“The first step in solving a problem is to recognize that it does exist.” – Zig Ziglar
Product definition is the cornerstone of our entire product and sets the stage for the success of our product. Every solution we design builds upon the framework of this initial problem.
That means we need to start with a problem that we work to understand and define–carefully. Otherwise, we risk clinging to the first problem that feels right. And we all know how that ends.
Photo Credit: Marcin Treder, UXPin
Let’s go through the process of designing an app around a problem. Since it’s always fun to be a designer on a project that deals with a problem you can relate to, I’ll choose a problem experienced by myself and the majority of people I know.
The problem of having too much stress.
I did some quick and dirty research by calling up a dozen friends and asking if it was a problem they felt they also had. 9 out of the 12 people said they experience the same problem. I suspect 3 of those 12 people are super-secret Zen monks.
Of course, I didn’t have to call them up. I could’ve just sent this 5 minute survey (which you can feel free to take too) to get a sense of the problem.
Now that we have perceived a problem to design an app around we can define it in a problem statement, or definition — a statement that captures the scope of the problem we are trying to solve.
In this piece, I’ll dive deep into how to write a well-crafted statement that communicates the right problem to the team. The next time you come up with a great product idea (or get feedback), follow the steps below to make sure your heart and mind are in the right place.
Perceiving the Problem
Adapted from: Danielle Elder, Creative Commons 2.0
As a designer fortunate enough to get to work with some incredible teams building mobile apps, I get to hear a lot about what other people think about the way many apps are designed and function. There are so many great examples of well designed apps available, it makes finding inspiration easy and enjoyable. Not every app is a pillar of stellar design though, every now and then I hear about one that got everything wrong.
Recently my wife was telling me about an app she was trying to use to assist her with some of the fun things associated with newborn humans, and said:
“This is a bad app.”
My designer’s ears pricked up at the sound of a problem.
“What’s that dear? You have a problem that needs solving?”
“No, I’m trying to tell you a story. Can’t you just empathize with me and let me finish?” she probably implored.
“Of course I’ll help you!” I exclaimed. “First we need to understand your perceived problem at a deeper level.”
An audible sigh came from somewhere in the room.
Many people don’t know how to begin solving their user’s problem because they don’t take the time to listen and really consider their problem. This is usually true not because the person is lazy, rather they just don’t know how to go about thinking about the problem on a deeper level in an effort to understand what is causing it. The design process has to start somewhere though, and that starting point is usually our perceived problem. The perceived problem my wife was having (apart from my listening and empathizing skills) was that the app she was trying to use was a bad app.
To recap, here is what we need to do when a problem is perceived:
- Acknowledge the problem. First things first, we must understand that there is a problem. You can’t solve it without saying that it exists. Brushing it under the rug does nothing for you or for your users.
- Listen and consider. Don’t just jump to wanting to solve the problem. You have to listen to your users — think about my interaction with my wife — to really understand what’s going on. Asking follow up questions is fine, but don’t just try to suggest a solution before you really understand what’s going on.
Let’s go back to our original problem as an example: I have too much stress.
Well, the problem of having too much stress is probably too general to design a solution around. As is the problem of an app being bad. This is where you need to probe deeper, asking more questions: How many ways can you fix a bad app? All the ways probably. How many different ways can you think of to manage stress? Are overall app design and amounts of stress our real problems, or are they symptoms of deeper problems?
Learn more: The Skeptical Designer’s UX Process.
What Are the Symptoms?
A symptom is a subjective departure from normal function or feeling which is noticed by a user.
For example, the feeling (feelings are subjective, not objective) of being tired (departure from the normal of being awake during the day) is a symptom (a subjective departure from the norm) of not getting enough sleep.
Adapted from: Eamon Curry, Creative Commons 2.0
Our feeling of too much stress is a subjective departure from our normal function of not being too stressed. It also has many different ways we could deal with it, such as having a glass of wine at night, or a bottle, or listening to music, or watching TV. Maybe you know someone who has huge meltdowns and throws tantrums as a way of letting off steam. Maybe you sit in a quiet place and breathe deeply and try to figure out what is causing you to feel stressed. Many people don’t even recognize that they are stressed, which means it’s not easy to recognize what is causing it.
Is having too much stress really our problem? It seems like it is just a symptom of a much deeper problem. In order to solve the perceived problem of having too much stress, we need to think about the problem to determine if it is a root cause or merely a symptom of something deeper.
What is the Root Cause?
Why is it important to find the root cause of the problem? It’s important because solving a symptom isn’t a permanent solution.
For example, if your leg hurts you could take aspirin to dull the pain, but you will not be fixing the root cause of the pain. You will continue to experience the pain which is a symptom of the real problem.
If you went to the doctor complaining about the pain and she determined that your leg hurt because you broke a bone, you could address the broken bone, which is the root cause of the pain problem.
So how do we determine the root cause of our perceived problem of too much stress? We can use something developed at Toyota during the design of its manufacturing methodologies known as the Five Whys Technique.
The Five Whys Technique
Adapted from: Jeffrey Pioquinto, Creative Commons 2.0
The Five Whys Technique is an iterative question-asking technique we will use to explore the cause and effect relationships underlying our perceived problems. This will enable us to find the root cause of our perceived problem. What was my wife confused about again? Something about an app she was trying to use, I think.
“This is a bad app. Also you could do a better job at listening to me when I’m trying to tal..”
..oh yeah that’s right. She couldn’t figure out how to use a productivity app to help her manage some of the fun things that are associated with having a newborn. Things like the amount of poopy diapers, ounces of milk consumed, etc.
In an effort to identify the deeper problem with the app I suggested we go through the Five Whys process.
- Why is it a bad app?
…because it doesn’t work the right way. (refined problem)
- Why doesn’t it work the right way?
…because I don’t understand where to go. (refined problem)
- Why don’t you understand where to go?
…because none of these icons make sense. (refined problem)
- Why don’t the icons make sense?
…because they don’t take me where I think they should. (refined problem)
- Why don’t they take you where you think they should?
…because some of them that I think are icons, actually aren’t, and the ones that are icons aren’t ones I’ve ever seen before. (alterable behaviors identified)
Created in UXPin
The root cause of my wife’s problem has been identified very quickly, which I can send to the app’s design team as actionable feedback.
How can we be sure we have identified a root cause? The key to understanding the root cause of the problem (it isn’t always answered with the 5th why) is in identifying a broken process or an alterable behavior. Sometimes there are more than one you will identify, like in the app we are going to design to help with the problem of too much stress.
- Why do I have too much stress?
…because I have too many stressful thoughts. (refined problem)
- Why do I have so many stressful thoughts?
…because I can not calm my thoughts. (refined problem)
- Why am I unable to calm my mind?
…because I don’t practice calming my mind. (refined problem and alterable behavior)
- Why am I unable to practice calming my mind?
…because I don’t have a process to calm my mind. (broken process identified)
- Why do I not have a process to calm my mind?
…because I’m not aware of myself enough to know I need one. (deeper broken process identified)
Created in UXPin
The root cause of the perceived problem of too much stress is a lack of process to calming and focusing our mind. In this example, calming my thoughts would lead to less stress, which solves the original problem. We can evolve our problem definition now.
Learn more: Free e-book UX Design Process Best Practices.
Redefining the Problem
New Problem Definition:
To enable users to calm their mind in an effort to reduce their stress.
What about the deeper problem of not being more aware of our true self? Sometimes a product will benefit from attempts to solve a deeper broken processes than may be necessary. By designing a solution with a deeper and more abstract problem definition we should still be solving the original symptom with the benefit of solving additional symptoms.
Throughout the design process we will continue to evolve the problem definition, so if we find we have gone too deep we can abstract back up one level. Let’s go ahead and redefine our problem definition:
Redefined Problem Definition:
to enable users to become more aware of themselves in an effort to reduce their stress.
Photo Credit: Kevin Dooley, Creative Commons 2.0
Here are a couple of ways you can probe deeper into design problems with your team, as discussed in the e-book The Guide to UX Design Process and Documentation:
- Brainstorm on the problem. Get your team together on the perceived problem, having everyone on the team — from designers to developers to marketers to business analysts to sales — participate. Now while it’ll be up to the designer ultimately to solve the design problems, teammates from other departments can provide other insights that will help frame your work. After all, sales may be closer to users and have a deeper understanding of their problems while a business analyst may have insights into the market.
- Researching the problem. You can conduct a competitive marketing analysis to determine if this problem is being faced elsewhere. You can also conduct a customer survey (like the one we did earlier on stress). If it’s an existing product, dig through your analytics, heuristics, content, or conduct users tests.
Doing these things will go a long way to getting to what’s causing your problem, its root cause and how to solve it.
Learn more:
3 Mobile App Problem Statements Done Right
Let’s take a look at a few apps and their problem statements:
1. Enlight
According to Stav Tishler from Enlight, their mobile app’s problem definition is:
“To empower the mobile photographer with creative tools, that until now, were reserved only for professionals and only on desktop.”
Enlight solves this problem through the careful design and technology. Lightricks’ proprietary image processing engine powers the tools that are tied together with a consistent UI that allow the users to transfer the knowledge they acquire by learning one tool, to other tools.
2. PureChat
According to Hamid Shojaee, Pure Chat CEO, their mobile app’s problem definition is:
“To enable small business owners who are on the move to be able to communicate with visitors on their websites.”
Maintaining 4.5 stars on the Apple and Google mobile app stores is a pretty good indicator that they have designed a great solution for the problem they set out to solve.
3. Crowd Mics
According to Tim Holladay, Crowd Mics CEO, their mobile app’s problem definition is:
“To enable users who have a voice to be heard in the conference, meeting or any live event in which they are attending.”
Crowd Mics turns the users’ smartphones into wireless microphones for use in live events.
Conclusion
By dedicating some time to thinking about the problem your product aims to solve, you will define a strong foundation for all your future design decisions.
- Start by making a list of the problems you perceive that you plan on solving with your product and combine them into a problem definition.
- Next take some time to think deeper about the problem definition with the 5 Whys.
- Finally discuss the problem with any of the product’s stakeholders and re-evaluate the problem, iterating on the problem definition if it needs further clarification.
Once you write a really strong problem statement, don’t feel like you’re married to it.
As you go along the design process, you may have to redefine your problem. That’s because you’ll discover things that weren’t apparent in the early discovery stage of the process.
For more UX advice, get the free guide UX Design Process Best Practices.
