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
“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
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
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
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.