How do you measure design work?
Attributing a revenue change to design is almost always a fiction, because redesigns ship alongside pricing changes, campaigns, new features and seasonality, and nobody holds those constant to satisfy a performance review. That does not mean design is unmeasurable. It means the measurable things are narrower, closer to the work, and considerably more useful than the headline number people ask for.
Why does attributing revenue to design usually fail?
Because the change is never isolated. A redesign typically launches with new copy, a new onboarding email, a marketing push and often a pricing or packaging tweak, over a period in which the market also moved. Any figure quoted afterwards is the sum of all of it, and assigning it to design is a claim nobody could defend if challenged.
The direction of causation is also unreliable. Teams redesign the parts of a product that are already struggling, so a redesigned area often improves partly because it was the worst performing to begin with and would have recovered somewhat regardless.
This matters because inflated attribution is fragile. A design team that claims a large revenue uplift is inviting the same arithmetic in the other direction the next time a number falls, and that is a much harder conversation. Claim what the work demonstrably did, and let it be smaller.
What can be measured honestly?
Task-level behaviour, which is where design has the most direct effect. Completion rate for a specific task, time to first successful use, the number of steps actually taken versus the minimum, error and validation failure rates on individual fields, and abandonment at each step of a defined flow. All of these respond to design changes and are far less contaminated than revenue.
Support signals are the second honest source and are systematically underused. Tickets and calls mentioning a specific screen, repeated how do I questions, and the volume of manual corrections your operations team makes on behalf of customers. When a design change works, the corresponding ticket category drops, and that is visible within weeks.
The third is throughput, meaning how quickly the team can produce and change interfaces. Time from decision to shipped screen, the proportion of screens using shared components, and the number of times a shipped interaction had to be redesigned. These measure the design function rather than the design, which is what a manager mostly needs.
| Measure | Tells you | Contaminated by | Use for |
|---|---|---|---|
| Task completion rate | Whether people can do the thing | Audience mix changes | Judging a specific flow |
| Step-level abandonment | Exactly where it breaks | Traffic source changes | Prioritising the next fix |
| Field-level validation failures | Which inputs confuse people | Very little | Quick wins and copy fixes |
| Support tickets per screen | What is costing you money now | Seasonality, release timing | Ranking real problems |
| Time from decision to shipped screen | Whether the design function is a bottleneck | Engineering capacity | Team management |
| Revenue or conversion | That something changed | Everything else that shipped | Very little, on its own |
What should you hold an individual designer to?
Decisions and their consequences, not metrics they do not control. A designer cannot be responsible for conversion, because they do not set the price, the offer or the traffic. They can be responsible for having identified the problem correctly, for having designed the states the product actually needs, and for the built result matching the intent.
Three fair expectations: that the work is grounded in something other than opinion, that shipped flows include the unglamorous states, and that they reviewed the built version and raised what was wrong. All three are observable without any design expertise on the reviewer's part.
A fourth, harder one is whether other people's work improved. Senior designers should leave behind conventions, components and rules that make the next screen faster, and a senior designer whose departure would change nothing structurally has been operating at a mid level regardless of title.
Are design surveys and satisfaction scores worth running?
Sparingly, and never as the primary measure. Satisfaction scores are dominated by factors outside the interface: price, delivery, a support experience last month, whether the thing was in stock. They move for reasons unrelated to your work and are largely insensitive to the changes that matter most.
The one survey instrument worth keeping is a single open text question at a moment of friction, asking what the person was trying to do. That produces a stream of specific, actionable complaints rather than a score, and the volume of a given complaint is itself a measure.
Beware of asking users to rate a design. People rate what is new highly for a few weeks and then regress, and they rate familiar things highly because they are familiar. Preference data collected this way tends to defend whatever exists, which is why survey-led design is conservative in a way that has nothing to do with what works.
What is worth counting, starting this week?
Pick one flow that matters commercially and instrument its steps. Count how many people start it, how many finish, and where the rest stop. Most teams cannot answer that question for their most important flow, and the answer routinely relocates the entire design roadmap within a day of having it.
Then count validation failures per field on the busiest form in the product. This is cheap to add, unambiguous, and it typically surfaces one field where a large share of people fail on the first attempt, which is a design defect hiding as user error.
Then set a baseline before any design work starts, however rough. The commonest reason design work cannot be evaluated is not measurement difficulty, it is that nobody recorded the before. A week of numbers collected in advance is worth more than any amount of analysis afterwards.
Common questions
- How do you measure the value of design work?
- Through task-level behaviour rather than revenue: completion rate for a defined task, abandonment at each step, validation failures per field, time to first successful use, and support tickets mentioning a specific screen. These respond to design changes and are far less contaminated than commercial metrics, which move for reasons including pricing, campaigns, new features and seasonality that nobody holds constant.
- Can design be linked to revenue?
- Rarely with any honesty, because redesigns ship alongside copy changes, marketing pushes and often pricing tweaks, so any figure quoted afterwards is the sum of all of them. Teams also redesign the areas already performing worst, which would partly recover regardless. Claiming a large uplift also invites the same arithmetic in reverse when a number later falls.
- What should a designer be held accountable for?
- Identifying the problem correctly, designing the states the product actually needs including empty, error and loading cases, and checking that the built result matches the intent. Not conversion, which depends on price, offer and traffic they do not control. For senior designers, add whether they left behind conventions and components that made other people's work faster.
- Are user satisfaction surveys a good measure of design?
- Weak, because scores are dominated by price, delivery, stock availability and past support experiences rather than the interface, and they are insensitive to the changes that matter most. A single open text question at a moment of friction, asking what the person was trying to do, is more useful, since it produces specific complaints whose volume can be counted.
- What should we measure before starting a redesign?
- A baseline for the flow being changed, however rough: how many people start it, how many finish, where the rest stop, and validation failure rates on the busiest fields. The usual reason design work cannot be evaluated is not measurement difficulty but that nobody recorded the before. A week of numbers gathered in advance is worth more than any analysis attempted afterwards.
