During the discovery phase of design thinking, the objective is to gain an understanding of the user’s perspective by investigating their habits and processes. Towards this goal, researchers and designers often ask “why?” to dig into details.
There comes the “Five Whys” technique. Described in many articles and recommended for designers, it’s a tool that helps to reach the root problem that should be solved (1). The rule is simple: when you receive a problem statement from a user or stakeholder, ask “why?” and repeat this question four more times. The fifth one should be recognized as an issue that requires attention and resolution or, at the very least, consideration.
Theoretically.
As a UX/UI designer in my company, besides work connected strictly to the product we make, I try to improve internal processes. I once suggested making a small workshop for my non-designer colleagues. As a recent project had failed, they decided to find out what went wrong and think about how to improve the process for similar projects in the future. As I was the moderator, I decided to use the “Five Whys” task in the workshop session. After reading plenty of examples, I was expecting to hear aspects of the current process that made this project go sideways.
While digging into specific things that failed, I started asking “why.” After the second “why,” some colleagues started to look at me, offended.
Why?
Wnen performing the “Five Whys” task, participants may feel as they are being interrogated and blamed for mistakes. They might also feel their competencies are questioned.
Why?
Fast and emotional thinking took the lead when asked “why?” — even though participants had previously exhibited a non-personal attitude toward UX designers’ work.
Why?
People prefer to be competent, view themselves as competent, and they are already competent to some extent (need for competence). (2)
Framing obstacles in a way “lack of time” helped a bit to focus on raw facts. It required activating the slow thinking (also known as “System 2”)(3).
What worked well
Instead of pushing them to fill out my template, I let participants engage in a spontaneous discussion — with my minimal moderation to make sure everyone is understood. Luckily participants quickly spotted the main problems and focused on proposing preventive actions they would perform next time. Thus, the ideation workshop that would normally follow, wasn’t needed.
I feel it necessary to highlight another observation here. When it comes to problem discovery within a group of specialists in a specific field, we (designers and researchers) shouldn’t be afraid of adopting a solution-focused approach — I believe they will know best how to address specific issues, drawing on their professional knowledge and experience.
Workshop summary
Creating the summary in a certain way was crucial to adding value to the team and encouraging a mindset focused on opportunities rather than failures. As a takeaway for the participants, I prepared a friendly-looking rules we agreed during the workshop.
I gathered all the things I learned. If, during the workshop (and preparing a summary of it), you want to use the “Five Whys” tool, consider applying the habits presented below:
- If among participants there any report to another, make sure admitting mistakes won’t affect the employee.
- Explain at the beginning (and keep reminding it later) the point of the task is not to blame anyone or prove mistakes.
- Digging into the details can make people unnecessarily uncomfortable. Try to follow a top-down approach and implement the “Five Whys” method once you have more information.
- Form questions into “Why? What happened/happens?” or “Why? What makes/made you do that?” instead of a simple “Why?” or “Why do/did you do that?”
Example:
– There was a bug.
– Why? What happened?
– I didn’t check the code properly.
– Why? What happened?
– I didn’t have much time.
– Why was it like this?
– I have too many duties. We need another developer in our team. - Don’t take the “Five Whys” tool too literally. Three whys might work just as well.
- Don’t address needs personally — avoid using names. If needed, use e.g. position names in singular or plural form.
Example:
Front-end developers need to use a component library in order to follow design system principles. - For more general questions or statements, use “we”.
Example:
What can we improve to avoid those mistakes? - When preparing a summary, focus on future possibilities, not the past. Unless necessary, don’t refer to failed projects, specific mistakes, or people.
Example:
There is a lack of updates between team members. Employees admit it’s hard to follow all applied changes, especially if there is any one source of truth.
Read the full article here
