A number of years ago I owned a Windows phone, much 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? After all, 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. Landline phone cords would only stretch so far! 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”
“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 within 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”
As we saw with the Window phone, a design that doesn’t solve a real problem, or solves the wrong problem is doomed to failure. This is why at Redgate (where I work as a product designer) there is as much focus on defining the problem, as on designing the solution.
The design framework used at Redgate is based on the Design Council’s Double Diamond framework. During the ‘Understand’ phase designers gather insights into possible problems to be solved. This can be through customer interviews, customer visits, surveys, analytics, and conversations with sales and support staff who typically have great visibility of the sorts of problems customers experience.
During the ‘Define’ stage designers will work with the product team to identify and define the problem to be solved. This will include being 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
A great way to define a target problem is through a problem statement. 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.
Let’s take a problem that I’m sure you’re familiar with as an example for building a problem statement. 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>.
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 agnostic. 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.
As we’ve seen 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”.