Reflecting on the design process
Having worked within the digital product design team at HelloFresh — a high-growth meal-kit company enabled by tech — for almost 3 years, I recently did some soul searching about what I believe product designers do and, more importantly, how we work when distributed within mission teams.
As many thought leaders within the industry have already stated eloquently: At their core, product designers care about building good products; meaning products that bring value to a big enough user base, are easy-to-use and transparent, and — although not many products achieve this — are just enjoyable to interact with.
Is there an ideal design process?
Building products that are valuable, easy-to-use and enjoyable is quite a feat. As designers, we learn about design processes that enable us to tackle these challenges in a methodical way.
Looking back at my experience within a product company that grew massively, I’ve realised that there is no ideal process that works for every project, every team or every designer. There are multiple things that get in the way of a rigidly structured approach — sometimes research is incomplete before a project starts, often times there is business or time pressure, and sometimes the biggest problems users face are already known.
Assuming there is a common understanding within the company that building good products — as mentioned above — is key to business success, certain guidelines are enough to ensure the decision-making in running projects is solid. As Julie Zhuo says, “Ignorance is the enemy of good design.”
“Nothing should be done at random; ignorance is the enemy of good design. To make a subpar decision because you didn’t get enough context or feedback is to fail.”
Julie Zhuo
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.
Successful projects lead to insights
I always consider a project “successful” if we manage to improve the experience of our product, improve the communication of our product, or understand our users better upon reflection of the data. For that, the 4 guidelines are essential to every project, big or small, in a time crunch or not, whether the project is initiated by design or business—because they ensure there is a clear context, ample exploration, and a subjective measure-and-reflect phase.
As, Stewart Butterfield writes in this inspiring memo:
“We get zero points for just getting a feature out the door if it is not actually contributing to making the experience better for users, or helping them to understand Slack, or helping us understand them.”
Stewart Butterfield
