How to Create the Ideal Design Thinking Process
Design Thinking is about creating solutions with the user in mind. Sounds obvious ––of course the product you are building is for the people who will use it. But as many have found, without a solid process underpinning your work, it’s extremely easy to replace the user’s point of view with your own, to develop tunnel vision, to think about business objectives rather than user needs.
Design thinking provides a toolkit and methodology for keeping the user front and center throughout the design and development process. Ask 100 practitioners about their process and you’re likely to get 100 different answers. But there are some consistent themes underlying most design thinking approaches.
The Design Thinking Methodology
There are a variety of different methodologies that have been developed over the years, all of which are pretty similar. We leverage the methodology developed by the Stanford d.school:
Start with Empathy
By far the most important principle is to develop and deploy empathy. Before we knew what design thinking was, we realized that what separated great product designers from everyone else was the level of empathy they would develop for the users they were designing for.
Empathy is about understanding the user - their aspirations, their fears, their values. How they move about their day. What they use to make their lives better.
There are several methods for building empathy:
Brainstorming
The least effective way to do this is to brainstorm your way to it. Sitting in a conference room making assumptions about your users is better than nothing - at least you’re consciously thinking about them - but it’s not nearly as effective as getting outside the building and actually talking with your users.
Customer development interviews
Customer development interviews are a much more effective mechanism to develop empathy. It’s critical these conversations aren’t your attempt to convince users about your solution - they are strictly about trying to understand their worldview, their lives, and their needs.
Observation
While proper customer development interview creation can gather a tremendous amount of insight cost effectively, sometimes it’s worth the additional effort to actually observe users in their environments. There can sometimes be a disconnect between what they say and what they actually do. Often their needs and values aren’t even obvious to them - watching what they do can sometimes uncover these unstated preferences and values.
Define a point of view
You’ll gather a lot of insights by talking to users. Before you jump to creating a solution, it’s imperative to gather all this material and attempt to make sense of it. We’ve found putting everything up on a wall in a collaborative session with your team can be an effective way to attempt to find meaning and patterns. The specific methods you use ––post-it notes, user journey maps, experience diagrams, etc.–– are ultimately up to you and your team. But what matters is getting it all up there where everyone can see it.
Preserving beginner's mind
In spite of your best efforts, you lose beginner’s mind extremely quickly. You’ll often find yourself forming opinions after a couple conversations.
Having the big picture up on a wall can be helpful for you in forming new connections and challenging those initial assumptions. Likewise, having other team members see these insights for the first time will undoubtedly lead to new connections and insights. With insights synthesized, you’re ready to define your point of view about the design challenge. This is often in the form of a problem statement - a clear, actionable guiding statement informed by your research, to be used as a north star for the steps that are to follow.
This step is often where things can go wrong. It’s been said defining the right problem is 90% of the work. Taking this step makes sure you are focused on the right problem, and that you’ve clearly identified what that problem is.
What makes a good problem statement
It sounds counterintuitive, but good problem statements are often smaller than you think. It’s a temptation for people to want to define the problem broadly. But this actually makes the steps that follow harder.
Good problem statements are often smaller than you think.
Constraints have a tendency to unlock more useful ideas. Tight problem statements also make it more likely you develop a compelling core experience in the final solution - and as we’ve discussed often, having a tight core experience is predictive of eventual product success.
Finally, having a tight problem statement makes it easier to know if you’re solving it. It reduces variables, helps you figure out the levers that matter, and makes it easier to measure success.
The Opportunity / Satisfaction framework
One tool that’s useful in this process is the opportunity / satisfaction framework. You’re going to uncover a bunch of potential opportunities. But not all of them are created equal. In many cases users are actually pretty satisfied with the existing solutions - even if that solution is something they cobbled together themselves. Displacing an incumbent is certainly possible, but it’s hard. And if customers are generally happy with it, your task will be much harder.
Great problem statements will galvanize your team, be easy to explain, will excite potential users, and will help you avoid the dreadful mistake of building a solution that tries to do too much.
Ideate potential solutions
Another pitfall in product design is focusing on a single solution too quickly. It’s rare the first idea is the best one. Odds are if it’s obvious to you, it’s obvious to others.
Typically, the best solutions come from looking at the problem from a variety of angles or facets, and focusing initially on breadth of potential solutions. Ideation is the process for developing those ideas.
While this can certainly be done by a single person, again it’s often helpful to have it be a collaborative process. Different people will bring different perspectives, which by definition multiplies the raw material you have to identify potential solutions.
The specific techniques or tools you use again can depend on your team’s preferences and the specific problem you’re trying to solve. It could simply look like brainstorming sessions. However, we’ve found certain frameworks or exercises can help frame the problem in a way that leads to more ideas.
How might we
One framework we’re fond of is called “how might we.” It’s exactly what it sounds like - asking “how might we” to subsets of the problem statement. They can stem ether from the problem statement itself, or from artifacts created during the synthesize step. User journey maps can be a great way to break the problem statement down to component parts, and provide plenty of fodder for good "how might we" statements.
You can conduct a series of ideation exercises on the the "how might we" statements the team thinks are most valuable to solve. This allows you to focus and constrain your ideation further than by trying to tackle the entire problem statement.
It’s critical that you capture as many ideas as possible early on before making decisions
There are dozens of other tools you can use - sketching, creating mind maps. Etc. But the common thread is to defer judgment. It’s critical that you capture as many ideas as possible early on before making decisions. To the degree you place value judgments on ideas too early, you effectively shut down the creative process and stifle the creativity that can lead to truly novel solutions.
Making decisions
Once you’ve generated a sufficient set of potential ideas, you can leverage discussions and other decision-making frameworks to narrow and select ideas to focus on.
Dot voting is a popular approach - with the ideas all up on the wall, people walk around silently and place sticky dots on the ideas they think have the most potential.We’ve found it’s helpful to provide criteria for evaluation. Leaving it up to people to determine their own criteria can sometimes cause participants to lose focus on what problem you were initially trying to solve, or the feasibility of a potential solution, or the strengths and weaknesses of the team. Criteria like “smallest level of behavior change required”, or “technical difficulty” or “most likely to delight” can be examples of such criteria.
Prototype
Prototyping is all about getting potential solutions in the hands of users as quickly as possible. They help you think through your potential solution, communicate it to stakeholders, and rapidly test potential solutions inexpensively.
Prototypes can take many forms - it often doesn’t mean code. It can be something as simple as written product concept, or mockups, or a clickable keynote. What matters is creating the prototype that allows you to get useful insights as quickly as possible.
Prototypes also don’t have to address the entire problem statement. You can prototype specific steps of the user journey, chaining them together over time as you hone in on solutions that are effective.
Test
Once you have your prototype in hand, you go back out and talk to your users to get feedback. Just as in the first step, a prototype is not about selling your solution or convincing them. You want to see how they interact with it, and have them tell you what they think about it. You are very likely to identify issues that need to be addressed. This isn’t a bad thing - in fact it’s the whole reason why prototyping is valuable. The point of doing it quickly and inexpensively is to identify issues and reduce risk when it’s cheap and fast.
The critical importance of iteration
The worst thing you can do in the prototyping process is not use it to capture feedback and iterate in response. It’s not uncommon to find teams falling down here - they get attached to their ideas and aren’t willing to step back and go through the loop again. But testing is another opportunity to develop even more empathy and potentially refine your problem statement. To ignore this opportunity is foolish. To the degree you can convince your team to focus on speed with prototyping, you can minimize this tendency. By setting the expectation that these things are meant to be thrown away, you can get them to move faster and test more. And by reminding them that the purpose of testing is to figure out what’s wrong vs. what’s right, you can set expectations appropriately.
Plan for as many iterations as you need to get this right. It’s tempting to build the final solution, but it’s almost always more expensive in the long run to have to iterate on the working product. Resist that temptation until you’re confident you’re on the right track.
Leveraging Design thinking in your organization
Design thinking isn’t dogmatic - different techniques and tools will work more effectively for you than others. What matters is committing to a process of developing empathy, and using the insights you generate to rapidly and iterative pursue potential solutions.
The best way to build these muscle in your organizations is to simply start. Start with a potential hypothesis or problem you’ve heard about from customers. Or simply start going out and talking to customers about their issues with your solutions or other problems they have. You’ll stumble through it at first, but you’ll learn what works and doesn’t for your organization by trying.
Manifold can help - our customer development sprints can help teach your team how to conduct user-centered interviews while gathering valuable insights in the process. And our collaborative design sprints can take those learnings and rapidly arrive at compelling solutions. To learn more about either, feel free to contact us.
