You Hired a Designer. Did You Hire Design?

Repeatedly throughout my career, design has been put in a box. Evidence includes reporting into disciplines led by people who assured me they had “worked with UI/UX before”—whatever the fuck that means. Usually it seems to mean proximity mistaken for expertise, with a little Dunning-Kruger thrown in for good measure.

Design reporting into Engineering is like the architect reporting into the general contractor. Architecture is reduced to the production of drawings that enable construction; Design is reduced to the production of interfaces that enable software development. In both cases, the artifact is mistaken for the discipline.

You can see this definition of Design hiding in plain sight in some very common product practices. Design is brought in after the strategic decisions have been made, after the problem has been framed, and sometimes after the solution has effectively been chosen. Its role is then to make that solution usable, coherent, and—tellingly—“creative,” as though creativity were the defining characteristic of the discipline.

The clearest tell may be how Design is measured. We apply production metrics to it as though it were a 20th-century assembly-line function: How much did you produce? How long did it take? How many screens, tickets, tokens, stories, or deliverables moved through the system?

None of these practices is unusual. That’s what makes them interesting. Taken together, they reveal an implicit model of Design: the important decisions happen upstream; Design is there to turn those decisions into artifacts.

For a long time, I thought these were variations of the familiar problem that organizations simply don’t understand or value Design. I’m starting to think that diagnosis is wrong.

Maybe the problem isn’t that organizations don’t value Design. Maybe they value exactly the version of Design they believe they’ve hired.

And the version many organizations believe they’ve hired is a production capability: something that turns requirements into interfaces and somehow makes software more usable, coherent, polished, intuitive, or delightful. A trick, essentially—a specialized skill possessed by “creative” people who can put lipstick on whatever pig the organization has already decided to build.

If that’s how the organization sees Design, its behavior starts to make sense—even if I disagree with the premise. Design enters after product strategy because the strategic decisions have already been made. Another discipline can manage it because they’ve “worked with designers before.” Designers are evaluated on throughput because production functions produce things. The designer’s job begins with a requirement because defining the requirement belongs somewhere else.

The organization may not be failing to value Design at all. It may be behaving completely rationally based on how it classified Design in the first place.

Design as Production

Organizations are comfortable with outputs because outputs are visible. A screen exists or it doesn’t. A prototype is complete or it isn’t. A ticket moves from one column to another. A release ships. A design system gains another component.

These things can be counted, assigned, estimated, and placed neatly into roadmaps, utilization models, and sprint boards. When Design is understood primarily through those outputs, the designer naturally becomes another production resource in the product-development machine.

The model is simple: Product determines what should be built. Engineering determines how it can be built. Design determines what it should look like and how users interact with it. It’s clean, understandable, measurable—and extraordinarily limiting, because some of the most valuable contributions Design can make happen before there is anything to design.

Design as Diagnosis

If Design is understood as a system of diagnosis, almost all of those assumptions break. The work becomes partly about asking:

• What problem are we actually solving?
• For whom?
• What evidence says this is a problem?
• Why does the current behavior make sense to the user?
• Where is the value exchange between user and business?
• What assumptions are we making, and which ones are dangerous?
• What could we learn before spending six months building something?

None of those questions is primarily about an interface. They are questions about product decisions, evidence, risk, and whether the organization’s understanding of a situation corresponds with the reality experienced by the people it expects to use—or pay for—what it creates.

This isn’t an argument that diagnosis matters more than treatment. Both matter, but they operate at different points in the causal chain. If the function looking for causes reports to the function responsible for treating symptoms, don’t be surprised when the organization optimizes for treatment.

That is how teams become exceptionally good at solving problems as they are handed to them without necessarily asking whether they are solving the right problem. Engineering can execute brilliantly against the definition it receives while the organization remains wrong about the premise. Building the wrong thing beautifully is still building the wrong thing.

Your Operating Model Tells Me What You Think Design Is

Forget what the company says about being “user centered.” Look at how Design actually operates. When does it enter the process? What is it allowed to question? Is research used to investigate uncertainty or to validate decisions that have already been made? Is Design expected to influence what gets built, or merely determine how the thing being built should work? How is its performance measured?

