We live in an era where data is abundant, yet most decisions about our digital infrastructure are still made on instinct, influence or inertia.
That should make us uncomfortable.
The irony is this: evidence-based decision-making saves time, reduces risk, and prevents waste. But despite its clear value, it remains the exception, not the rule.
Why? Let’s start with what we mean by “evidence.”
We’re not talking about 400-page academic papers or the kind of data hoarding that turns insight into a burden. We’re talking about usable, observable signals: user research, service data, analytics, frontline feedback, behavioural insights, real-world trials. The kind of evidence that tells you whether your product, service or feature is actually working for people.
In design, particularly in digital services that affect people’s health, housing, education or income, this evidence should be non-negotiable. But too often it’s seen as optional. Something we’ll “circle back to” after the shiny thing is launched.
The cost of ignoring evidence
There are plenty of examples of what happens when we skip the evidence.
Like the multi-step registration form that required a mobile number, but 20 percent of users were on shared or landline-only phones. They simply couldn’t proceed. No one caught it until error logs spiked.
Or the portal that assumed every user had an email address. Analytics later showed over a quarter of users abandoned at account creation — not because they didn’t want to sign up, but because they didn’t have the tools.
One real-world platform we reviewed had a login timeout of five minutes. Younger users moved through it quickly. But older users, switching devices or checking paper records, needed longer. Their sessions kept resetting. Progress was lost. Support lines filled with calls. Internally, this was flagged as user “drop-off”. In reality, people weren’t unwilling to complete the task. They just couldn’t. Simple testing or even session replay would have flagged it in minutes. Instead, it took weeks of complaints to identify a fix.
The worst part? That launch to fail to fix cycle burns money and time — both of which are avoidable.
The ROI of evidence
Evidence doesn’t slow you down. It speeds you up in the right direction.
The best design teams are obsessed with reducing the gap between assumption and reality. They prototype quickly, test regularly, measure honestly and pivot when the signals say so. They ask frontline staff, not just execs. They build in instrumentation and feedback loops. And they revisit decisions when new data emerges.
One product team rebuilt their onboarding flow based on real session data. They removed blockers, added clarity, and gave users the ability to skip unnecessary steps. Drop-offs fell. Activation rates climbed. Support tickets were cut in half. All from watching what people were actually doing, not what they assumed they would do.
Another team launched a redesign that looked great in mockups but tanked task completion. They reverted quickly, ran tests on two variants, and shipped a third version that outperformed them both. Without evidence, that failure would have stayed live for months.
So what’s stopping us?
Let’s be blunt. The barriers aren’t technical. They’re cultural.
Evidence-based design requires humility. It means letting go of the idea that the most senior person in the room is always right. It means accepting that what worked last year might not work now. It means being open to bad news before it becomes expensive news.
It also requires mechanisms: time, budget, permission to gather and act on evidence in the first place. And too many projects still treat research and evaluation as a luxury, not a foundation.
Until we start treating evidence as the scaffolding, not the safety net, we’ll keep repeating the same mistakes. We’ll keep building digital services that don’t serve, launching infrastructure people can’t or won’t use, and wasting money solving the wrong problems.
The fix is simple.
Listen more. Test early. Measure often. Act on what you learn.
Evidence is cheap. Ignoring it is not.