This is part 1 of an article series exploring how every participant in the software design process can apply design decision-making methods to the way we organize teams, plan work, and build products, rather than just to the products themselves. I hope to make these tools useful and relevant to readers — if what I am describing doesn’t fit your experience, don’t hesitate to drop me a line.

When the Web was still 2.0 and my UX design career was just beginning, it was fashionable to talk about design’s “seat at the table.” Design leaders appealed to senior practitioners’ responsibility not merely to their users, but to the design community as a whole: to build not just products, but company culture that could recognize and leverage design’s potential.

And at one point, it even seemed like we succeeded: Design Thinking (capital D, capital T) was in the headlines and taking the industry by storm. Even dweeby old guard companies like Google and Microsoft hired not just design leadership roles but dedicated Design Ops to support ever-growing design teams and their activities. Companies aimed to “get better at design” and actively followed the roadmaps laid out by design maturity frameworks to get there. You could say we were in an era of Peak Design.

And yet, the recognition designers earned didn’t come with a matching level of satisfaction. The call for design’s seat at the table was replaced with a new generation of articles, with roughly the same title and contents repeating year after year. Designers got their seat at the table. Now, what do we do with it?

Indeed, non-designers were talking about design — but they weren’t saying the same things we were saying about it. Designers wanted to be recognized for the problem-solving power of our craft, but instead were celebrated for producing “delight” “empathy” and “usability.” Design orgs aimed for “strategic” but had to settle for “scalable” — more outputs, more artifacts, more design systems, and pattern libraries. The “thinking” from “design thinking” had disappeared.

I think it’s because we’ve been telling the wrong story about what design could do for teams and orgs.

The biggest value of design is not building better apps — it’s building better ways of working.

During the period of Peak Design, a group of designers at Deloitte dusted off the design ladder framework and added two more levels to it, which made sense back then: the more levels, the more upleveling services you can sell. The concept didn’t get a lot of traction as the idea of “design maturity” faded from the spotlight, but I came back to it recently as I was thinking about post-Agile ways of designing.

Rather than being simply an extension, these new levels represented a kernel of something far more interesting. The struggles of the Seat at the Table era called for a playbook that would make design fit. Design Thinking wanted to fit the way that businesses thought about value. Design systems and “two weeks ahead of dev” approaches tried to fit the way programmers delivered that value. And so they were constrained not just by those processes, but the way that their companies thought about them. “Design as process” could only take us as far as the Agile framework encapsulating that process would allow. “Design as strategy” would always be limited by the company’s existing approach to setting goals.

But “design as change” and “design as culture” were describing something else. Rather than squeezing into existing processes, they envisioned designing new processes that could properly leverage design’s higher-level learning loops. Processes that would be able to design effective products because they could shape not just the outputs of the work, but how that work got done.

I believe that this — not Agile transformations lurching into their third decade of life — is the key to finding new, better ways of building software.

The “design doing” joke is as old as the term “design thinking” (lowercase D, lowercase T) — but however long in the tooth, it identifies the method’s biggest flaw. While design thinking workshops effectively leveraged cognitive estrangement to break people out of business-as-usual, the effect could not be sustained beyond the room. People would leave the workshop, and go back to their old jobs embedded into the prevailing semantic environment, where they continued to make decisions in the exact same ways as before.

Design thinking that tried to fit itself into old ways of working could not succeed, because thinking like a designer could not work without the accompanying praxis of design. The lingering conception of design as visual artifacts made it impossible to conceive of design as culture — to adopt designerly ways of achieving other types of outputs, beyond the workshops and across all levels of the reporting chain.

But the tools of design — especially design writing and service design — are just as powerful when turned inwards. “Design doing” doesn’t need to mean that everyone should be a designer, but rather that everyone should be equipped to look at their role’s challenges, including collaboration with cross-functional partners, through the lens of the design process.

