- What is human-centered design?
According to IDEO, human-centered design is the process in which we (as designers) understand stakeholders’ needs and create innovative solutions that can address those needs.
Human-centered design has three phases. The first phase is Inspiration, which focuses on understanding customers using several methods (e.g. interviews, guided tour, observation, etc). The second phase is Ideation in which we derive insights from the information collected in the first phase, brainstorm ideas, make rapid prototypes, test with users, get feedback, and iterate prototypes accordingly. In the third phase — Implementation — we make live prototypes, conduct pilots, assess resources, and many more to bring our solution to the world.
This may sound simple at first glance. However, one may make several mistakes when implementing this process. Below are three mistakes I have made in using human-centered design for the past two years.
2. Three mistakes in using human-centered design
a. Solving a non-existent problem
Before we go to the field and talk to stakeholders, we may assume that they have certain persisting problems. As such, we need to test these assumptions with them to identify the correct ones. Only after knowing the correct pain point can we brainstorm ideas and build solutions.
Want to read this story later? Save it in Journal.
However, it is likely that one does not test his assumptions with his stakeholders and goes on building a solution that is assumed to “work”. This may lead to the issue of a non-existent problem: there is no such problem existing and one may waste time and effort on building a solution that no one needs.
This problem happened to me and my team when we joined the Thammasat Tech Startup Competition 2019. Our idea was a platform to connect SMEs and micro-influencers in Thailand. Micro-influencers were usually defined as those having between 500 and 10,000 followers on their social media accounts.
For this idea, we had two assumptions: (1) SME owners were finding influencers to promote their products and (2) these owners could not afford the fee charged by macro-influencers, who usually had between 10,000 and 1 million followers. As such, micro-influencers could be the right solution, having a lower reach than macro-influencers yet a higher engagement with their followers.
We did not test our assumptions with our stakeholders (i.e. SME owners in Bangkok, Thailand having online channels to promote their products) to see if we were solving the right problem. What we did instead was to put a lot of effort into building the website prototype (e.g. creating the landing page, etc). Only then did we conduct interviews with our stakeholders to identify whether they wanted to use our platform.
The result was frustrating yet somehow predictable. After interviewing 10+ SME owners, we realized that none of them had the assumed pain point. Thus, there was no need for our platform.
We eventually gave up on this project. Nevertheless, failure always taught you something valuable. The biggest lesson I learned from this failure was to always validate my assumptions with stakeholders before building any solution.
b. Building a “perfect” prototype
For those who first know about human-centered design, the prototype concept may be unfamiliar. According to IDEO, a prototype is an early model of the final solution (i.e. the one will be launched in the market). The aim of the prototype is for designers to test something (e.g. the size of the product, etc) and learn from it to iterate and improve their design.
In my opinion, it is quite unusual that the final/official version of the product will be the same as the first prototype. There are often several iterated prototypes before one can build the final version that is ready to launch.
As such, the prototype isn’t meant to be perfect. Building a “perfect” prototype can have many negative consequences. The first consequence is the waste of time, effort, and money. Building an actual app may take weeks and months while building a simple prototype only takes a couple of days. By the time the former is tested with stakeholders, we can reach the fifth version of the latter. As it is likely that we have to re-design certain features of the prototype after testing it with users, the time to rebuild an actual app will be much longer than that for a scrappy prototype.
As a result, building a simple prototype can help us reach the final version (which satisfies stakeholders) in a much shorter time than building an early, perfect prototype. In a competitive startup world, time is often the crucial factor for startups to win the market.
The second consequence is the indefinite delay of the prototype testing phase. One may have the mindset of “waiting for everything to be perfect”. He is afraid that the prototype is not ready to be tested and keeps delaying the prototype testing phase. As such, it is likely that the prototype will never be tested.
I made this mistake when participating in the EdAbler Workshop series in the summer of 2019. I and my teammate came up with an application for Thai university students to learn about critical thinking skills. A perfectionist myself, I wanted to build an actual app rather than a simple prototype (e.g. creating wireframes on papers, etc).
As none of us had a technical background, we tried to learn coding to build the app. It was much harder than we thought and after the workshop series ended (the series lasted for three weeks), we were not able to build any app. Looking back, we should have built simple prototypes to test with our stakeholders and see if we should move on with this idea. If it worked, we would devote our time and effort to building an actual app later (or outsourcing this app to our friends in the computer science department).
This experience taught me that it was better to build something and test with stakeholders rather than waiting for everything to be perfect and not testing anything.
c. Asking stakeholders what they want to have in the solution.
In the Inspiration phase, when we talk to our stakeholders, we may attempt to ask them what features they want to have in the solution. Even though all stakeholders share the same pain point, they may have different requirements for the solution. As designers, we may try to satisfy all stakeholders by incorporating all required features in our design.
If the number of stakeholders is small (e.g. 5–6 people), we may be able to do this. However, with a huge number of users (e.g. 100+ people), it is (nearly) impossible to do so. In either case, it is not recommended to follow this route.
The biggest reason is that we may lose sight of the core problem that we are trying to solve. Some features suggested by our stakeholders may be unnecessary and can be eliminated without affecting our solution. In other words, our solution could address the core issue without having those features.
Let’s take my recent design project as an example. Regarding the problem that I was trying to solve, university students usually bought a lot of vegetables at once as they did not have time to visit the market frequently. However, due to several reasons (e.g. eating out, doing group work after class, etc), they could not cook as planned and their vegetables were rotten.
Thus, my idea was an application that allowed users to scan their vegetables and identify the remaining storage time of them as well as providing tips on how to keep those vegetables longer. Recommendations could be tailored to the type of vegetables being scanned and the remaining storage time of it. Using this app, users could prioritize which vegetables to eat and take actions to preserve their vegetables longer.
Some stakeholders suggested a feature that allowed them to search for general information about vegetables (e.g. general storage times, general tips, etc). This was different from vegetables that users bought and scanned using the application.
Even though this feature could help these stakeholders plan what vegetables to buy before going to the market, it did not help solve the problem that I set out in the beginning. If I removed this feature, my solution would still be able to address the issue of vegetable preservation.
How should we avoid making this mistake? From my experience and advice from an expert on social innovation, there are two things we can do. First, we should never ask stakeholders about what they want to have in the solution. The aim of an interview or observation is to figure out their pain points, the context in which they have those needs, their concerns/feelings, etc. These data points will allow us to design a solution that can address our stakeholders’ pain points.
Second, when it comes to feature prioritization, we should look at the problem we are solving, our key stakeholders, and the values our solution brings to them. Then we look at all features and see whether they satisfy these values. This process allows us to rank and prioritize these features. For features that fail to satisfy, we may eliminate them. It is always better to keep a feature that can solve the problem than an unnecessarily shiny one.
3. Conclusion
Human-centered design is a useful process for anyone wanting to solve problems, from the smallest problems to the seemingly unsolvable issues such as poverty and gender equity.
The process may seem simple at first sight. However, one may encounter several issues in using it. In this blog, I have illustrated three mistakes that I have made and ways to avoid them, namely (1) solving a non-existent problem, (2) building a “perfect” prototype, and (3) asking stakeholders what they want to have in the solution.
For you who have read my blog until here, I first want to say thank you. It is indeed a long read. However, I don’t want you to only remember these three mistakes after finishing reading. Remembering things won’t help you avoid these mistakes in the future. Trust me — I read about these mistakes before practicing human-centered design, thought that I could never go wrong yet still stumbled upon these issues later on. As such, there is no other way to avoid or correct these mistakes than constantly practicing human-centered design. Only then can you fully master the process and successfully solve problems.
