Design is the art of being wrong safely
Design disciplines such as graphic, UX, and content design all share a core feedback loop that requires psychological safety to generate value and breaks down when it isn’t safe to iterate.
UX Designers (myself included) bristle at the implication that design is all about drawing pictures. Design is not just visual, we say. But statements about what design is tend to be very vague: design is the rendering of intent, design is making decisions, design is Doing The Right Thing and The Right Thing To Do.
These definitions are self-defeating — pretty much everyone likes to think of themselves as making good decisions and doing the right thing! 30 years of designers changing their adjective from “graphic” to “web” has not meaningfully shifted the layperson’s perception that designers are downstream of the decision-making. The truth of the matter is that in most companies, this is accurate: an executive (or another stakeholder from “the business”) makes big decisions, and designers illustrate them.
And to change that state of affairs, we need to articulate what it is that design actually does.
Why call it design?
“Design” has caught on when we talk about making good decisions in software. We talk about user-centered design and design thinking rather than “user-centered engineering” or “developer thinking” (even if most people can’t define design thinking beyond “thinking like a designer”). But the pieces of what we now call user experience come from all over the place: computer science, human-computer interaction, cybernetics, management consulting, psychology, political science, and anthropology.
Only design was able to incorporate these concepts into a coherent whole — and hence become “user experience design”. This would have been impossible if design was nothing more than the crafting of images. It happened because design already had the conceptual framework required to recognize and employ these tools: the design process.
The design process is common across all design disciplines, from traditional graphic and industrial design to today’s UI, UX, product, and content design practices. What unites them is the nature of the problems designers solve: wicked problems, problems in the world rather than on paper, socially complex and with no clear boundaries or solution conditions. The design process uses a feedback loop to define the actual problem by producing speculative artifacts (a practice that software engineering re-discovers every few years as “provotyping”). These artifacts often look like sketches or low fidelity versions of the final “deliverable” artifact that the designer will eventually hand off.
Being wrong safely
On the surface, the design process looks a lot like Agile software development. You spend a little bit of time producing something, then see whether it works well, and use that information to shape the next version. But there is a major difference: the developers are intending to be right, and the designers are intending to be wrong. This is because the developers have a very clear picture of what “right” looks like: the feature requirements. The definition of “value” has already been framed and the work is to deliver it to the customer.
By contrast, the designers are framing their problem as they go. It is not possible to solve a wicked problem on the first try, because you can’t tell whether your decisions are right or not. Instead of starting with the shape of the intervention itself, designers start by shaping the problem space the intervention is meant to address. By the time we have defined “right” rigorously enough that we can try to start being right, we have already made (and tested) all the important design decisions, and the work ahead is mostly documenting the ones that worked. Until that point, the objective of design iterations is not to “deliver value to the customer” but to deliver learning to the team.
From the early days of design school, we are taught to produce many cheap, quick, incomplete artifacts, and then bring those artifacts to public critique, where our peers already understand that these artifacts are cheap, quick, and incomplete. The critique seeks to help the designer refine their design decisions; designers are often expected to bring dozens of sketches so that the critique can focus on the one or two promising ideas among them. So a designer’s reputation doesn’t suffer from showing “bad” artifacts in critique. It is safe for designers to bring “bad” design decisions to the critique, because everyone else is going to be doing the same thing, all the time. Design culture is a culture of psychological safety.
“Being wrong safely” extends to audience research (what we in software usually call user testing). Participants don’t lose trust when a designer presents a low-fidelity or incomplete speculative artifact because they weren’t expecting to be handed something new that they could use. Instead, the artifact prompts them to talk about what they would like to see in the parts that are missing. The information gathered this way goes through a process of synthesis and serves as a foundation for further design decisions.
Design outputs are not design outcomes
Peer critique and audience research are extensions of that common design activity: sitting at your desk or standing at a whiteboard and sketching illegible doodles. In the same way that the solitary activity answers “does this design decision make sense within my conceptual model,” the critique answers “does my conceptual model make sense within our scoping of the opportunity” and the research answers “does our scoping make sense within the user’s context.”
Designers get answers to these questions by being wrong in different ways for an extended period of time. If the organization the designer works for has not made it safe to be wrong, these questions cannot be answered within the design process — only by releasing software (and suffering the consequences of bad software: lost revenue and user trust). But these organizations don’t understand the design process, and so they see no other way to learn.
I’ve worked with many teams who were afraid of showing something to their customers until they were 100% sure that it was “ready.” They sought out stakeholders who would set their definition of “right” by providing imagined problem definitions and solution requirements. The designers were told to skip directly to high-fidelity prototyping — attempts to test the stakeholder’s conceptual model against the problem were shot down because the stakeholder’s reputation for knowing the right things was on the line. The visual fidelity of the product outstripped its conceptual fidelity and created a false sense of certainty in that knowledge.
When the software shipped and failed to help users, the company lost a lot of money and a lot of customer trust. By trying to avoid being wrong at all, these teams made it a lot more expensive to be wrong, and reduced their chances of being right. And the designers got the blame for doing a bad implementation of their stakeholders’ brilliant ideas.
Designing design culture
It’s tough to kickstart design culture from zero. Giving and receiving critique are both skills that have to be learned; critique only works when it is directed at the artifact and not at the person presenting it. For someone on the receiving end of critique, being vulnerable is not something that comes naturally. People who are not used to being vulnerable in this way see critique as something inflicted upon them by gatekeepers. And because they only have their “one right idea” rather than a multitude of options, the risk of getting that idea shut down becomes an all-or-nothing fight.
Teams who want to adopt critique culture should start by giving up the assumption that they already understand any problem they are tasked with solving. Peer critique becomes natural when a team moves from an authority-driven framing of the problem (by a stakeholder or a one-time workshop of stakeholders) to an experiment-driven process of defining it over time.
This sets off a virtuous cycle: removing the requirement to be “right” immediately gives us the freedom to be wrong, which lets us bring many ideas to the table, which makes it safer for any one of those ideas to be wrong. And testing multiple ideas brings in a wealth of data for synthesis, expanding our understanding of the problem beyond a single anecdote from Sales that may have kicked off the entire effort.
I have a lot more to say on effective critique, but if you can get to “being wrong safely” you’re most of the way there. Once you have established this baseline, you’ve made it possible for design to do its job: practice the design process feedback loop to render wicked problems solvable.