The conceptual model of design is fairly straightforward: we are making a tool to get someone (the user) from where they are (their context) to where they want to be (their goal). The model applies whether the designed thing is tangible (like a product) or intangible (like a meeting). In other words, any designed tool must have a clear purpose; we cannot design without knowing what that purpose is.

And as a great deal of what we do at work is purposeless, you can see how this framing might be an effective way of developing new ways of working.

Framing work activities in the terms of the design process allows us to apply one of design’s most powerful tools — design critique — to improve that activity. This is one process that a lot of people flinch at because they’re used to “critique” meaning “criticism.” Indeed, if you have to justify every decision you make, you’re not working in a healthy environment. But if you can’t explain every decision you make, then you are not a responsible partner for your colleagues. Critiques are designed to avoid that, by making sure that the proposed design achieves its intent.

Given that designers are famous for having strong subjective opinions on “good taste,” design critique is a deliberate strategy for getting beyond that surface level of conversation. Rather than a conversation about whether or not you like something, critique is a highly structured tool for determining if a design is fit for purpose.

Question 1: What is the purpose?

To avoid talking past each other, all critiques start with alignment between participants on the purpose of the tool being designed. Before any kind of solution is presented, participants must agree that the goal the tool serves is something that makes a difference. Until this alignment exists, it would be fruitless to have the rest of the conversation — refining a tool that does something pointless would be a waste of resources and time.

This is the stage at which mature teams catch proposals that are motivated solely by outputs, where the success criteria is merely that something new is made, or by vanity metrics, where the goal (such as “improving NPS”) has no intrinsic value. Similarly, if the tool is intended to make a measurable impact towards the goal, but the magnitude of the impact is very small, it may not be worth pursuing — regardless of the solution being proposed.

For a functioning team with a shared understanding of success, this conversation is usually brief and rarely recurs. But without it — without an explicit understanding of what success looks like — it’s impossible to move on to the second question. The majority of critique breaks down when participants try to skip this part and go straight to looking at a solution, because without a clear definition of “good” all they can say about it is “I like it” or “I don’t like it.”

Question 2: Is the design fit for that purpose?

After success is defined, comes the second question: why do you believe that this is the best path to reach that goal? In other words, what is your hypothesis for how this proposal will get the user there from their initial context?

It’s useful to think of this stage as a user journey. The designer soliciting the critique presents the goal & the hypothetical series of events that would unfold during the process of use. The critique participants can then help them spot incongruities: either moments when the required inputs for a process don’t exist, or the depicted outputs do not yield outcomes that reach the goal established in the first question.

When designers make visual depictions of a design, the visuals themselves are not the goal; the goal is to answer this question, to make the designer’s thinking clear and visible, whether to themselves or to critique participants. Before any design depicts a product that works, it will depict dozens that don’t — and critique is how those problems are spotted and smoothed out.

This stage of the critique delves into the two components of any designed thing, whether software or process: the user benefit, and the form factor. A common property of thoughtless design is the emphasis on form factor over benefit — the conversation turns to features (what the user can click on) over how it helps them get to their goal. Asking “why this way, and not another way, to deliver this benefit” helps spot these mistakes quickly, because when the benefit is essentially “the user gets this feature” there is no other possible way to provide it outside of building that feature.

Consider this scenario: a designer proposes to solve a problem of low productivity within the company, through mandatory return to office for all teams. Putting this proposal through the design critique framing encounters a series of questions. What does “low productivity” mean, and how will we see improvements in productivity reflected? (We don’t know.) What is the hypothesis for how RTO improve this metric? (We don’t know). What other methods exist for improving this metric, and how do they compare to RTO? (We don’t know.)

But of course, it would not occur to anyone to critique the CEO’s design. Under “design as strategy,” the design process is still seen as a chore, an unnecessary delay, or extra cost. Real change is only achieved when doing the right thing is easier than doing it wrong.

Extending the semantic environment of design critique from design’s silo across the entire company is the fastest way for our industry to get there. Seeing like a designer is the first step to getting there.