‘Where are we?’ is not only one of my favourite tunes – It’s also a good question to ask ourselves when we join a new product development project.
You know that illustration of the design process as it really is; the one that turns a straight line into a tangled piece of yarn? It’s kinda like that when you step into a new project, trying to work out what the brief is really about and how you can best support the project goals.
It can be quite stressful knowing that it’s up to you to define the design plan but at the same time not be sure about the next steps.
Are the project success criteria clearly defined? Do you have validated and up-to-date user insights? Are there technical constraints you need to be aware of? Is the problem statement even the right one?
I find it useful to take my bearings by asking myself a set of questions when I join a new project. The answers can then help me pin down exactly where we are in the product life cycle and design process, thus informing me of next steps.
My design process – The double diamond
The double diamond has been embraced by the product design community wholeheartedly since it was popularised by the British Design Council in 2004. It wasn’t revolutionary, didn’t introduce anything new and designers had been using variants of it way before it was articulated in its current shape. But it gave us a name and a neat model that is easy to understand and tweak to our needs.
Using this ideal design process as a map for the project at hand, I can use the following set of questions and answers to understand where we are, and thus what we need to do next.
The design process is a model, obviously, and often far from what reality looks like. It may seem a bit too theoretical to be practical in the field but I have found it very useful to give structure to rather chaotic projects – over time it has become the lens I apply to any design brief I’m given.
Questions to ask at the beginning of your new design project
Is this a project? If not sure – Does the project have SMART goals?
Yes: Good, you’re off to the races.
No: The double diamond design process is not the right tool.
In order to put yourself on the process map, the very first thing we need to establish is that you’re part of a project. The double diamond design process is project-led, so if you’re joining a team tasked with maintaining a design system or run designOps, that’s going to require a different process. This is probably quite easy to detect, but if ever in doubt wether this is actually a project, simply map your duties against SMART objectives and if it doesn’t add up your work isn’t project-led.
Do we know what problem we’re solving (or opportunity we’re chasing)?
Yes: At least you’re not in the 1st quarter of the design process.
No: You are at the very beginning of the process and need to create a problem statement or project objective.
In my double diamond the first diamond refers to product/market fit. Others simply define it as the discovery or research phase. Either way, the first diamond is about answering the WHAT, and the second diamond is about the HOW. That’s a great clue right there and I use it all the time if I’m unsure.
If your brief is “Design this app that is like Tinder for dog owners” you can pretty much rip off Tinder and have a pretty nice design done in a short time. But if the answer was ‘no’ to the question above, you know there’s work to be done in the WHAT diamond.
This is not always what the client wants to hear, but challenging the brief and pushing for a solid product/market discovery phase is sometimes needed and will help the project in the long run. Of course, the client pays your bills so know when to stop being an idealist and find a compromise if needed.
Do we (really) know who we are designing for?
Yes: You can start exploring solutions in the HOW diamond.
No: You are in the 1st or 2nd quarter of the design process and should gather or synthesise user insights.
In our dog owner Tinder example you would’ve been excused for thinking it’s a shit idea. But maybe the product owner hands you some convincing market trends that points towards a real opportunity.
If we don’t know what the USP is (or whether our users actually value that USP), or don’t have a better persona than ‘Dani the dog owner’, you have some user research ahead of you. A design decision should always be a response to a verified hypothesis about your users. This is called hypothesis-driven design and it’s the bee’s knees.
Do we trust the accuracy of the user insights provided?
Yes: You can start exploring solutions in the HOW diamond.
No: You can either redo the user research in the WHAT diamond, or do a mini discovery before you enter the HOW diamond.
Quite often I find myself brought into a project at the beginning of the HOW diamond, only to find that the user and market insights given to me aren’t up to snuff. What was handed to you as a set of personas might’ve been user profiles based on the stakeholders assumptions of the user. What was claimed to be user behaviour based on usage data might not be applicable if you’re entering a new market with the new design.
In this case it’s highly unlikely that you’ll get the time and budget to redo the research phase, but you should at least highlight the issue with missing or false insights and decide best way forward together with your team.
Are all relevant hypotheses about your users answered?
Yes: You can start exploring solutions in the HOW diamond.
No: You can either redo the user research in the WHAT diamond, or do a mini discovery before you enter the HOW diamond.
Similarly to the question above, you might find that after doing a hypotheses exercise you don’t have the answers to design-critical assumptions. Spend some time filling the gaps best you can before going into solution exploration. This doesn’t have to directly include users if that’s too much of an ask. You can also go through customer feedback logs, look at analytics data and talk to stakeholders and subject-matter experts.
Do we know how we are solving the problem (or realising the opportunity)?
Yes: You’re in the final quarter of the design process, with focus on production and testing.
No: As long as you know what and for whom, you’re ready to explore options.
This far into the process it’s usually easy enough to know what’s going on and what needs to get done. Blockers and friction here is more likely related to the designOps in place; i.e. your tools and processes for producing, testing, signing off and handing over design.
A good process is paramount for efficient product development. Unfortunately, humans are a messy bunch. When we are put together in large companies with layers of sub-cultures within, we often get a cocktail of conflicting interests, ideas and values pulling the project in all directions.
This is probably why I’m often overwhelmed in my first days in a new large scale project. Things aren’t always straight forward, and we simply have to make the best of the situation and find a way of working that contributes most towards the end goal.
Stay calm, ask questions and figure out what needs to get done. I believe that’s a good way to keep your client happy and your stress levels down.