Putting things into context
The world, as most may already know, is constantly evolving. Our planet, our society, our closest communities and even our own mentality can change overnight.
In addition, we live in a time when people no longer want to use something that does not match their needs or something that they feel compelled to use for a lack of choice. That time has passed! In fact, we hardly come across something irreplaceable, especially when we are talking about digital products (apps, websites, desktop systems, web systems, electronic totems, social networks etc.).
Now, let’s add this growing market demand to the need for products that really look at people’s real problems. Can you already tell why understanding who will use our products matters?
Okay, but, what does this have to do with design? Everything! As designers, we design products and/or services for someone, so that users can have the best possible experience.
How can we expect to do this without understanding what and, more importantly, who we are dealing with? Good thing HCD (Human-Centered Design or People-Centered Design, as I like to call it) is here to help us build viable, desirable, and business-friendly solutions.
What is HCD?
Okay, but what, after all, is Human-Centered Design (HCD) or, as it is also known, User-Centered Design (UCD)? Well, it is a design methodology applied in product development processes.
Essentially, UCD helps us create solutions that meet the needs of our users. Or, in the words of a very nifty author in the UCD field, Travis Lowdermilk, in his book “User-Centered Design”, “By placing users at the center of your development process, you remove ambiguity and get to the heart of what they need.”
Thus, we can understand HCD as a design perspective focused on solving people’s problems, putting who, in fact, will use our solution at the center of our processes and thoughts.
That means that HCD is about people, not Technologies. This point is so relevant that ISO 13407: 1999 itself, which defines the user-centered design process, now bears the name “HUMAN-centered design”, and no longer “USER-centered design”.
Although the process is essentially the same, this change in the name was made precisely to emphasize that we should think of people beyond what we would normally consider for users. For example, when we talk about speedboats on a beach, which user first comes to your mind? If you thought about who is piloting the speedboat, you got it! But that’s just the primary user of the speedboat.
The passengers of this speedboat are secondary users. We can also go further and consider the people at the beach and even people who are on other speedboats — they can be considered tertiary users.
We need to think about everything that can negatively impact people’s perception, even when they are not using our product. And HCD allows us to do just that.
Maybe you’re wondering how to actually get people into the center of the design process. Well, in HCD (or UCD), there are 4 Principles, which help us achieve this goal.
These principles can be considered activities, but are not necessarily linear. They are adapted to the project or product or service etc. Often, we can go back and forth between them. These activities are:
- Understanding and specifying the context of use;
- Understanding and specifying business and user requirements;
- Designing to solve the identified points;
- Testing the solutions and assessing whether they meet the requirements and contexts identified.
By establishing these activities in the product and service development process, we are ensuring that we are producing a solution that adds value to the business and the people who will be impacted by it.
Now, how about we learn a little bit more about each of these activities? I think that will facilitate understanding HCD.
Understanding and specifying the context of use
In this activity, we identify our users’ characteristics through research, so that we can understand who they are, where they are and what they are seeking to solve in their day-to-day life.
Additionally, we look to understand when they will use our solution: whether they are at home or on the street and what they are doing. This allows us to build personas for our products, empathy maps and user journeys, so that we can guide ourselves when designing our solution.
When we think about who is going to use our solution and, more than that, listen to that person, we can avoid mistakes and find failures and inconsistencies faster and more effectively. This decreases rework time and investment in development that would probably not bring good results, since developers, designers, PMs, POs, and other stakeholders have a clearer picture about who will use the solution.
Understanding and specifying business and user requirements
When we are talking about product development, we often specify lists and more lists of technical features and we end up forgetting to look at the goals and needs of the business and the user.
When we list functional requirements before identifying the business or user requirements, we are giving a solution before we understand the real problem or how its solution can bring value to our company.
By understanding business requirements, we look at the strategic goals that our company wants to achieve with a particular product or service. And, by looking at users requirements, we understand what activities they expect to successfully complete through our solution.
By listening to people, we can think of how to help the user interact more and better with what we are proposing. That way, we can find ways to decrease the chances that the user will be frustrated by not being able to use the solution or not finding what they were looking for.
Designing to solve the identified points
Once we understand who we are designing for — when and how these people use our product, what their real problems are etc. — and what our business goals are, we need to create hypotheses about how to achieve those goals and actually design the solution.
Developing something that does not add value can be very expensive, and, to avoid this, we build prototypes of low, medium and high fidelity. With them, we can move away from a broader concept and move on to a more realistic view of the final product, allowing the idea to be tested with the end user in parts.
At this point, we analyze everything we have to build the best possible product, also looking at the technical variables. Here, we should think about what resources are available to help us implement our solution, what its impact (in time and money) on the business are, and what technical options can help us get the user to reach their end goal.
Not just get to their end goal, but get to their end goal in the most intuitive way possible. As one of the big names in the UX (User Experience, in case you’re not familiar with the term) field would say, Don Norman, in his book “The Design of Everyday Things”:
“[…] when a device as simple as a door has to come with an instruction manual — even a one-word manual — then it is a failure, poorly designed.”
Testing solutions and assessing whether they meet the requirements and contexts identified
Now that we’ve defined what our product should look like, it’s time to take our prototype to our stakeholders. In this activity, we evaluate whether the solution we design actually meets the objectives of the business and seek to understand whether this product solves the user’s problem in the context in which it will be used.
At this stage, we gather feedback on the hypotheses we created and verify them (or invalidate them, which is also a positive thing). Thus, we can evaluate whether the solution achieves its goal and, mainly, find out what does not work before implementing it, thus avoiding a waste of resources.
Here, we develop usability tests to assess whether the tasks are being successfully completed, whether the user can find what they are looking for and whether the experience they are having is the expected one.
If we find that something doesn’t work or only partially works, we have the opportunity to correct the development path of our product (or functionality) before it reaches the market.
In the same line of thought, by verifying that solutions work, we can proceed with greater certainty that we are on the right path to offer a solution that will, in fact, help people and, at the same time, improve our business.
In addition, according to Dr. Susan Weinschenk of Human Factors International, a company known for implementing CXI (Customer Experience Integration), rework can be avoided 50% of the time with HCD.
Designing for the real needs of our users and businesses helps us take a more assertive and concrete path in our design and development process. This, in turn, helps us improve productivity of our product team (services, projects etc.), since we can avoid the rework that results from the implementation of an inadequate solution.
When we stop to listen to our users, we have the opportunity to find points where we could be nearsighted strategically. And, best of all, perhaps, our competitors may not have found these gaps either! That is, it can give us a great competitive edge.
By talking to real people who have real problems, we end up getting more insight into how to secure more loyalty. When we talk about loyalty now, we no longer mean simply buy-back action, we are talking about brand advocates, as already said the father of marketing, Philip Kotler, in his book “Marketing 4.0”.
In conclusion, the HCD process is continuous and pervades the beginning, the middle and the end of a solution. Therefore, it includes the process of development, as well as the team that will bring it to life.
So, even if everything is fine with the product now, we should always keep that vision, so that we can improve it and keep it alive and competitive in the market. After all, the world is constantly evolving, why shouldn’t our product change for the better as well?
Do you have any questions? Would you like to know more about some other topic in the field (or outside it, why not?). Tell us here in the comments.