Design problem statements — what they are and how to frame them - Stories

The Microsoft Zune was not a successful product because it didn’t address any special design problems in daily life not already fulfilled by features in other products.

In 2006, Microsoft made a competitive move and released Zune, its version of the futuristic, one-buttoned, every-song-in-your-pocket iPod. The onscreen colors were punchy and the interface was type-led with a beautiful minimalist font. It was a bold move to challenge Apple, but in the world of product, success is not always about being first.

It could be argued that the Zune-only features, such as wirelessly sending a song from one Zune to another (an innovative feature in the mid-aughts) were just as good as the iPod-exclusive features, making Microsoft’s product a seemingly strong contender. But instead, it was a failure.

Why?

You could unearth countless reasons why the Zune wasn’t a success (and probably a pile of reasons why it should have been). One major underlying cause was that Microsoft had not identified a problem the Zune would solve. There were no clear user needs that the iPod was failing to meet or any new innovation that would shake things up. The Zune was solving nothing.

“If there is no problem, there is no solution, and no reason for a company to exist.” — Vinod Khosla, Khosla Ventures (a Silicon Valley venture capital firm)

What Exactly Is a “Design Problem”?

We’ve all had them, solved them, and most definitely caused them. But to put it in simple terms is a challenge in itself. The Oxford dictionary says a problem is “a matter or situation regarded as unwelcome or harmful and needing to be dealt with and overcome.” True, but this implies there is an awareness of the desired outcome. With all due respect to the brilliant minds at the Oxford Dictionary, this definition is missing an important component: unconscious desires.

Inventor of the automobile, Henry Ford, knew about this layer of desire when he famously said, “If I had asked people what they wanted, they would have said faster horses.” He knew that the unwelcome matter at hand was that horses were too slow. But this wasn’t really the problem that needed solving. There was a deeper need that his customers couldn’t articulate.

Henry Ford, and a driver of the first Model T

Richard Buchanan is a “design theorist” whose career revolves around human-centered design thinking principles. In his paper, Design Research and the New Learning, he alludes to a user’s unarticulated need when he defines design as “the human power of conceiving, planning, and making products or services that serve human beings in the accomplishment of their individual and collective purposes.” It’s the user’s purpose that needs attention, not simply an unwelcome situation. This deeper need is at the root of what a user desires, whether or not they can articulate it.

Ford’s customers thought they needed a faster version of what they already had. But Ford understood their deeper purpose: to get from one place to another faster. This distinction helped him avoid simply engineering a faster horse and instead opened the doors to create something that had never existed before.

A problem isn’t simply an unwanted situation or a matter that deviates from the norm — although these are still valid definitions of a problem. For designers and creative problem solving, a problem is an unmet need that, if met, can satisfy the user’s purpose.

Framing a problem brings focus to an otherwise busy landscape.

Why Frame a Problem?

Framing a design problem is the first step in a human-centered design process. It prioritizes the elements just discussed: the user and the purpose they desire to accomplish. This means that an initial round of user research can be revolutionary in uncovering deep-rooted desires. Conducting user interviews or desktop research, such as competitive analysis, can reveal insights into potential users and what problems they face.

For example, a design problem statement may be, “New mums need a way to feel connected to a support group because they spend a large amount of time alone with their babies and end up feeling isolated and lonely.” These mums have a deep-rooted desire to know they’re not alone, and a new product might help them accomplish the purpose of feeling connected.

A design team could develop an app, a social network platform, or even a brick-and-mortar venue where mums could gather. The problem statement would guide the team in navigating decisions and features, like, should we use AI? What other apps should it link to? How could the environment be designed? The framed problem provides a framework for crafting the best solution for the user.

By framing the problem with a statement narrow enough to bring focus yet broad enough for creativity, the product design team can stay simultaneously focused on design problem-solving and open to innovative possibilities.

Identifying Barriers and Opportunities

