“Design the right things versus designing things right.”
About five years ago, I began hearing this expression more frequently. At that time, I was in the middle of an exciting, mind-changing experience: my company had given me the chance to relocate to Vienna, Austria. From one day to the next, I had landed in another city, in another country, with people speaking another language. I was completely out of my element. Most importantly, I started working as an insourced designer at an international bank that was a client of my design studio.
I wasn’t alone; a team of colleagues had already been there for about eight months. In those first days, I carefully observed how the design team laid the foundation for all their activities. How the Head of UX and the other senior designers were dealing with new requirements coming from stakeholders was very interesting to me. They often challenged those requirements—sometimes quite rigorously. Having arrived with a consulting-oriented mindset, that was a bit surprising to me—although my design studio, Digital Entity, has always supported challenging the requests and briefs coming from our clients, with the aim of designing the best possible experience for users. But my perception changed a little once I had started working as an insourced designer. I was now able to see how clients generated the requirements.
Champion Advertisement
Continue Reading…
The first time I heard that expression about designing the right things, I immediately connected it with the ability to challenge a requirement that comes with a ready-made, often disputable design solution and take a step back and rethink the request with the aim of finding the right solution. That’s the basic idea, but there’s much more behind it.
Brief Versus Concept
Two years ago, I attended the World Usability Congress (WUC) in Graz, which was a very interesting meeting point for UX designers from all over Europe. During a talk about the localization of design, Julie Blitzer, currently the Digital User Experience Manager at an important Italian design studio, described the real experience of a client giving a design team a brief something like this: “We want to build an app for the students of this city so they can find the best events in town.” I’m sure those of you who are UX designers have experienced briefs similar to this many times. But is this really a design brief ? It sounds more like a concept. Understanding the difference is fundamental because these two terms are not interchangeable.
A design brief is basically a list of requirements; a group of requests that relate to the problems one wants to solve. A concept, on the other hand, is a unitary response to those requests, as depicted in Figure 1. It is a product, a user interface, an object, or an entity that aggregates and embodies solutions to all the problems that the stakeholders described in the brief. There is a big difference between the two. The work of design exists entirely in this difference: finding innovative solutions to problems, creating concepts, and developing innovative products. A brief is something that nondesigners can—and should—produce. We call these nondesigners business stakeholders, clients, product managers, product owners, business analysts, bosses, unit managers, and so on. The brief is the formulation of their requests.
Figure 1—Requirements in the design brief become design concepts
In contrast, a concept is something that designers create. The brief is singular, while the related concepts can be multiple. Designers can find multiple solutions to the same problem.
Let’s look at another example. My team is currently working on design maintenance for a mobile application. We support rollouts and design new functionality on the basis of a solid design system. We frequently receive so-called briefs such as “place a button here for function A” or “put a label there to start function B.” Are these design briefs or concepts? They already refer to a solution, but nobody knows if it’s the right solution. In such cases, there are already concepts when there should be just briefs.
How does a product team—comprising both designers and nondesigners—provide the right design solutions to problems? Simply by understanding the right problems. That’s exactly what I mean by taking a step back.
Defining the Right Problem
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.
Figure 2—A revamped version of the Double Diamond diagram
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.
Involving Nondesigners
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.
Figure 3—The difficult path to innovation
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].
For example:
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.
Conclusion
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.
Zurlo, Francesco, Raffaella Cagliano, Guiliano Simonelli, and Roberto Verganti. “Innovare con il Design: Il Caso del Settore dell’Illuminazione in Italia.” Paper, 2002.
Jacopo has more than 14 years of international experience in planning, leading, and delivering design projects. He supports companies by designing services that provide excellent user experiences and creating digital touchpoints that lead to conversions. His higher mission is to create a better world for users. Jacopo holds a Master’s degree in Industrial and Product Design from the Politecnico di Milano. Read More
