I’ve had to think about my ideation and design process a lot lately, transitioning from a background of customer-centered product design to tech companies that are more driven by engineering. How does design work in these environments?
Also, during the recent extensive time at home I’ve managed to cook a lot of meals. I had an aha moment this weekend where I realized that a design process is similar to a cooking process. Hear me out on this one.
With cooking, you start with the goal (eating, most likely), then sometimes have a very strict plan where you buy all the exact ingredients you need, then use all the exact measurements to create the recipe. Other times with cooking you wing it, using the framework you’ve learned over the years as a guide and whatever ingredients are left in the fridge. With the strict process, you’ll have a predictable result. You also have more chance of success. But sometimes you can wing it and come up with something wonderful and unexpected.
With design, you start with your goal (usually from a business need) and can either follow a very strict process where each step is specified and measured out, or you can use a loose framework of data and instinct to lead you towards a result. The latter is where we are currently on my team, with a rough idea of design activities but none are required or established as a process to follow in any particular order.
I will point out that it’s a privilege to have the autonomy to create my own process, and it’s prompted me to look deeply into what I’ve always believed to be the “right” way to design, or the correct process that will produce the results we need.
Here are the parts of the framework that I employ in my design process, using the double diamond framework as a guide.
Question the premise (The discovery phase)
Sometimes you have clear business goals, and sometimes you don’t. Sometimes those business goals don’t make sense. As always, if you’re not clear about the “why”, be sure to get clarity. A better question gets a better answer. This clarity opens up the potential for a lot of creativity, and the ability for people to ideate within those constraints.
This thought experiment is about questioning the premise. Look at the thinking that led your team to this business goal, evaluate whether there are underlying assumptions that need to be teased out and validated. Always reframe the problem.
Here’s an example. Look at these two questions:
- “What is the sum of 5 plus 5?”
- “What two numbers add up to 10?”
The first question only has one answer, while the second has an infinite number of solutions (including negative and decimal numbers.) Changing the frame can drastically change the range of possible solutions.
Albert Einstein is quoted as saying, “If I had an hour to solve a problem and my life depended on the solution, I would spend the first fifty-five minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.”
So how can we translate that to an actionable process for our team?
- Ask why, then ask why again. and a third time. Use The Five Whys technique where it’s applicable.
- Research. Talk to everyone involved. Stakeholders, customers, people on other teams, etc. Ask questions that will validate or invalidate the original hypotheses.
- Look at the competitive landscape. What are other companies doing? What are opportunities in the current environment that might change our perspective?
- Summarize raw findings and cluster into themes
- Find insights and build opportunity areas, create How Might We… questions
Insights are the dormant truth about a customer or potential customer’s motivations or frustrations on a topic, and opportunity areas are markets, tactics, audiences, or features where we can take action. The How Might We… questions turns those insights and opportunities into tangible statements of what can be done or solved within that area of action.
In much the same way that you’d look at the ingredients in a recipe with curiosity – why did they say to add maple syrup to the tahini? I remember another recipe where sriracha was way better here – “tear up” the design brief with the same informed, creative, and thoughtful judgement.
As a designer it might be easy to skip this step, but it’s our job to create a solution. If the business goal is fundamentally flawed, that’s a lot of wasted time spent designing a perfect solution for a flawed premise. Don’t skip this step.
Salt, fat, acid, heat (The tactical phase)
This is my favorite cooking framework, coined by chef Samin Nosrat on her gorgeous Netflix show. These four components are essential to any great-tasting meal, although they don’t guarantee one.
The design components that are essential to any great solution for me are data, gut feeling/vision, and empathy. Data being what we know about the landscape and quantitative assessment of our users/potential customers, gut instinct being what we know to be good design, and empathy being the ability to put yourself in others’ shoes and change your perspective to understand how the customer might use your product.
This article about moving from data-driven to data-informed design by the Head of Design at Atlassian really resonates with me.
Even if you don’t have a design process chiseled in stone, using these three components in your tactical design cycles will create learnings to base future decisions on. A clearly defined and proven product development process will decrease risk and likely increase your team’s chances of success, however.
The following actionable steps can be done as as individual designer, or as part of a workshop or design sprint. It feels like there’s an opportunity in that moment of ideation, where having multiple voices can lead to more potentially viable solutions and greater buy-in from across the organization.
That said in an organization that’s free from the needs of stakeholder alignment, if it’s a choice of planning a design sprint vs coming up with the solution yourself, the latter is more lightweight.
- Sketch and ideate. Expand the possibilities before you narrow them down with reality.
- Simplify. Narrow down the ideas to what is the smallest thing you can do to achieve the biggest value.
- Storyboard. Walk through the user journey from beginning to end. Understand context and purpose.
- Prototype. Make the idea as real as possible.
- Test. Put the fleshed out idea in front of people and see how it solves their problems.
Similar to when you try a new recipe, now you’ve tested or released a new feature and can iterate on it the next time based on how it turned out.