User testing and research have long been the default response to design uncertainty, but that’s changing. Teams are moving away from cumbersome, expensive validation cycles, and rightly so. Recruiting participants, moderating sessions, synthesis, tooling: a single round of usability testing can consume weeks and thousands of dollars before a single design decision changes.
But cost is only part of the problem. The more uncomfortable truth is that much of this work isn’t generating insight, it’s generating cover. Testing often happens after direction is already set, which means it’s confirmatory at best and theatre at worst. Teams already know what they want to build. The research exists to validate the decision, not interrogate it.
There’s an irony worth naming here. The same teams that reach for research in the name of risk aversion are often comfortable funnelling significant budget into a process that’s nearly impossible to measure. What’s the ROI on that round of usability testing? How do you attribute a design decision to a research finding six months later? The risk of wasted time and money rarely gets the same scrutiny as the risk of shipping something untested. Risk aversion, it turns out, is quite selective.
And that selectivity points to something more human: a fear of blame. In organisations that punish failure, testing becomes a way to distribute accountability. If it doesn’t work, at least we tested it. That’s an understandable response to a bad environment, but it’s not design thinking, it’s self-preservation.
This isn’t an argument against understanding users, it’s an argument against manufacturing that understanding when it already exists. The support queue, the analytics, the existing patterns in the market: users are already telling you what’s broken. The question is whether you need to go looking for more problems before acting on the ones you already have.
The alternative isn’t to skip rigour, it’s to front-load it. Most of the knowledge a research programme would generate is already available, it just hasn’t been organised yet. In your analytics, in a current state analysis of what exists and where it breaks down, in competitor analysis of how the problem has been solved elsewhere, in the expertise already in the room. A well-constructed brief does that organising before a design is ever presented.
So what does front-loading rigour actually look like? For me, it starts before a design is ever presented, with documentation that makes the decision legible before anyone has a chance to question it. Not a spec, not a presentation. A brief that answers the questions stakeholders are going to ask before they ask them.
The brief as a communication tool
The goal is to make a decision legible to people who aren’t in the design work every day. A developer, a product manager, a business stakeholder: they need enough context to evaluate the decision, not a full design education.
Before the brief gets written, the thinking that feeds it matters. Jobs To Be Done helps define what the user is actually trying to accomplish, not what they’re clicking, but what outcome they’re after. MoSCoW prioritisation forces clarity on what the solution must do versus what would be nice. From there, a good/better/best framework gives you three starting points rather than one: a minimum viable solution, a considered middle ground, and an ideal state. Options stop roadblocks. When stakeholders have something to react to and choose from, the conversation moves. When they’re presented with a single solution to approve or kill, it stalls.
What goes in the documentation
The problem statement. What are we actually solving? This is the most important thing to get right. If the problem isn’t clearly defined, the design solution has nothing to stand on. A crisp problem statement also makes it easy to evaluate whether a proposed solution actually addresses it.
User goals and business goals. These don’t always align and it’s worth being explicit about both. A design that optimises purely for user experience at the expense of business outcomes won’t get built. Showing that you’ve considered both builds credibility.
Current state analysis. What exists today and where does it break down? Documenting the current experience, its gaps, its inconsistencies, its friction points, gives the proposed solution something concrete to push against. It also makes the case for change without you having to argue it directly.
Competitor analysis. How has this problem been solved elsewhere? Established patterns carry implicit user familiarity. Referencing what works across the industry grounds the decision in something beyond internal preference and signals you’ve done the homework.
Design principles at play. Which Gestalt principles, interaction patterns, or UX heuristics informed the decision? This isn’t about showing off, it’s about grounding the decision in something beyond personal preference. When you’re communicating options, you’re not asking the room to trust your taste. You’re referencing Nielsen, Gestalt, WCAG: frameworks developed and validated by people who’ve spent careers thinking about this. That’s what turns a design recommendation into a defensible position. It’s the difference between “I think this works” and “this works because.” You’re backing yourself with the best minds in the field.
Constraints and tradeoffs. What were the options considered and why were they rejected? Showing the work, including the paths not taken, demonstrates rigour and pre-empts the “but what about…” questions.
The ask. What does approval look like? What needs to happen next? Be specific. Vague sign-off leads to vague implementation.
What good advocacy isn’t
It isn’t overselling. A brief that’s too long, too detailed, or too obviously trying to pre-empt every objection reads as defensive. The goal is clarity, not exhaustiveness.
It isn’t presentation theatre. Slick slides with no substance behind them don’t hold up to scrutiny. The documentation matters more than the delivery.
And it isn’t always winning the argument. Sometimes the constraints are real: time, technical debt, resource. Good advocacy means making the tradeoff explicit so that when something gets cut, it’s a conscious decision rather than an oversight.
The underlying principle
Design decisions are only as good as the understanding that surrounds them. If the people implementing your work don’t understand why it’s designed the way it is, they’ll make changes that undermine it, not out of malice, but because they’re filling in gaps with their own assumptions.
Documentation closes those gaps. It’s not overhead, it’s part of the design.
When data does the talking
None of this means ignoring evidence. It means being selective about how you gather it.
Behavioural data, analytics, funnel drop-off, heatmaps, session recordings, tells you what’s actually happening at scale, faster and more honestly than any moderated session. A spike in cart abandonment at a specific step is more actionable than ten interviews about how people feel about shopping. It’s already there, it’s continuous, and it doesn’t require a recruitment brief.
When qualitative input does add value, it tends to be targeted and specific: five conversations to pressure-test a hypothesis, not a research programme to generate one. The question comes first, the method second.
That said, there’s a place for it. If you have a genuinely unanswered question, the bandwidth to pursue it, and, in a dream scenario, a surplus of engineering resources waiting on the other side, research earns its keep. But some problems are obvious enough to act on. Trust your gut, back it with evidence you already have, and move.