Making solid design decisions
The guidelines I’ve found to be key in my projects can be distilled down to 4. In my experience, when a designer doesn’t incorporate the following rules within the product design cycle, the products they build will be either unsuccessful or accidentally successful — which means no insights are taken from it and success is hard to replicate.
- Understand the context
- Explore as many solutions as appropriate
- Gather feedback from other perspectives
- Measure success and learn from it
Let’s go into them one by one…
Understand the context
There is nothing worse than starting a project without a clear and shared understanding of the problem, solid evidence to the existence of the problem and what success should look like. This goes back to the baseline of good products, that they need to be valuable for potential and existing users. Even when there is already a concrete idea that inspired the project team, it is absolutely invaluable to align on the problem statement and challenge it if necessary, along with concrete success metrics.
In the most meaningful projects I have worked on, this has been largely a collaborative effort between product owners, designers and analysts. Some tools we use at HelloFresh to verify that a problem exists are online feedback, app reviews, cancellation feedback, NPS feedback, user interviews, and Hotjar for qualitative feedback; Google analytics and Tableau for quantitative data.
Explore as many solutions as appropriate
There are hundred ways to solve the type of problems product designers encounter day-to-day and the first solution is rarely the best option. Problems can range from very specific and small to broad and ambiguous. Design is sometimes about facilitating discussion among a group of people and sometimes about creating clear, usable interfaces. It is sometimes about thoughtful decision making and sometimes about brute force.
Whatever the needs may be, the tools that I’ve referred to while working on different sized projects range from brainstorming workshops and white-boarding with colleagues to wire-framing ideas, creating mockups and prototyping. If the problem is quite simple to solve, doing a brainstorming session will be a waste of time. However, if all we have is a high-level direction, jumping to mockups means we are missing out on opportunity areas and might be solving the wrong problem. In my opinion, it boils down to judgement about what tool is appropriate and that skill develops over time with experience.
Gather feedback from other perspectives
One of the biggest mistakes I see designers make is thinking they can “do design” alone or thinking only designers can come up with good solutions. Finding solutions that are not only obvious for the user; but technically feasible, match project timelines and address business goals is almost impossible without getting perspective—perspective from colleagues and from potential users. There’s a huge range in the types of feedback and the time investment that goes into them, from design reviews to guerrilla tests to planned user research. So, I also reject the notion that getting feedback from users will take too much time — designers can be scrappy when necessary.
As a rule of thumb, every project I work on gets feedback from colleagues (that I interact with on a regular basis) in the form of design reviews, going over user flows with engineers and product owners, or short feedback through our communication channel Slack. This is the easiest and mandatory-at-all-costs feedback. Then there are different ways to get outside opinion starting from guerrilla testing prototypes around the office and in cafes, to unmoderated testing to moderated in-house testing. One thing that has helped us in the past is to use new joiners for doing usability testing — they have a fresh perspective of the product and it makes for a cool onboarding.
Measure success and learn from it
And my final guideline of every meaningful project: getting insights at the end. What users say and what they do can sometimes be completely different. So, although qualitative feedback helps give direction, testing live will always be the most certain way to answer “How do we know if we are on the right track?”.
At HelloFresh, as designers get more senior, they need to become a crucial part of the conversations around understanding data, asking the right questions and analysing the user intentions underlying the behaviours that result in the numbers we often see in tools like GA, Tableau, Apptimize, etc.
Our aim, as a mission team at the end of a project is to decide:
- Our hypothesis was right and we should roll out to 100%.
- Our hypothesis seems to be right but we might need to fine-tune some things to counteract the negative effects.
- Our hypotheses seems to be wrong. What did we learn about our customers from this?
Many companies identify themselves as data-driven and that means being able to reflect on the data in a meaningful way. Numbers rarely give clear cut results. When teams optimise some part of the product they can create problems for other parts. Experimentation, then, needs a phase where the teams step back and reflect on the learnings. Given that all data is a reflection of human behaviour and product designers are trained by profession to have empathy with users, they become a key part of understanding the meaning behind the numbers to guide future decisions.