Why every design should start with the problem
5 minutes read
A number of years ago I owned a Windows phone, like the one shown below. At first I loved my Windows phone, I really did. It felt great to hold in the hand (much better than a slippery iPhone). It had a great screen and battery life. It had a very intuitive interface and what’s more I paid significantly less than I would have done for an iPhone. Alas, like I suspect many Windows phone users I soon fell out of love with my new phone. You’ll find out why in a bit…
With a good design, a good price, good marketing and a strong brand you’d have thought that Windows phones would have been a roaring success with consumers. But you’d be wrong. If you’re reading this article on a mobile I’d wager that it’s extremely unlikely that you’re doing so on a Windows phone. I can confidently say this because like me, and I suspect also with somewhat of a heavy heart Microsoft abandoned the Windows phone a few years ago.
So why did the Windows phone fail? Afterall, it was well designed, well priced and well marketed, usually a winning combination. The answer lies in the problem that the Windows phone was trying to solve, rather than Microsoft’s well designed, well priced and well marketed solution. You see, in the past when someone bought a mobile phone it was to be able to be in touch when out and about. A well designed, well priced and well marketed phone would be a winning combination. However, the problem has changed from:
“Without a mobile I can’t phone or message when out and about”
To…
“Without a mobile I can’t access Facebook, check the news, listen to music, watch a movie, write a note to myself, play a game, ask Google etc… when out and about”
Mobiles are no longer bought to make phone calls but to run apps. Indeed, it’s estimated that most people have about 80 apps on their mobile and use close to half of them each month.
Unfortunately, Microsoft was never able to persuade many application developers to build Windows phone apps, meaning that there were never many apps available. Being unable to run Android or iPhone apps, the Windows phone was doomed to failure because it no longer solved the user’s problem. Sure, it allowed users to make phone calls, to send and receive messages and emails, and to access some of their favourite mobile apps but crucially not all of them. If only Microsoft had better focused on the problem, they might have found a better solution (like an Android based phone with a Windows like UI).
Falling in love with the problem
“Great designers don’t fall in love with their solution. Great designers fall in love with the problem”
Jared Spool
A design that doesn’t solve a real problem, or solves the wrong problem is doomed to failure (as was the case with the Windows phone). This is why all good design processes, including the well known Double Diamond process (shown below) have a discover and define phase. This is where designers should gather insights into possible problems to be solved and really drill into the problem to focus on. It’s where as a designer you should be falling, head over heels in love with the problem. And before you say, “but that’s the job of a researcher”, take a look at my previous article titled why designers should research, and researchers should design to find out why gathering insights into the problem is as much a job for designers, as researchers.
I won’t cover how you can best discover and define the problem in this article because that’s a pretty big field called UX research, but suffice to say that whatever approach you take you should be able to answer the 5 Ws:
- What is the problem?
- Who is affected?
- When does it happen?
- Where does it happen?
- Why does solving it matter?
The last one – “Why does solving it matter?” is the most important because if a problem is not really a problem, merely a minor annoyance, then it’s unlikely that any solution to that problem will provide sufficient value to be adopted.
Defining the problem
Having discovered possible problems to solve and identified the problem to target it’s important to define that problem. The double diamond process refers to this as the ‘Problem definition’. This helps to establish a shared understanding of the problem being tackled and provides a point of reference to judge potential solutions against. It allows us to ask the very important question, “Does this solution solve the problem?”. If the answer is no, then it’s likely that this is the wrong solution.
A great way to define a target problem is through a problem statement. Let’s take a problem that I’m sure you’re familiar with as an example. The dreaded pain of filing paperwork!
If you’re anything like me you know that you should be regularly filing important papers that you collect or get through the post, but rarely if ever get around to doing this. Before long a large pile of papers grows somewhere in your household and when it’s time to find some important information, such as for the dreaded annual tax return, what should be a simple job becomes a nightmare hunt for long lost paperwork.
What is the problem?
It’s hard to find important documents, or at least the information contained within important documents because they are rarely filed away and invariably have to be laboriously browsed by hand.
Who is affected?
Everyone who gets and has to retain and use important documents for future reference.
When does it happen?
On at least a monthly basis when important information, or important documents are required. For example, for annual tax returns, for paying invoices and for claiming expenses.
Where does it happen?
Usually at the home, but sometimes at the office.
Why does solving it matter?
Because filing is so painful that few of us will undertake it, even though the consequences of not being able to retrieve important documents and information can be very serious.
Using a problem statement
As the name suggests a problem statement is simply a statement describing the problem. Take a look at Design Problem Statements – What They Are and How to Frame Them for some formats that you could use. I’ve found the following format to work well:
We know/believe that <problem>. This is a problem because <why important?>. Our solution should enable <users> to <goal / job-to-be-done> in/with <target performance>.
For example:
We know that important documents are not always filed away or even retained. This is a problem because information within documents might be required in the future, such as for tax returns. Our solution should enable document recipients to retrieve important information held within documents in less time than present.
The problem statement should be solution agonist. Remember, at this stage we are not defining the solution, rather the criteria by which the solution will be judged. In this case we want a solution that will allow document recipients to retrieve important information in less time than present.
Armed with our problem statement we can start ideating and exploring possible solutions, such as a document scanning service or a mobile document scanner app, such as Tiny Scanner. We can ask the question, “Does this solution solve the problem?” and ensure that we’re starting with the problem, not the solution.
Conclusion
As was the case with the Windows phone, a design that doesn’t solve the right problem, or solves a problem that is not really a problem to start with is doomed to failure. Before creating any designs, you should ensure that you understand and have defined the problem being solved, for example using a problem statement. This will not only help to build a shared understanding of the problem, but also provide focus for the rest of your design process. In the words of Albert Einstein:
“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions”.
Albert Einstein
See also
- Design Problem Statements – What They Are and How to Frame Them (Toptal)
- How To Define A Problem Statement: Your Guide To The Second Step In The Design Thinking Process (Career Foundry)
- Writing effective problem statements (thoughtbot)
- Define the problem statement (Komodo)
