Demystifying the ‘product design process’

Our high level design process at Moonpig

What you’ll learn from this blog

It’s Monday morning and you’re faced with a fascinating customer problem to solve, but you have no idea where to begin. A quick google search of design processes, coupled with the advice from your trusty colleagues, and you’re left thinking…

“Eugh, not another design process”

Well I hear you! Over the past few years there seems to be a growing number of new ways to think about the process of solving customer problems and doing ‘product design work’, often leaving you more confused than before you started.

And how many times have you heard recruiters ask to “see your design process”? 🤷‍♂️

Over my 13 years of doing product design work as both an IC and a Manager, I’ve learned about many different approaches to getting from ‘outcome that needs to be achieved’ to ‘validating a potential solution with users and iterating on it’.

In this blog post I will share my key learnings and tips and tricks to help you navigate the choppy waters of product development.

TL;DR… There is no such thing as a ‘design process’. Instead, there are just a variety of tools that you should learn, suited to solving different problems at different times. Learn as many as you can (and maintain a curious mindset to learn new approaches in the future) and you’ll become a product design maestro in no time.

What is a design process anyway?

Nielsen Norman describe the design process as a way of “approaching problem solving with a hands-on, user-centric mindset”, often represented by a series of stages or steps to move from problem discovery through to implementing an idea or experiment. And don’t get me wrong, a design process can be a very useful tool to help frame the stages of your design approach, especially when you’re early in your design career and need something to anchor your decisions against, or, when trying to advocate for design thinking within your business.

Below are just a few examples of popular design processes that have been created and used by many teams around the world, such as…

1. The Double diamond (Design Council)

The Double diamond (Design Council), focusing on 4 key stages; discover, define, develop, deliver.

2. Continuous discovery (Teresa Torres)

Continuous discovery (Teresa Torres) focusing on 2 tracks; delivery, and discovery, both informing each other and running in parallel.

3. Triple diamond (Read more here)

Triple diamond (Read more here) which adds a 3rd diamond onto the aforementioned double diamond, focused on product development and rollout

4. Build Measure Learn (Read more here)

Build Measure Learn (Read more here) focuses on repeating cycles of building something to test, measuring the impact, learning from it, and using that to inform the next thing you build.

Just to name a few! Each have their own merits, and offer a similar but different take on product design, but fundamentally they help achieve the same end goal.

A useful way to think about the idea of a design process is to see it as a way of helping you do 2 things (and there’s more on this in the paragraphs that follow…)

1. Determine a solution to the problem as quickly as possible (focus on speed)
2. Ensure you’re solving the right problem in the first place (focus on risk)

A useful quote I’ve used in various teams I’ve worked in is…

“A design process helps you get to the right answers faster, and avoid making expensive mistakes”

And this is the crux of it… how do you ensure you’re solving the right problem, in the best possible way, as quickly as possible?

How a design process helps and hinders

Don’t get me wrong, a solid design process has it’s place in anyone’s toolkit or business process, and can often act as a very useful tool to align thinking across multiple teams or divisions in your organisation. When used in a slightly more abstract, high level way to share the key stages we go through in order to solve and test customer problems, it can be a powerful way of inspiring other teams to adopt our best practices.

However, the risk comes when experienced designers rely too heavily on applying their established process to every problem thrown their way. With every problem being different, a different approach is therefore required.

If you think about the design process as a way of moving from problem to solution as quickly and effectively as possible, it encourages you to think very differently about the way in which you move between those 2 stages…

• How long do you spend on each stage?
• How much effort do you invest?
• Who else do you involve?
• How much research is enough?
• What’s the best way of testing your idea?
• How do you learn as quickly as possible? How do you prioritise learning, i.e. via MVPs, user testing, forming great hypotheses, desirability testing.

So instead of thinking about your ‘process’, instead consider the tools you need to help you move from problem to solution as quickly as possible, those designed to help you learn about your customers and what is likely to work for them. What will actually help you figure out the most important thing allowing you to move on to the next step, rather than blindly following each step of your process just because it’s your process.

• Are stakeholder interviews relevant for this project?
• Do you really need to conduct primary research if this is already a well understood problem space?
• Do you need to work up detailed wireframes if we could test something with users in the same timeframe by pairing with an engineer?
• Could we run desirability testing using marketing channels/social channels to gauge customer appetite before we conduct lengthy research cycles or commit to code?

These (and many more) should all be questions you ask your team when working on projects in the future. Where do we prioritise speed vs invest effort to de-risk the problem? How long do you spend talking about the solution before you actually test it? A good friend of mine once said…

“The best solution is the one you have implemented”

And I reflect on this often to ensure we’re focusing in the right areas and prioritising the right type of work.

Thinking differently about the process of design

