Though great designers employ a myriad of tools to solve problems, perhaps the most powerful tool is effective use of the question “why?” Why? Because it helps the designer understand the deeper need (the why), as opposed to a solution (the what).
Having become more proficient at asking “why” myself, it’s become more evident to me when a designer does not ask this critical question. I’m going to describe a failed user experience I had recently using Microsoft Project — the negative consequence of Microsoft’s team not asking “why.”
“Why?” for Understanding Need
Search the internet for “asking why design” or “five whys” and you’ll find dozens of articles discussing how, when problem solving, the first step is to understand the deeper problem or need. Continually asking why — perhaps using the five whys tactic — is a valuable approach. (Although certainly not the only one. Please see the wonderful book Designing for Growth, or Don Norman’s great discussion on the power of stupid questions.)
Of course, when you don’t consider the need, the result is poor design.
What Not to Do
I was reminded of this recently when trying to export a Microsoft Project project as a CSV file. Project has this capability, but along the way, the exporter does a number of asinine things. In my case, it won’t export dates in a non-American styled format. This is problematic for at least two reasons.
- The date format isn’t machine readable out of the box, thus requiring some custom date parsing. Anyone who’s done date parsing knows how thorny it can be.
- Even worse, you can’t select any non-American date formats, thus leading to hundreds of non-Americans trying to figure out how to create custom Excel macros to get the date into their culture’s format.
Where the Solution Went Wrong
I think the team that implemented CSV export in MS Project went wrong in neglecting to ask “why is someone exporting to CSV?”
What’s the deeper need/problem to be solved here? The user is trying to import the data into another application! Thus, Project should export dates into a standardized, easily machine-readable format, or at least allow the user to pick one! This way a user in any part of the world can easily import and interpret a date into their application of choice.
The negative repercussion of neglecting to truly understand the need means a crummy user experience. Every user must carefully select a specific date format to export, export the data, import into the other application, and encounter potentially undefined behavior if the import went astray.
Resources for Getting Better at Asking Why
Daniel Ritzenthaler wrote an excellent article on how to achieve the same outcome as the five whys exercise, without pestering someone like you’re a toddler. A great read and highly recommended!
Another approach I’ve used is to confess that I’m starting from a position of ignorance and then asking the question — perhaps by saying so directly (e.g. “I’m coming from a position of ignorance in this field”), or using a cute metaphor (e.g. “pretend like I just beamed down from Mars and am new to the culture”). Context and familiarity with the people you’re interviewing will dictate which approach is more appropriate.
I’ve also been impressed with the jobs to be done (a.k.a. design thinking, but with a much better name) interview approach, which I heard via a great example on the Critical Path podcast.
What tools and tactics have you used to help understand the deeper need?
Resources for further reading :
- A description and example of the five whys technique.
- Designing for Growth, my favorite design book, which hits hard on the importance of understanding need.
- Daniel Ritzenthaler’s blog post about how to ask why without being annoying.
- A Critical Path podcast episode with an example of the jobs to be done interview approach, another way to discover need.
- A more abstract discussion of the jobs to be done approach.
- Two of Don Norman’s wonderful musings about design thinking and his thoughts on it after 25 years. Both, of course, touch on understanding need. Design Thinking: A Useful Myth and Rethinking Design Thinking