Don’t Solve The Problem That You’ve Been Asked to Solve!
As a designer, the first job isn’t writing solutions or coming to a conclusion.
Every design starts with a problem statement, and they can be as random and vague as possible. Now these problem statements come from different places. Sometimes a problem statement directly comes from a client, while sometimes its your team that comes up with it.
Sometimes, it’s the developers who tell you to solve something, and sometimes, it’s your parent who is stuck and confused about some Gen-Z technology! Every problem statement is unique, and every problem statement does not need to be ‘clear’ or ‘perfect’.
You can only come to a perfect solution, when you have a perfect problem statement — right?
Problem statement is, and has to be the focal point of the entire design process. If you really want to solve the problem, you should first clearly know the exact problem.
Decoding the problem statement
Many times the problem statement starts with vague and random sentences. And many other times, the problem statement isn’t even from end-users, but from project managers, business people, or just developers who analyse comments from the app-store or play-store ratings.
Usually the people who are using the product, are not designers or developers.
They come from varied backgrounds and have a set of experiences that define their expectations from an application or a digital product. When such people write their expectations, they cannot be translated into user problems directly.
You need to filter out a lot of redundant information from there, and re-write the problem statement to find a solution.
Let’s look at a play-store review of Instagram:
Instagram review on Google Play Store
The person here says that the new layout is a bit annoying with stories taking half of his screen, which is making him see few stories and few posts.
If you have to fix his problem, you might suggest to move stories elsewhere or to simply introduce an option to toggle the stories ‘on’ or ‘off’, just as this gentleman is suggesting here. If you write the problem statement just from this comment, it would be —
“Instagram stories take a lot of space on feed, because of which users are not able to see the feed, neither the posts, nor the stories — which is defying the purpose of putting stories completely!”
The solution to this problem can be either move stories elsewhere, or simply allow users to toggle them on or off as per their convenience.
But if you apply some design thinking here, and logically re-write the problem statement, you would not start with the statement itself, you would rather start with a bunch of questions first —
- Which device are you using, where you are facing this problem? Is it on web-interface or mobile-interface? (He has mentioned ‘app’, so it must be mobile’, but still ask!).
- Have you tried logging into your account from a different device, maybe the problem is solved there? (even if he has, there’s no harm in knowing the answer, right?)
- Do you have another account on Instagram? If yes, does the problem persist there as well or is it specifically on one account? (Why is this question even important? Well, I use two accounts on Instagram. One is business and other is personal, and very often on the business account I can’t see the profile image. It’s a black circle, which I don’t understand why. But sometimes, Instagram creates problems for one account and not other).
image credits: mixkit
Rewriting the problem statement
Just these few questions might tell you a lot more about the problem, after which the problem statement will change significantly. Let’s suppose you get to know that the user was using small-screen device, because of which he is facing issues with seeing less stories/posts.
Then the problem statement will now be specifically for those small device-sizes, and Instagram might then decide to update their users about the same, so that there’s no confusion.
Re-writing the problem statement is not only about knowing the ‘actual’ thing, but also gives you a deep context about user problems. If one user that has a particular phone is facing an issue, imagine how many others who have that same device might be facing the same thing?
Keep it simple, clear and concise
Your problem statement is not only going to be read by you, but by everyone who’s involved in the project. So, it’s essential to keep it short, clear and minimal. A problem statement is not a detailed description of user issues, but a to-the-point sentence that talks about user-issues and problems.
The longer your problem statement will be, the higher the chances that it might have useless and vague information. Make sure that your problem statement covers essential points only, like —
Problem statement simplified
This is a sample problem statement that talks about a fictional feature for Instagram feed, where users can toggle between stories and posts.
But as you can see that the problem statement can also have a lot of unnecessary clutter, that you should filter out before you come to the actual point!
So, don’t solve the problem that you’ve been ‘asked’ to solve. Find out the ‘real problem’ before you arrive to a conclusion or think about a solution!