DESIGN EVIDENCE · PART 1 OF 2
How to turn vague requests into accountable design work
A client recently looked at me as if I had confessed to a minor crime.
I told him I was a designer who liked numbers.
Metrics. Baselines. Analytics. Documentation.
“You’re a designer,” he said. “Aren’t you supposed to hate numbers?”
He thought designers made things look good. Someone else worried about whether those things worked.
I told him I like numbers because they help me understand what I am designing, choose a responsible direction, and find out whether the work changed anything. They also give the client a fair way to evaluate me—not by whether I made something attractive, but by whether the work improved the condition we agreed to improve.
Numbers do not design the solution for me.
They stop me from confusing my solution with the truth.
Design is answerable to a condition
Every serious design project begins with a condition someone wants to change.
A customer cannot complete a task.
Employees spend two hours doing work that should take twenty minutes.
People abandon an application because they do not understand what is being asked.
A support team answers the same question hundreds of times.
A service excludes people with disabilities.
A company pays several vendors to solve the same problem repeatedly.
Something is happening before the designer arrives. The work exists because someone wants that condition to become different.
That is where accountability begins.
ISO 9241-11 describes usability as an outcome of use. It does not treat usability as a visual quality that can be declared by looking at an interface. It becomes visible when specified people use a system to pursue specified goals in a real context.
That distinction matters.
A new interface may be cleaner. The component library may be consistent. Leadership may approve every screen. The prototype may perform beautifully during a presentation.
None of that tells us whether customers can complete the task, whether employees make fewer mistakes, or whether the change reduced the problem the project was created to address.
A design is not successful because it shipped.
It is successful when it changes the condition it was created to change.
Clients rarely arrive with measurable problems
Most clients do not begin by presenting a baseline, a behavioral hypothesis, a measurement plan, and a set of guardrails.
They arrive with a deadline.
They bring feature requests, brand guidelines, competitor screenshots, executive opinions, technical limitations, and a vague but persistent sense that something is wrong.
They say:
- “Our website looks outdated.”
- “It needs to be more intuitive.”
- “We want more engagement.”
- “The site is not converting.”
- “Our competitors have a better experience.”
- “We’ll know it when we see it.”
These are not necessarily bad requests.
They are compressed requests.
The client sees a symptom or feels pressure but may not yet have the evidence or vocabulary to describe the underlying condition. The designer’s job is not to mock the request or immediately translate it into a visual trend.
The designer’s job is to unpack it.
Designers often make the opposite move. We accept the surface request and begin asking about pages, components, colors, content, and delivery dates.
The solution takes shape before the problem does.
By the time anyone asks how success will be evaluated, the team has already invested weeks in the answer. Stakeholders are attached to it. Questioning the original premise begins to feel like sabotage.
Clients contribute to the problem when they treat designers as visual order-takers.
Designers contribute when they behave like visual order-takers.
Questions before the screens
The difficult part of these conversations is not only what the designer asks.
It is what the stakeholder thinks the question means.
When a designer asks for evidence, the stakeholder may hear a challenge to their credibility. When the designer asks what “modern” means, the stakeholder may hear sarcasm. When the designer asks how the redesign connects to revenue, the stakeholder may believe the designer is preparing to refuse responsibility later.
The conversation can fail before the answer arrives.
| What the client says | What the designer asks | What the stakeholder may hear |
|---|---|---|
| “Our website looks outdated.” | What is that appearance preventing customers, employees, or the business from doing? | “Defend your taste.” |
| “It should be more intuitive.” | Where do people hesitate, make mistakes, leave, or ask for help? | “Prove users are confused.” |
| “We need more engagement.” | What useful behavior should increase—not merely clicks or time spent? | “Choose a KPI for us.” |
| “The site is not converting.” | What counts as conversion, where does the journey begin, and where do people leave? | “Guarantee more revenue.” |
| “We’ll know it when we see it.” | What would distinguish an effective design from one leadership simply prefers? | “Your opinion does not matter.” |
The objective is not to expose the client’s ignorance. It is to convert concern into something the team can investigate.
Take the word outdated.
It may mean customers no longer trust the company. It may mean the content team cannot publish without calling a developer. It may mean the experience fails on mobile, performs badly, does not meet current accessibility expectations, or no longer supports the business model.
It may also mean the chief executive dislikes blue.
All are real organizational facts.
They are not equally good reasons to rebuild a website.
The client does not need to arrive with perfect UX metrics. The client needs to explain the business reality honestly enough for the team to define useful evidence together.
The designer then has to extract four things:
- the condition that exists today;
- the people most affected;
- the behavior or outcome that should change;
- the limits the solution must respect.
Translate adjectives into observable change
“Modern,” “intuitive,” “engaging,” “premium,” and “trustworthy” are interpretations.
They are not finished requirements.
A more modern website might allow a communications team to publish in hours rather than weeks.
A more intuitive application might reduce task errors and requests for assistance.
A more trustworthy checkout might help customers understand pricing before they reach the final step.
A more engaging service might bring people back to finish meaningful work rather than trapping them in more screens.
This is where the vague request becomes a hypothesis:
We believe simplifying account verification will increase successful first-session completion and reduce verification-related support requests without increasing fraud, privacy risk, or accessibility failures.
Now there is something to design.
There is also something to challenge.
Google’s HEART framework follows a similar order. Teams begin with the experience goal, identify signals that would indicate movement toward that goal, and then map those signals to metrics. The metric follows the intended outcome; it does not replace it.
Starting with whatever number is easiest to collect reverses that logic.
The team begins optimizing what is visible instead of deciding what is valuable.
Establish the current condition
A target without a baseline is mostly guesswork.
If the team wants to reduce abandonment, it needs to understand current abandonment and how it was defined.
If it wants to reduce support demand, it needs to know which requests relate to the experience, how frequently they occur, and whether the categorization is reliable.
If it wants to improve efficiency, it needs to understand the current workflow—including the unofficial steps employees created to keep the official process alive.
The baseline does not have to be elegant.
It has to be honest.
In one recent project, a client insisted their onboarding “wasn’t working.” When we instrumented the flow, we found that 68% of users were actually completing it—but 41% of those completions were happening after at least one failed attempt and a support interaction. The problem wasn’t abandonment. It was recoverability.
Sometimes the most important discovery is that the organization cannot currently measure the outcome it has promised to improve.
That is not a reason to invent a number. It is a finding, and it changes the work.
GOV.UK’s service guidance recommends defining metrics from the service’s purpose, developing hypotheses, combining performance data with user research, and using existing or legacy systems to establish a baseline where possible.
Metrics can tell the team where something is happening.
Research helps explain why.
The number points to the room.
Research turns on the light.
Evidence does not require millions of users
The most predictable objection arrives quickly:
“Our product only has 200 users a month. Analytics will not tell us anything.”
Small numbers limit certainty.
They do not excuse ignorance.
A low-volume product may never support a persuasive A/B test. The team can still examine support complaints, error logs, failed transactions, task-completion observations, accessibility defects, employee workarounds, and the time required to complete a workflow.
Five usability sessions will not reveal every possible problem. They may still show that four people cannot understand the same instruction.
An enterprise tool may have only forty users. If those people spend several hours a day inside it, one recurring failure can waste hundreds of hours over a year.
Evidence has to match the decision.
At low volume, the team should be cautious about generalization. It should state the limits of the evidence and avoid pretending that a pattern observed in five sessions is a universal law.
But the absence of a massive dataset does not make every opinion equally good.
Who pays for the thinking?
This work is often described as if designers can solve everything by asking a few sharper questions during kickoff.
Sometimes they can.
Often the real work involves stakeholder interviews, analytics review, technical discovery, support-log analysis, workflow observation, accessibility assessment, and the painful discovery that five executives believe they approved five different projects.
That takes time.
Discovery is not free work performed before the real design begins.
Understanding the problem is part of the real design.
There are three honest ways to fund it.
A client can purchase a separate discovery engagement before committing to a larger build. This works when the problem is unclear, the organization is complex, or the proposed solution carries significant cost or risk.
Discovery can also be included in the first phase of the engagement.
For smaller work, the designer can run a deliberately narrow evidence pass.
What designers should not do is perform unlimited strategic work for free while teaching clients that thinking has no value and screens are the only things worth paying for.
When a client refuses to fund any attempt to understand the problem, the resulting scope is not a plan.
It is a bet.
Metrics can mislead with impressive precision
More clicks may indicate interest.
They may also indicate poor navigation.
More time spent in a product may indicate engagement. It may also indicate confusion, slow performance, or a workflow that makes simple work unnecessarily difficult.
A reduction in support-call duration may look efficient while resolution quality quietly collapses.
Then the measure becomes a target.
David Manheim and Scott Garrabrant’s work on variants of Goodhart’s law describes how optimizing a proxy can weaken the thing it represents.
People become remarkably creative about moving whatever number leadership rewards.
The dashboard may turn green while the experience gets worse.
Guardrails: what are we unwilling to damage?
Every serious measurement conversation needs two questions:
What are we trying to improve?
What are we unwilling to damage while improving it?
The second question defines the guardrails.
A team may want to increase registration completion without increasing fraud or excluding people with disabilities.
The primary measure tells the team where it wants to go.
The guardrails tell it whether it drove through somebody’s house to get there.
A local improvement that damages the wider system is not an improvement.
It is cost relocation.
Numbers and empathy are not enemies
Some designers resist metrics because numbers can reduce human beings to conversion units.
That concern is legitimate.
But avoiding numbers does not protect those people.
It often leaves the measurement system to someone whose only concern is revenue, speed, or volume.
Designers should participate in defining metrics precisely because metrics determine what organizations notice, reward, and ignore.
Qualitative research gives the number a human face.
Quantitative evidence tells us how many faces we failed to see.
Neither is sufficient alone.
Documentation makes evidence interpretable
I also told the client that I like documentation.
That probably sounded worse.
Documentation has earned its reputation. Organizations create enormous collections of files because a process says a document should exist. Nobody reads them. Nobody updates them.
That is not knowledge.
It is sediment.
Useful documentation preserves the connection between the original condition, the evidence, the assumptions, the measure, the decision, and the result.
Without it, teams reopen old arguments. Failed approaches return wearing new clothes.
Documentation is the chain of custody for a design decision.
When the reasoning disappears with the designer, the organization did not learn.
It rented someone’s memory.
The evidence contract
For one project, the initial agreement can fit on a page.
It needs six things.
Problem.
Baseline.
Hypothesis.
Measures.
Guardrails.
Ownership.
This is not a promise that design will transform the company.
It is a shared statement of intent.
Measure to learn, not to punish
The evidence system fails when every bad result becomes evidence against a person or team.
People stop using numbers to learn and begin using them defensively.
A failed hypothesis can teach the organization something.
A hidden failure teaches nothing.
The conversation is the beginning
Clients do not always realize that numbers belong in the design conversation.
That is understandable.
So when a client tells me the website feels old, confusing, or not intuitive, I do not dismiss the request.
I also do not open Figma.
I ask what is happening, who is affected, what should change, what evidence exists, what we cannot afford to damage, and what limits the solution must respect.
That is design.
Continue to Part 2: When evidence has to survive the organization
Your Team Knows Better. Why Does the Work Still Go Wrong? →