There is No Design Metric

Designers have spent the last twenty years trying to justify their discipline to the very teams that hire them. Maybe it’s time to stop.

I got into tech because of the opportunity to create useful, usable, sometimes delightful products for people — and because software is such a tangible, approachable way to do that. That’s not purely a design goal—depending on the team it may involve product management, product marketing, or front-end engineering—but we’ll just call it “design” for the same of simplicity.

Design takes time. Time to understand users, their assumptions, their needs. Time to ensure we build things that fit their expectations. Time to polish the result.

Designers everywhere struggle to get that time, even after decades spent making the case for it. The struggle itself has become part of the designer identity, a perverse badge of honor that sets designers apart even as it burns us out.

It’s a struggle we can’t win.


When I was freelancing in the early 2000’s, design was often an afterthought: “We’re done with the product! Now, can you do the design?” It was frustrating but not intractable: There was always something to do. In the best case, I was brought in early enough to rewind a few steps and talk about use cases. For really last-minute projects, I dug into the code and improved what I could: maybe the information architecture was off limits, but I could reduce chartjunk, improve visual hierarchy, and upgrade the look & feel.

To make it work, I had to educate my clients about design: The importance of starting from user needs; the dangers of self-reporting bias; the nuances of visual hierarchy; the difference between consistency and matching expectations; the dangers of click-counting as a proxy for usability. It was rewarding: As I explained these things, my discipline became a part of my client’s process — whether I was there or not.


Today, design is accepted by the industry. We have VPs and Directors of design, established systems like Material, and well-funded teams.

But the problem hasn’t disappeared. Follow any design blog and you’ll see a stream of posts with titles like, “How to Ensure Design Has a Seat at the Table,” or “Justifying Design Projects with Data.”

Reading these, and working in both design and non-design roles, I can’t help but notice what hasn’t changed in all these years: Design is still optional, like a feature we may or may not prioritize.

Don’t believe me? Let’s compare design with a common engineering task — for instance, architecting for flexibility and robustness out of the gate. Suppose we’ve concluded a feature will take two months to build. The PM, or an executive, might ask, “What needs to happen to cut that time in half?” The engineers’ answer might involve de-scoping the feature, or reexamining the trade-offs around technical debt. They may or may not conclude it’s even doable.

Here’s what doesn’t happen: The PM doesn’t unilaterally rearchitect the product. She may propose changes, but she’s not going to insist; she’s probably not even set up to do so organizationally.

Nor do the designers insist on implementing one version with a SQL database and another with a NoSQL one, and then using key performance indicators to determine which is better.

In other words, we have some baseline standards for how to build software. To some extent we take these on faith, and that’s good because we can’t easily measure their impact. We hire great engineers and ask them to make trade-offs. We expect them to define a “good enough” implementation and to justify their decisions, and beyond that we defer to their expertise.

But design is different. PMs and engineers cut design details all the time. We define functional (and, therefore, launchable) in terms of whether it’s possible for a user to accomplish a task, not whether it’s easy, or enjoyable, or even whether it’s a task the user has any interest in accomplishing.

With that definition of functional, it’s possible to strip out critical portions of a design, or even to implement an entirely different one that the designer doesn’t like. It works, doesn’t it? And we can watch the metrics and see if it’s worth investing the time to do it right in v2.

A decade ago, it was possible to overcome such objections as I did in my freelance days: By helping people understand how product design fits into the overall narrative of product development. But that doesn’t work in today’s data-centric world. We already understand the narrative, but we reject the work necessary to support it because it can’t be tied to a success metric or performance indicator.

So here’s the uncomfortable truth: There is no success metric for design.

You can’t look at your data and see the overall contribution design makes. Nor can you measure the long-term, cumulative impact of design on every metric — let alone on satisfaction or brand perception.

I say “can’t,” but of course it’s not that simple. We can certainly get closer if we’re willing to invest enough: build two massively different UIs for a feature and test them over a significant period of time; or, maintain both a polished and an unpolished version of a product for years and measure retention. But that’s prohibitively expensive.

And I’m not saying design doesn’t affect metrics. We A/B test to answer design questions all the time. Here, I’m talking about the overall impact of thoughtful, holistic design and product polish.


So we’re trying to justify design via metrics we don’t have. Which guarantees that when time is tight — and time is always tight — design details will get cut. And, it guarantees that bane of every designer’s existence: the “fast-follow” release that never happens.

To solve this, we have to start defining the trees in terms of the forest: If we agree that product quality and design are important, then we must hire great designers and trust their instincts—just as we hire great engineers and trust their instincts on architecture, technical debt, security, and scalability.

“But wait,” you say. “My designers don’t do trade-offs: they’re always telling me the feature is ruined if we don’t implement the whole thing.” And indeed, all too often designers are categorical about their work. But, I wonder what’s cause and what’s effect. If you hire someone for her expertise, and then ask her to justify every decision via means that aren’t applicable, she’ll get defensive. If you continually rip out pieces of her work based on your judgment that they aren’t important, it’s reasonable to think she’ll insist every piece is important.

But if designers are asked to make trade-offs, and those trade-offs are respected, maybe designers will make more trade-offs.


How do we do this better? How do we, once and for all, give design that seat at the product table and get the twenty-year-old chip off designers’ shoulders? It’s going to need everyone:

  • Product Managers: Take it on faith that every launch has a quality bar, and that you will never justify that quality bar with data. Look to your designers as keepers of that bar. Ask them to make hard trade-offs and to justify those trade-offs. Include them in product strategy discussions so their decisions are well-informed.
  • Engineers: Adopt the same attitude as the PMs. Work closely with designers to ensure they have a deep understanding of product architecture and can use it to inform their choices. Respect their expertise and thoroughness in choosing, even as you engage in productive debate.
  • Design Managers: Encourage and reward trade-offs. Be wary of “drive-by” critiques: If your team never knows when you’ll criticize the “down” side of a trade-off, they’ll conclude you demand perfection across the board.
  • Designers: Don’t be perfectionists. If you want a seat at the table, remember that the table is all about compromise; if you’re unwilling to do it yourself then others will do it for you. Make decisions about what matters and what doesn’t, and let go of the latter. Revel in the things you decide not to care about. Recognize that you’ll choose wrongly sometimes, and give yourself permission to do so. Don’t be afraid to push back when asked for metrics if there aren’t any.

And one more thing: Most of us want to launch polished, well-designed products. By abandoning the notion that doing so requires quantitative justification, and by accepting product quality as a given, we’ll launch products we feel better about. We’ll have more fun, and we’ll hold our heads higher.