Design thinking is a framework that guides designers through a series of activities to facilitate the creation of new and innovative solutions. Design thinking is not new to the IT industry and it certainly is not new to IBM. My first exposure to design thinking concepts within IBM occurred well over 3 years ago when I was working on an IBM Pure Application System (IPAS) development team. I have to admit that my initial exposure to design thinking left me dazed and slightly confused.
I was working on a disaster recovery solution. I worked closely with the lead architect to define our disaster recovery lifecycle. We created a 50+ page document describing the lifecycle. The document described all possible disaster recovery states, transitions from those states, processing associated with each state transition, as well as the user interface. When our user experience (UX) group invited me to a walkthrough of our disaster recovery solution I was very excited.
In the past we had similar groups in IBM, but we called them something like the human factors group or usability group. My first clue that something different was about to happen should have been the name: UX group.
I walked into the UX walkthrough thinking we were going to cover the details of the life cycle document I worked on. Much to my surprise we did not. The walkthrough consisted of a story about the people that had to use our solution. It focused far more on them than the solution. It described their roles and associated a name and face to each role. I vividly remember sitting in this meeting wondering what was going on. To me the lifecycle was a series of transitions between states. Why would I care how Adam, the disaster recovery administrator, feels when he gets called at 3:00 AM to recover from a catastrophic hardware failure? Well it took some time, but I now understand why I should care.
IBM has always been a great innovator of new technology. Heck, we pride ourselves on being at the top of the U.S. patent recipients list for each of the last 23 years. In 2015 alone, IBM received 7,355 US patents. There is no doubt in IBM’s ability to develop leading edge technology, but as Millennials and Generation Zers advance in the workforce and the number of Baby Boomers and Gen Xers in the workforce declines, technology is not enough. Millennials and Generation Zers grew up taking technology for granted. They crave products that have a sexy design and are intuitive to use. IBM needs to develop solutions that meet the demands of today’s and tomorrow’s workforce.
It may seem obvious that we need to develop products that are easy to use and fulfill our customers' demands, but exactly how to do that is a little less obvious. Today in IBM there is a subtle switch from an emphasis on building technology to an emphasis on building solutions. When I walked into that IPAS disaster recovery walkthrough 3+ years ago, I was focusing on technology – how to build it and how to wire it. The members of the UX group were focusing on a solution.
IBM utilizes design thinking in concert with an Agile development process to deliver to customers an exceptional user experience. About 18 months ago I had the opportunity to attend a design thinking workshop. As I participated in the workshop it occurred to me that we had been using design thinking principles back in my IPAS days. I just did not know it by that name.
Here in the z/OS Communications Server organization we are using design thinking to drive the content for our next release. I am fortunate to be the technical lead on the development of our very first design thinking hill; although, at times I feel like the crew of the starship Enterprise - boldly going where no man has gone before.
A hill is a piece of work stated in terms of a ‘who, what, and wow’. In my case, the ‘who’ is a z/OS network security administrator. Unfortunately I can’t disclose the ‘what’ at this time, but I assure you it will wow a z/OS network security administrator. I know this because we are using the design thinking framework to develop the hill.
My hill, like all design thinking hills, was born at a hills workshop. At a hills workshop a list of candidate hills is created. Each hill is ranked based on cost to implement and value to customer. A set of hills to capture in an upcoming release is agreed to. The intent is to pick hills that will provide maximum value to customers within the allotment of available resources. Keep in mind that hills focus on a ‘who, what, and wow’. Some enhancements don’t have that wow factor, but need to be done in a release nonetheless. A "foundations" bucket is created for items like this.
Customer validation of selected hills is important. After all, what good is creating a solution to a problem that our customers do not experience? To that extent, my team surveyed a group of customers, asking them if our hill statement addressed a real need and if they were interested in our solution. 83% of 23 respondents agreed our hill statement addressed a real need and 90% expressed interest in our solution. A few months later we followed up with a second survey to help us prioritize the aspects of our solution. To put this in design thinking terms, we were interested in understanding what our customers viewed as their minimal viable experience.
Once our hill statement was validated we focused on understanding our customers' pain points. My team interviewed a small group of customers to discern the people involved with our hill, what those people do today, and how our hill can improve that. Based on the information we obtained from the interviews, we defined a set of personas exemplifying the typical roles, responsibilities, and concerns of people involved with our hill. We then documented our understanding of the ‘as-is’ scenario and created a proposed ‘to-be’ scenario.
In parallel we started to solicit customers to become sponsor users. A sponsor user partners with us to shape the solution of our hill. Being a sponsor user requires a significant time commitment on the part of the sponsor. Typically we engage with a sponsor user once every month or two to solicit their input on our solution. The first activity we did with our sponsor users was to walk them through our understanding of the personas, ‘as-is’ scenario, and ‘to-be’ scenario. Feedback from this and all future sponsor user activities is incorporated into the design of our solution. Currently our hill has 4 sponsor users. We will continue to engage with them until our solution ships.
This is a significant change in the way we develop new function. I think this is a good change and I am excited to continue working with my sponsor users so we really can wow z/OS network security administrators in the next release of z/OS Communications Server. I hope you agree and are equally excited. I know our sponsor users are.