Defining the Right Problem
Framing the problem, the need, or the request correctly begins the process that produces innovation, a step forward, and a positive difference for a product or service.
In 2005, the British Design Council formalized its famous Double Diamond design-process model. Most UX designers are familiar with it. One of the most interesting contributions of that important diagram was that its creators highlighted and conferred visual dignity on the first part of the design process. The part generally and improperly referred to as research occupies the first half of the entire Double Diamond process; it is the first of the two diamonds.
However, if you look at Dan Nessler’s revamped version this diagram, shown in Figure 2, you’ll see a title above each half. The first one is Design the Right Thing; the second, Design Things Right. Every request that designers receive that just asks them to design something right arrives too late in the process because it doesn’t consider the first half of this flow. In such requests, the stakeholder has already made many design decisions and project choices. Often, nondesigners have made these decisions, and they’ve already done the biggest part of the design work.
Such requests need to take a step back. The purpose of this step back is to give UX designers the opportunity to exercise their skill to achieve their most important goal: to innovate. Even in designing small functions or micro-interactions, the potential for innovation exists everywhere.
Taking that step back and challenging those already-made decisions won’t be an easy path. In many organizations, nondesigners make decisions, then involve designers when it’s already too late. The goal of innovation is not really the foundation of their daily work.
Jordan Devos, a design and strategy professional from New York, explains this simple concept in relation to product strategy. He describes how, back in 2006, Microsoft managers decided to launch a competitor to the Apple iPod. I assume that, at some point, a Design department received a request, or brief, saying: “We need to design this new MP3 reader that can compete against the Apple iPod.” The designers did an amazing job of designing that thing right, and the product looks really cool. But they probably didn’t have a chance to design the right thing. They couldn’t analyze whether the product was the right answer or maybe other solutions could have addressed the same need better—listen to music on the go.
If they would have approached the process from the first diamond, maybe they would have found a different solution—for example, an innovative online service for MP3 sharing and a player for smartphones. In 2006, this would have been quite an interesting innovation. Spotify was founded in the same year. Framing the problem, the need, or the request correctly begins the process that produces innovation, a step forward, and a positive difference for a product or service. Commercial success is the natural consequence of developing products in this way. A company adopting this strategy might fail once, even twice, but if they persist, their success is almost guaranteed. In addition to delivering commercial success for that company’s product, this process also provides greater value to customers and users. Promoting innovation-driven progress delivers value to everybody.
Nondesigners have the power and the responsibility to formulate amazing problems to solve and define appropriate requirements that can potentially result in a successful product.
Involving nondesigners in research and design activities is an important factor in the success of a product. But, as I said earlier, that’s not an easy path for either UX designers or nondesigners—especially in big organizations where everybody wants to apply a design-oriented process and implement an innovation-driven strategy. How the organization is set up, its structure, its history, its people, its culture, its limitations and strengths, but also the level of seniority of design stakeholders, the right design leader, and having managerial backup are all fundamental factors in making design impact within an organization. In a nutshell, knowing the organization and its culture is fundamental to the success of any innovation-driven approach in large companies.
I spoke a bit more extensively about this topic in my last talk at UX Vienna. Designers and nondesigners can create this positive wave of change, but there are many obstacles in the way, so it’s often a very hard battle. Figure 3 explains this challenge better than any words could.
Let’s look at a practical example. By now, you probably understand that nondesigners actually have an important role to play in designing the right things! The key to achieving this goal is simply a correct formulation of the design brief. A brief could be a list of requirements for a new product, a set of managerial inputs on a multiyear digital-transformation program, or the smallest user story—perhaps for a micro-interaction in a mobile app. Nondesigners have the power and the responsibility to formulate amazing problems to solve and define appropriate requirements that can potentially result in a successful product. If they do not, designers must send the request back and ask questions such as: What’s the intended business value of the product? How would this product benefit users? What is the problem we are trying to solve?
If the brief the designers received did not analyze the problem completely, it’s now up to the designers to define a meaningful brief. But giving designers an inadequate brief is counterproductive, inefficient, even dangerous. The nondesigners who create the brief should avoid making such mistakes and formulate the right problem from the beginning.
Now, let’s take a look at a practical example: a common technique for problem framing, the user story. Whoever writes the user stories for a product has great power in their hands—the power to drive the design and implementation of the product. But at the same time, there is risk in initiating a process that could just lead to great execution of a bad idea. A user story takes the following form:
As a [role, user, persona], I want to [action] so that I can [get a benefit].
As a user of my electric company’s Web site, I want to log into my personal account so that I can see when I have to pay my next bill.
This format works well because it’s simple and user centered and focuses the team on the user’s point of view—which teams all too often ignore. But, even with this robust framework, people can still write bad briefs. To avoid such mistakes, nondesigners could work collaboratively with designers when writing user stories, then ask themselves the following simple questions and compare their answers.
Did I start with the users and their needs in mind?
Try to solve real problems for real users. This can lead to innovation. But it’s important that you learn who your users really are by conducting good user research. Invest in user research; it’s always worth the money.
Did I write this story in an open-ended way that would let designers come up with multiple solutions?
Don’t describe a solution that you think is good. Write user stories in a way that doesn’t define a solution and instead encourage discussion. Good, even innovative solutions often result from collaboration.
Does this story push my preferred solution or design?
Even if the design you have in mind looks amazing to you, the designers on your team might not agree. Remember, you are framing a request for a product solution. That’s an important responsibility. Leave the design stage to the designers you’re asking to provide a solution.
Does my user story include a draft design that I created myself?
This is a tell. You’re defining a solution, not a problem. When this happens, I’m often tempted to start a conversation with the nondesigner that goes something like this:
Designer: “Then, why exactly do you need help from me and my team? It seems like you’ve already done everything yourself!”
Nondesigner: “No, no. This is just a suggestion. But actually, you should do it like this.”
Designer: “I think we need to make sure we understand and solve the right problem. From what you’ve written here, I have no idea what that might be. Let’s do some user research to understand users’ needs and try writing some user stories together.”
Does this sound familiar? If the nondesigner isn’t willing to take this more constructive approach, I suggest that you, the designer, withdraw from the project. Don’t waste your time and energies critiquing a bad design solution to which the nondesigner is already committed. The focus of nondesigners should be to explain user needs and requirements. That’s the key point of this article. At this point, I hope the reasons for this are clear.
Does the benefit in the user story describe real value, or have I just repeated the action?
The benefit should express real value—something that is important to your users. Using my earlier example, if you were to write that the user of the electric company’s Web site wants to log into his account so he can see his personal details, that would be just a repetition of the action. Dig deeper. A specific benefit that describes real value to the user unveils a whole new world of possible solutions that would meet the user’s needs. The benefit narrows the focus and clarifies the problem the user story is defining. Identifying the benefit is the starting point for building a useful product.
Does this user story deliver business value?
The problem you are stating should have value to the business, too. User stories should express value to the business. If a user story describes a useless improvement to the company’s Web site, for example, with no backup from analytics data, discard it. Don’t waste time and money developing useless features. Challenge whoever requested the so-called improvement.
Nondesigners can ensure they create good user stories by asking these simple questions. The example I’ve provided shows how to use this popular problem-framing tool correctly. You can also use other techniques such as the 4 Ws to achieve correct problem framing.
Please take away the importance of the need for nondesigners to give UX designers good, meaningful briefs from this article—especially if you are a nondesigner. Not only can a good brief address user needs, it can also spark innovative solutions. Providing a good brief is the only way nondesigners can make a fundamental contribution to designing the right things, which is the beginning of the path to real innovation.
Blitzer, Julie. “Cross-Cultural, Multilingual, Localised, Global Design.” YouTube, November 12, 2018. Retrieved July 5, 2020.
Design Council. “Eleven Lessons: Managing Design in Eleven Global Brands: A Study of the Design Process.” (PDF) Design Council, undated. Retrieved July 5, 2020.
Design Council. “What Is the Framework for Innovation? Design Council’s Evolved Double Diamond.” Design Council, undated. Retrieved July 5, 2020.
Devos, Jordan. “Design Problem Statements: What They Are and How to Frame Them.” Toptal, undated. Retrieved July 5, 2020.
Jane, Caroline. “How to Write Meaningful User Stories.” Medium: UX Collective, October 30, 2019. Retrieved July 5, 2020.
Nassler, Dan. “How to Apply a Design Thinking, HCD, UX, or Any Creative Process from Scratch.” Medium, May 9, 2016. Retrieved July 5, 2020.
Reuter, Christian. “Writing Effective Problem Statements.” Thoughtbot, March 21, 2018. Retrieved July 5, 2020.
Zurlo, Francesco, Raffaella Cagliano, Guiliano Simonelli, and Roberto Verganti. “Innovare con il Design: Il Caso del Settore dell’Illuminazione in Italia.” Paper, 2002.