Almost all designers can tell you about their “design process”.
I remember my first encounter with digital product design was making huge cartoon faces of my potential users and put them on the wall to be reminded that I’m designing for real people with real needs and goals.
I’ve created personas, drawn fancy color-coded journey maps, affinity diagram, empathy maps to further show how much effort I am putting in in order to empathize with the user.
That’s probably the biggest lie I tell myself and have been told in my design career.
After the word “design thinking” rose to its buzzword status, it’s been abused by countless crash courses and unthoughtful corporate re-org towards “innovation-driven” culture. All are well-intended (perhaps) but prescriptive responses to the emerging importance of design without really comprehending what it entails.
this is called empathy mapping
an excerpt about having empathy when designing for others
It’s scary when you are literally bootstrapping a person, a “very rough” person, making dangerous assumptions about their needs and sufferings. Although we might believe that the suffering of our friends is just as awful as the suffering of someone from a different demographic or speak a different language. In reality, it’s a lot easier to empathize with those who are similar to us and those we see as more attractive or vulnerable. In this case, empathy clouds our judgments in pretty much the same way that any bias does.
Whenever an important and innovative idea spreads, it almost simultaneously loses its essence as people start distorting it for their own agenda. In software engineering, there is the “agile development process” or the “SCRUM” process that’s suffered a similar fate. I came across this piece and found this incisive critique on the “SCRUM” or “Agile” method:
Like a failed communist state that equalizes by spreading poverty, Scrum in its purest form puts all of engineering at the same low level: not a clearly spelled-out one, but clearly below all the business people who are given full authority to decide what gets worked on.
If you are interested, you can check out his full post here.
Seeing this post inspired me to write about some of the “design thinking” practices I found problematic used by institutions and companies of all kinds and sizes. The SCRUM process, when used improperly, threatens the product outcome and the overall well-being of the engineers. Similarly, the methods in the design process, when used without intention, can lead the product direction astray by not understanding or solving the “real” problem.
I want to quote one of my design mentors Kevin here, who gave me a pithy summary when I asked him about his take on design methods:
Design methods are all tools, and like any other tool can be useful in the right context. (i.e. “is wrench useful”). In general, though, I think they are widely used as crutches for
a) forcing consensus when internal teams get too large to effectively do design work as a group;
b) agencies selling deliverables;
c) things to talk about at conferences.
How then should we approach the design process then, if there are so many misinterpretations and misuse out there? If I want to become a designer or become design-centric, where should I start?
That’s why I’m dedicating a series just to this. I will attempt to re-examine the very definition of some common design methods like user research, creating personas, and journey mapping, how they lead to some common mistakes when making product decisions, and how to increase the likelihood of solving real problems.
More to come in part two.