I have used Design Thinking on many projects over the years, such as the IBM Mail Onboarding Manager (a.k.a. M.O.M. – best acronym ever!), and I am an unabashed fan.
In addition, I’ve also trained teams in the use of Design Thinking techniques. It really is an exciting process and people have very strong, very positive, reactions to the experiences. There is always this moment when you can see the “Aha!” happen.
Sometimes, I Wish “Design” Wasn’t In the Title
As odd as that statement sounds, I think that by referring to this technique as “Design Thinking” undercuts one of its core benefits, which is to get all the different disciplines (e.g. Product Management, Design, Engineering, etc) on the same page. Engineers and Product Managers often think “Oh, this is for user experience designers, it has nothing to do with me,” when, in reality, the title simply reinforces that we are taking a design, or user-centric, approach to the problem and applying it to three distinct stages of software development: Understanding, Design, and Implementation.
Understanding
One of the things Design Thinking excels as it is getting all the key stakeholders and participants to clearly articulate and agree on what the objective of the feature/product/project. These objectives are defined as “Hills.”
A hill clearly states “Who” the target user is, “What” they want to accomplish, and the “Wow,” or, as I like to think of it, the “why would anyone pay money for this” component.
For MOM, for example, our who were System Administrators, the what was giving them the ability to migrate their users data from an on premise system into the cloud, and the wow was the ability to do is a self serve manner. That last bit really only seems wowish if you are aware that data migrations of the sort we were looking at tend to nasty, brutish, unpleasant experiences. You’re just going to have to trust me when I tell you it really is a wow.
Arriving at this hill required designers, product managers, engineers, etc, to focus on the users and their needs. We conducted a workshop where we used different exercises to articulate our users needs, such as Empathy Maps, As-Is and To-Be statements, paper prototyping, and others.
Usually there are only three hills for a project. These objectives are scoped to ensure the objectives can be built in a reasonable amount of time (for example, in a quarter). By keeping the hills small and manageable, the team can stay focused on these priorities and, hopefully, keep other distractions from creeping in and stealing focus.
Customer as Partner
Once you’ve got your hills, the next step is to validate them with real life customers. These customers, referred to as Sponsor Users, partner with the design team to realize the initial wireframes of the design. Designers and Sponsor Users meet regularly throughout the design process as the customers provide feedback and the designers iterate. The best model I’ve used is to have at least two Sponsor Users (bonus points if they are from different companies) and meet with them every other week. This reduces the burden placed on the customers while providing the design team with regular feedback.
We’ve Arrived – Playback 0
Playback 0 is a deck of wireframes, or prototype, that the team uses to tell the story of how the hills will be realized to the executive stakeholders. Ideally the sponsor users are present so they can respond to any questions the executives have. It’s even better if the customers present the playback themselves, though they often don’t feel comfortable doing so.
Playback 0 represents a commitment on the part of the team to build what is envisioned, and a commitment by the executive stakeholders that they are in agreement and will support the team in their objective.
Sons of Playback 0
Once Playback 0 occurs and everyone is in agreement on what needs to be built, design starts creating detailed specifications and engineering starts building. Code and designs are still being put in front of Sponsor Users to confirm their needs are being met.
More importantly, as code gets delivered, there are additional Playbacks (e.g. Playback 1, Playback 2, etc) in which the story originally told in Playback 0 is revisited with live code demonstrating the story. This helps reinforce that we are delivering on the story and, by extension, the hills and our original objectives.
The Big Benefit
My favorite Design Thinking workshop that I ran was for our summer co-ops. It included User Experience co-ops, of course, but also engineering co-ops as well as other disciplines. All of them loved the Design Thinking process, but the engineering co-ops in particular walked away with a new sense of the need to focus on users and, more importantly, techniques they could use in the future to achieve that focus.
Sometimes as Design professionals we forget that the things that are second nature to us, reaching out to end users, getting feedback, and iterating designs, are not always so obvious to everyone else. Imparting this viewpoint to without a doubt the single largest benefit of Design Thinking.