When you know the direction you want to go, you can see what’s in front of you. With a clearly defined problem that’s rooted in a user’s purpose, it’s easier to see what barriers are in the way of reaching that end goal. And if the problem is clearly stated at the start of a project, it can act as a lens through which to find additional opportunities that might have gone unnoticed.

Aligning the Team Around Design Problem Solving

Without realizing it, members of a team — stakeholders, designers, developers, and even users — each have a different image in their head of what the end product should be. They are each thinking about it in a slightly different way informed by different mental models. Arguably the biggest impact of framing a problem is how it aligns these varying views.

The process of framing a problem collects multiple perspectives within a framework that sparks effective conversations and decisions. Once an articulated statement is made, expectations for the team can be managed and efforts are aligned.

A successful product team is focused on solving a clearly framed, common design problem.

Guiding the Project and All Future Decisions

A product team can function without a problem defined — it happens all the time. But when an explicit statement declares what problem needs to be solved, every effort is focused on that single outcome.

A well-framed design problem statement that is documented as part of a product design brief is a simple tool to weigh options and measure success. A good design problem statement will leave room for creativity, but it ultimately provides a clear lens through which to view each element of the project.

Outlining the problem statement and the design process steps act as a filter that sifts out superfluous or irrelevant ideas and retains only the ones that meet the need. As the design process progresses, the team should refer to the initial problem statement and ensure that what is being designed still addresses the core problem statement documented in the product design brief.

“God gave us ten styluses … let’s not invent another.” — Steve Jobs on his distaste for the Apple Newton’s unnecessary stylus pen

Saving Time and Money in the Long Run

With a shared perspective and sign-off on the ultimate purpose of the product, the design process can run more efficiently. There will always be inevitable tangents and dead ends in innovative projects, but even these learnings can be more insightful when everything is driven by finding a solution to a single problem.

Working from a shared understanding of the design problem needing to be solved can also prevent public embarrassment — apart from a failed product. When Juicero launched its extravagant juicing machine, it was met with jabs and jeers because it charged a premium price for what anyone can do with their hands — squeeze fresh juice from a packet. It managed to raise $120 million in investments but suspended sales 16 months after launching.

Ultimately, the product brought very little value to juice-lovers because it solved a non-existent problem. Not every idea should be executed, and a well-framed problem statement can help determine which ones should just stay in the sketchbook.

Juicero offered pre-sold packets of diced fruits and vegetables that users plugged into its $400 machines.

Helping Connect Emotionally to the User

A problem can’t be defined unless you know who is struggling. By taking the time to conduct research and speak to potential users and ask questions about their current situation and how they feel about it, your team can suddenly step into the shoes of the user.

The emotional engagement needed at the problem framing stage aligns the product with the person it’s meant to serve. The user’s motivations, desires, and fears can create a framework for measuring all ideas and proposals. Seeing a problem from a human perspective will inevitably illuminate intuitive and emotional insights that will make a product more lovable.

How Can a Problem Be Framed?

Even though the benefits of framing a problem are significant, it’s often a skipped step. It’s not uncommon to receive a thoroughly constructed design brief that includes everything from visual direction and functional requirements. And sometimes that’s all you need when you join the team.

But if you’re at the beginning of a project and the visual and functional decisions are already being made, it’s worth taking a step back to define the problem the product is solving. Sometimes there is plenty of time to do this, other times there’s resistance and limited resources. Regardless of where you find yourself, there are methods that can help bring a level of clarity to everyone involved.

“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

The Four Ws: Questions to Answer

Ideally, this is a method that gathers key stakeholders around a pile of Post-its and a large wall. By asking four simple questions, everyone can put their own thoughts up and together synthesize the content to find focus and clarity.

Who is affected? Who is experiencing the problem? Can this user be further specified (by demographic, persona, motivation, reason for being in the situation)?
What is the problem? What are the struggles? What task needs to be accomplished? What pain point needs to be relieved?
Where does it happen? What is the context in which the user experiences the problem? Is it in a physical or digital space? Who else is involved?
Why does it matter? Why is this problem worth solving? What value does it bring to the user? What value does it bring to the business?

