Who are we designing for?
Knowing your users and recognizing their diversity is key to successfully address their needs.
Reading articles about apps and UI design practices, I started thinking about why companies build their products the way they do it and if they consider not only who is going to use them but who they are designing for.
The most common answer is “We are designing for our users”, but most of the time that is not true. Products are built and shaped based on assumptions, beliefs, or even on requests from executives who are not actually the end-users of the product, nor who interact with it in their daily life. Many times, the need of the user is not necessarily considered, and the final result is something like this:
If we know that this happens, what can we do about it?
Well, the answer is actually pretty straightforward: go to the source and research with the purpose of finding out what is the real need and what problem your product is trying to solve. That sounds like a nice idea and simple to do, but the execution can sometimes become complex. It depends on the circumstances, your audience, your business domain.
Having direct access to your users is a great opportunity to see first hand how people benefit from our great ideas, but also how they undergo our errors and mistakes. It’s incredible to see how many assumptions can be proven wrong because we didn’t have the right point of view when we were designing or creating our product.
Talking with people allows you to see and understand the activities that a real-user does with your product, their environment, and in many cases some “hacks” or workarounds when they find something is not working as expected. Asking direct questions and receiving honest answers from a person that interacts with our product every day of the week for multiple hours is a great opportunity to understand what details are missing, the context of use and how the product can improve overall.
Imagine you work on a product for a spaceship; the only time you can test your product in real conditions is traveling to space. Likewise, when you work on a software app for finance or banking, it is almost impossible to shadow customers while they do their transactions in the bank office, especially considering that it is illegal in some countries, and most people will not trust having someone looking over their shoulder while they transact with their money. In these cases, the only way to test a product is in simulated environments or simulated tests.
Showing ideas and prototypes to real people in their daily context is one of the best ways to understand the highlights and flows of your product. Validating concepts allows you to design and create something based on your users' real needs and goals instead of only assuming them.
At the end of the day, everyone involved in product design and product development wants to understand and figure out new ways to help clients achieve their goals in an efficient, effective and timely manner.