In essence, what we’re really talking about here is ‘design thinking’ rather than design process. While ‘design process’ may outline WHAT you’ll do, ‘design thinking’ focuses on WHY you’re doing it.

• What is the outcome from this stage of my process?
• What do I need to learn in order to move to the next step?
• How can I get to a conclusion as quickly as possible?
• What do I need to learn to de-risk this project or idea?
• How will this tool/framework/workshop/research help me determine the right solution?

What this all boils down to is… there is no one-size-fits-all approach to product design. Every problem is unique, and requires a different approach to problem solving.

Imagine you’re a mechanic working on a car. If you applied the same diagnostic approach to every car that came into the garage, sure you’d discover the problem eventually, but it would take a lot longer and cost the business a lot more money. Instead, experienced mechanics use the right tools to quickly narrow down the problem and repair it as efficiently as possible, picking the right tools for the specific job at hand. You should consider your job the same, you have a variety of tools in your toolbox, some you know, some you won’t, but you can deploy these tools strategically to help you solve the problem at hand as efficiently as possible.

One way we’re thinking about this is comparing the various types of problems or projects we face in our daily work, and comparing them on a 2x2 that helps us…

1. Understand the level of risk associated with the problem space
2. Understand the current level of knowledge we have within that problem space

This matrix has been a useful way of encouraging designers to consider the type of problem they’re solving before determining the right tools to help them get from A to B as quickly as possible.

Problems that are high risk and are fairly unknown problem spaces require a greater investment in upfront discovery work to ensure we understand the market, users, demographics we’re solving for through discovery based research activities, i.e…

1. Ethnographic research, diary studies, primary research
2. Jobs To Be Done, Value Prop Design, Lean Canvas
3. Storyboarding

Problems that are high risk but in a fairly well known problem space may require a shorter discovery phase to build confidence we understand the problem well enough, i.e….

1. Journey mapping, service blueprinting
2. Empathy mapping, secondary research
3. Wireframing, scamping

Problems that are lower risk and in a well known problem space can focus on speed and a test and learn approach, aiming to take risks and validate ideas through observing what customers actually do, rather than only what they say they will do., i.e…

1. Prototyping
2. AB testing, fake door tests
3. Guerilla testing
4. Dev pairing

We’re building a design toolkit within each of these categories to help designers pick the right tool for the job at any given moment, more on that very soon!

An Agile Coach I used to work with introduced me to a Japanese quote and form of martial art that helped me understand this with greater clarity… “Shuhari”, which roughly translates to “follow the rules, break the rules, transcend the rules”.

• shu (守) “protect”, “obey” — traditional wisdom — learning fundamentals, techniques, heuristics, proverbs.
• ha (破) “detach”, “digress” — breaking with tradition — detachment from the illusions of self, to break with tradition — to find exceptions to traditional wisdom, to find new approaches.
• ri (離) “leave”, “separate” — transcendence — there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical — there is no traditional technique or wisdom, all movements are allowed.

When applied to design thinking, you can think about it in this way…

• Shu — Learn the tools, the frameworks, the different processes for problem solving (much like a mechanic learning about new tools in their toolbox; the hammer, spanner, screwdriver, understanding what they do and how to use them)
• Ha — You know and understand a wide variety of tools, and can naturally select the right tool for the job without thinking (much like a mechanic simply grabbing the relevant tool from their toolbox without needing to compare them all side by side)
• Ri — You understand the tools and process so well that you no longer need to rely on a specific framework to help, instead you can create new frameworks or tools made from component parts of everything you’ve learned, unique to the problem you’re trying to solve (much like a mechanic determining workarounds or new ways to solve a problem, using a variety of tools to overcome the challenge).

With all this in mind, your ‘process’ is really just a case of selecting the right tool at the right time (or creating your own tool!) rather than following a rigid step by step process that must be applied to every problem.

Maintain a curious mindset

So what’s my advice to you?

1. Try to understand a variety of tools from problem discovery, to prioritisation, ideation and validation. Only through understanding the pros and cons to each tool (the first part of Shuhari) will you begin to master them. Keep track of the tools you’ve learnt, log them somewhere helpful for future reference, even create your own toolkit for the future.
2. Understand what you don’t know. Even if you haven’t had a chance to use the tool itself, simply being aware of it is the first stage of learning!
3. Test out new tools. See your next design challenge as an opportunity to validate these new tools you’ve discovered and see if they help you get from A to B more efficiently, with a better outcome, than other tools you’ve used before.

Understand your strengths and weaknesses, and look for others who can help you. No one is exceptional at each stage of design thinking, and tends to gravitate either towards problem discovery or ideation. Look for others who compliment your skillset and work together to coach and mentor each other.