Empathy Map: Putting Yourself in the User’s Shoes

Empathy maps are a common tool used in UX design and can be helpful in many stages throughout a product’s development. Here, at the start, it instantly connects the team to the user to find out what their purpose might be. Depending on the amount of time you have for the problem framing stage, this method can involve user interviews and observational shadowing.

Hear and see. What kind of comments or concepts does the user encounter? What are others saying that the user is exposed to? What does the user observe others doing around her? (This category illustrates the user’s surroundings.)
Say and do. What are the user’s comments and behaviors? What is she saying out loud to others? What does she do in practice? (These are things that are explicitly done and can be clearly observed.)
Think and feel. What does the user think but keep to herself? How does she emotionally react to a situation? What are her desires? (These aren’t always apparent by simply observing a user, but can be revealed through conversational interviews. It takes some digging to understand what is happening on a subconscious level, but this is where great insights can be found.)
Pains and gains. What frustrations does the user have? What about the experience is unnecessary or disappointing? In contrast, what about the experience is improving the life of the user? What works well? Where or when is the user happiest? (These are the outcomes of the experience.)

Empathy maps help better understand the person the product is meant to serve.

The Final Problem Statement

This is a simple but really effective way to bring focus to the insights you’ve uncovered and the ultimate problem you can frame. The design problem statement structure template is like a page from MadLibs, a sentence with blank spaces to fill with your insights. It creates a concise statement rooted in your team’s collective thinking. It’s important to keep the statement specific enough so there is a shared vision for the product, but broad enough to allow for creativity and new insights.

Here are a few design problem statement example formats:

From the point of view of the user: “I am (persona) trying to (verb) but (barrier) because (cause) which makes me feel (emotional reaction).” e.g., “I am a new mum trying to take care of my baby in the best way possible, but I don’t know if I’m doing a good job because I’m always at home alone and don’t have anyone to talk to about it, which makes me feel isolated and alone.”
Drawn from user research: “(Persona) needs a way to (user’s need) because (insight).” e.g., “New mums need a way to connect with other mums because they are often at home alone during the day and feel isolated and alone.”
Using the 4 Ws: “Our (who) has the problem that (what) when (where). Our solution should deliver (why).” e.g., “Our new mum has the problem that she has no one to talk to about the best way to care for her baby when she is at home alone every day. Our solution should deliver a way for her to feel connected to other mums so she feels less isolated and alone.”

Every Good Problem Framing Phase, No Matter How Simple, Should:

Avoid proposing solutions. It’s easy to think in the tangible terms of features and functionality, but these will only distract from first understanding the fundamental problem.
Ask why. It’s a simple question to help find insights under the surface. But as Fast Company contributor Tina Seelig writes, asking “why” lets you see a situation from a different angle.
Reflect. Make time to step back and look for connections and patterns. This is where insights lie that can set a product apart from competitors.
Keep it universal. Avoid using jargon or any unnecessary complexities. The problem should be simple for anyone to understand, and ideally, to retell. Equipping team members to easily talk about what you are trying to achieve will build confidence and passion within the project.

Forget the Horse, Deliver a Car

What is a design problem statement? Some clients may set a brief that clearly defines the problem to solve. Others might not know about this crucial stage. Therein lies an opportunity for you to lead the client in taking a step back and evaluating why this product will exist. Together you can align the team, craft a framework, and kick off an effective and efficient process.

Perhaps the greatest value of this step is understanding the human psyche. Framing a problem from a customer’s perspective lets you more effectively deliver what people never knew they needed. Dave Thomsen, a former IDEO designer, writes that a human-centric approach leads to great user benefits and purpose.

When designers design a product that deeply connects to a user’s desired purpose, it becomes easier to build a product experience and a brand that connects to people on an emotional level. In turn, these will not only be more successful products but will prove to be more purposeful and meaningful in the lives of the people who use them.

Originally published at www.toptal.com.

This article is written by Jordan DeVos on UX Collective: Design problem statements — what they are and how to frame them