Those answers reveal the organization’s actual definition of Design. They also expose a strange contradiction: designers are supposed to be creative, innovative, curious, holistic thinkers who challenge assumptions and advocate for users—but often within a system that says, be creative, but stay inside the requirements. Understand the user, but don’t participate in deciding what problem we’re solving. Think holistically, but measure your performance by tickets closed.

In that system, creativity becomes just another production technique: creatively solve the problem we already defined, inside the boundaries we already established, according to the delivery schedule we already committed to. Execution matters. Interaction quality matters. Craft matters. But they represent only part of what Design can contribute.

Companies misclassify Design as a production capability and then build organizational structures, processes, metrics, and expectations around that classification. They subsequently wonder why Design fails to produce strategic value.

The system may simply be working exactly as designed.

Why Twenty Years Can Look Like Two

Treat Design as production and experience becomes difficult to see. A designer with two years of experience may produce an interface that looks remarkably similar to one produced by someone with twenty. Increasingly, a generative tool like Figma Make may produce something in the same neighborhood.

If the artifact is what you’re measuring, the apparent gap between junior, senior, and machine-assisted output can collapse very quickly. But that doesn’t mean the expertise is equivalent. It means the artifact was never a sufficient measure of the expertise in the first place.

Much of the value of experience lives in judgment: the unsupported requirement challenged before it becomes a feature; the “edge case” recognized as a systemic problem; the research question identified as confirmation disguised as inquiry; the seemingly minor interaction decision that would have created downstream complexity; the “new” idea recognized as an old failure pattern wearing different clothes.

Experience avoids pitfalls. But it also does something that a production model is particularly bad at valuing: it simplifies.

Production naturally rewards addition. More screens. More variants. More components. More flows. More features. More visible evidence that work occurred. Generative tools make addition cheaper still; given a requirement, they can quickly produce more plausible ways to satisfy it.

Good Design often creates value by doing the opposite. It removes a step, a choice, a feature, an assumption, a layer of complexity, or sometimes the need for an interface altogether. The important question is often not “How should we design this?” but “Why does this need to exist at all?”

Production tends to reward addition. Good Design often creates value through subtraction.

That makes experienced design judgment especially difficult to measure, because successful prevention and simplification remove their own evidence. I’ve written before about this as the UX Paradox: the bad feature never ships, the support burden never materializes, the expensive redesign never becomes necessary, and the team doesn’t spend six months discovering that it solved the wrong problem.

Nothing dramatic happens—which is precisely the point. Meanwhile, the screen is sitting right there in Figma where everyone can see it, so the organization measures the screen and concludes that someone else—or increasingly something else—could have produced it for less.

Junior and senior designers look interchangeable when the organization only measures the part of the job that experience has made easiest to see.

The artifacts may look similar. The paths taken to arrive at them may not be remotely equivalent. One produced a solution; the other may have removed half the complexity and prevented three bad solutions before arriving there.

What Did You Actually Hire Design to Do?

This is why I’m becoming less interested in arguments about giving Design “a seat at the table.” That makes the problem sound primarily hierarchical: give Design more authority, have it report to the right executive, invite designers to more meetings. Those things may help, but they don’t address the underlying classification.

The more important question is: What does the organization believe Design is there to do?

If the answer is to produce interfaces efficiently, then measuring output makes sense. Putting Design downstream makes sense. Treating senior practitioners as expensive versions of junior ones makes sense. Having someone who has “worked with UX before” oversee the function may even make sense. Everything follows from the premise.

Which means the challenge may not be convincing organizations that Design deserves more respect. It may be challenging the premise itself.

Design is not a trick for making predetermined products better. It is not merely the interface layer between requirements and Engineering, nor creativity applied after the serious decisions have been made. At its best, Design is a repeatable way of understanding human problems, exposing assumptions, reducing uncertainty, exploring alternatives, simplifying complexity, connecting user behavior with product value, and learning before the cost of being wrong becomes enormous.

Yes, eventually it produces things. But production is not the whole system. If an organization only values what Design produces, it will systematically overlook what Design prevents, removes, discovers, reframes, and makes possible.

Then it may look at the function and wonder why it isn’t delivering more strategic value.

Maybe it is delivering exactly the kind of value the organization designed it to deliver.