The age old quip that common sense just isn’t all that common is well known. Just because it’s a cliché doesn’t mean it should be dismissed. In our profession as UX designers it should be a mantra we start with each day to help us remember that we need to capture different points of view in order to understand how we can create the best user experience.
As we are working with clients and users the most important thing we can do is not necessarily the design we make for them, but the discovery of what the problem is our design is supposed to solve. If we get the problem wrong, our design will be wrong even if it is the most elegant solution ever made for the problem we thought we should be solving.
Solving the right problem vs. solving the problem right.
For those of us that have worked on small teams, this doesn’t seem that important. There is a shared understanding (a common sense if you will) in small teams that often makes explicit discussion like this unnecessary. But if you have worked on large/distributed teams you know exactly what I’m on about. So many projects have failed because of the assumption of common sense.*
Last weekend I attended a super fun conference, the NortheastPHP conference. This was primarily because of the influence of the design agency Above the Fold on the conference program. There were many juicy UX and Human Factor talks. One of them was Joe Baz’s (of Above the Fold) talk on Ideation. He showed us a very useful tool to frame a problem:
According to [data] [customer] [verb] [problem]
This tool is useful in many ways.
First by having it we are reminding everyone on our team that it is important to frame the problem, it makes us stop in our tracks and not assume we all share an understanding of what the problem is and plow on.
Second it is useful because it forces us to think about who we are solving the problem for.
Third it requires us to demonstrate the existence of the problem with data. It’s not a good idea to start solving a problem just because there is a gut that had a feeling. If we can’t demonstrate it, the problem is not worth solving, there is no market for the solution.
“A problem is a fact.”
If you frame this statement with your team you have come a long way. Sometimes this may take days/weeks, especially if you need to do the research yourself to prove the existence of the problem. There are some projects that shouldn’t go any further because you can’t create this statement. So it is not trivial.
Another case where a statement like this is really useful is when you are deep in the implementation and you run into a snag. This may be a technical hindrance that makes it impossible for the implementation to continue. In those cases it is very easy for all team members to get fixated on solving the technical issue instead of stepping back and looking at the problem to find an alternative solution that still works to solve the original problem. It helps your team focusing on fixing the problem, not the solution so to speak.
Whichever tool you are using to frame your problem I would like to encourage you to always include the why.
Ask yourself: Why is this a problem.
As an example, here’s a Baz problem statement:
According to a survey administered by a respected authority on health issues 36% of married people are woken up at least 2 nights a week by their spouse’s snoring.
(I am making this number up but I can tell you that if you are married into my family this number is much higher).
Now some may look at this statement and think: This is unacceptable for the non-snorer! We have to help them sleep.
Others may think: This is taxing on the snorer. We have to help them stop snoring.
Still others may think: If the spouse is waking up, I’m betting there are others that can hear and are influenced by this. We have to reduce the noise level of the snoring.
If we don’t make different interpretations of the problem statement apparent different team members will be solving different problems. So ask everybody: Why is this a problem. Ask the product owners/managers, ask all the team members, ask the users. Not until you have asked everybody can you say that you have a problem statement. Skipping this step will lull you into a false sense of security.
This is very important. It will not only help you devise the right solution for the problem but get everybody off on the right foot. Subtle differences in understanding of the problem are not necessarily apparent at the outset of the project, they don’t become pain points until later when team members try to apply their understanding of the problem on what has been designed (or even created). It’s when the testers start testing their idea of the product on the product that the developers have submitted. It’s when the middleware developer starts hooking the user interface up to the underlying systems. It’s when the users start using the product that you team has produced. Then the questions start flowing in. The issue reports. The finger pointing.
It’s much easier to eliminate that from the start.
*This is the bane of many small startups as they grow beyond about 20 employees