You already know your users. How sure are you?

What discovery actually is

Discovery is the phase of a project where you test your assumptions before you act on them. Not forever and not exhaustively: a good discovery can be a handful of interviews and analysis of existing data. The point isn't to gather every possible insight before a single component is designed: it's to find out, cheaply, whether the thing you're about to build is the right thing to build in the first place.

Most organisations that skip discovery don't think they're skipping it, they think they already did it, through years of lived experience with their users. The problem is that, although lived experience tells you a bit about the people you're already reaching, it tells you very little about the people you're not, what's stopping them or what they actually need from a digital service.

The cost of confidence

A dramatic example of what happens when you build on untested assumptions comes from government IT. The NHS National Programme for IT was launched in 2002, with an aim to create electronic care records for every patient in England. It was dismantled in 2011, having cost, by the most conservative estimate, around £12.7 billion - and likely more. The programme was driven top-down, with clinicians and frontline staff reporting that their operational needs had not been considered in the design. The technology was built on assumptions that were never adequately tested with the people it was meant to serve.

The scale of this is unusual, but the mistake they made isn't. Organisations of every size - charities, public bodies and membership organisations - consistently make the same error when they leapfrog discovery straight into design and build. The details change, but the dynamic is the same: confident assumptions, untested, becoming expensive problems later down the line.

When the research surprises you

The most valuable discoveries aren't the ones that confirm what you thought: they're the ones that don't.

When we worked with the Internet Society on their fundraising campaign, we came in with a reasonable assumption: that donors would respond to the mission that the internet is for everyone, and it should be open, connected and secure. It's a compelling cause. What research with past donors and supporters revealed, however, was different. Privacy concerns were a bigger motivator for donating - people were worried about corporate and government exploitation of their personal data and were willing to put their money behind protecting it. The original mission framing wasn't wrong, but it wasn't what moved people to give.

Building the campaign around the research finding rather than the assumption produced a 573% increase in donations and exceeded the lead generation target by 60%. It's the difference between a campaign built on what the organisation believed and one built on what donors actually felt.

The finding that changes the project is rarely the one you went looking for. It's usually the one that challenges the belief you were most confident about, which is exactly why you need to go looking in the first place.

Discovery isn't overhead

The argument for skipping discovery is almost always about saving money. And in the short term, it does save money: you go straight to design and build, you move faster, you spend less at the start.

The problem is that what you save in discovery you tend to spend several times over later: in rework when the design doesn't land, in a rebuild when the service doesn't meet the need, or in a campaign that underperforms because it was built on the wrong insight. The organisations that have paid the highest price for skipping discovery didn't think they were taking a risk: they thought they already knew enough.

Discovery is a small, early investment in finding out whether you do. Almost every project we've done that included a proper discovery phase has been better for it, not because we're methodologically attached to the process, but because the people we spoke to told us something we wouldn’t have known otherwise.