Why it is so important to solve real user problems?

autor Hanna Krupa, UX/UI designer

Let’s imagine you are a product owner and you have what some clients call “a killer app” - nice design, custom illustrations, and it's functional and user friendly. Altogether, it works like a swiss watch.

But have you ever asked yourself - “Would anything change if your product did not exist? Would users find another solution? Would they look for any other equivalent at all?”

“What problem does my product solve?” - this is the initial question for all stakeholders. But very often they are too preoccupied with the second part of the question “My product solves.” What if we take a step back and focus on the first part - “What problem?”


Why defining a problem is a key thing

Sometimes it is not that easy to define a problem. It can be a tricky process because it requires digging, deep research, analysis, seeking, and serious thinking through, unlike aimless ideas and hypotheses which easily enter our minds.

But the thing is, when the problem is revealed, it gives us the opportunity to look at it from different angles. We can release our minds from biased thinking and feel free to be innovative, creative and original. Therefore, if all our mental forces are directed towards a particular problem, all ideas and solutions will more likely hit the target.

It is important to brainstorm with a team because, even when you think the solution is found, it might not be a good decision in the opinion of other team members. Some features can take too much time to implement and it won’t be worth it in the end. Or, different development technologies require a particular way for the design creation process. All these details can be a real pain if they're not discussed at the initial stage with a team. Software development is a team game.


Moreover, team brainstorming can bring more features to your product. A feature is just a part of your product functionality, but when two similar products solve the same problem a specific can become the reason a user will prefer one over the other. So, one feature could be the crucial thing, which can give you an advantage over a competitor.

Sometimes we compile a backlog of features that our competitors already have, only because we think that nowadays this goes without saying. But users don’t use many of them because they just don’t need them. Instead of implementing a feature and trying to explain what problem it solves, wouldn't be better if we focus on the problem?

Any development costs money, so if the feature is not really useful. It simply means that the business loses money.

So, how can we be sure that we really solve our user’s problem when implementing features, and it’s not just another fancy button?

How to find our user’s pain

If you took any User research courses you’ve probably already heard this famous quote, which is often attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.” It means that sometimes our users can’t articulate their problems and simply don’t know what they need. If they did, we wouldn’t spend our time trying to define their problem.

Very often we ignore the User research phase because we have some assumptions which we believe can work out. But then we go to another extreme - associating ourselves with our users and designing products for us. Most likely our customers may have another opinion.

Today there are many UX research techniques that help to improve our understanding of the user’s needs. It’s up to you which one you choose:

● Observations (process of closely observing or monitoring a user's natural behavior without interrupting them);

● Field studies (participant observation in their natural environment, where they would most likely face the product or service);

●  Interviews (one-on-one discussion helps understand what the participant thinks about the topic);

●  Diary/Camera Studies (participants use the device to record and describe particular situations that are relevant to a product or service);

● Card Sorting (users organize items into groups and divide them into categories. This method is useful when it comes to defining information architecture);

● Surveys and Questionnaires (helps to gather a lot of information about large and diverse group of users;

The more you explore your users at the beginning, the more precise and accurate it will be. Now you can start designing first sketches, wireframes and clickable mockups based on the research. These are also great tools for testing the first rough solutions.

It is important to keep on working with your users and get their feedback at all development stages.

A huge amount of similar products and features make them look less meaningful and valuable. Besides, we spend a lot of time choosing which are most suitable for us from among all of them.