Every project starts with assumptions. About who the customers are, what they actually need, whether the problem is even real. Most teams hold those assumptions lightly — and build heavily. Discovery is the practice of finding the ones that matter before they become expensive to reverse.
In practice, that might mean a workshop to map what a team knows against what it's guessing. Research interviews with the people a service actually touches. An experiment designed to test one belief before committing to a direction. Or just sitting with a team and asking: what would we need to see to know we'd got this right?
Case study — CX Partners / NHSx
A mental health service was over-stretched, running on disconnected systems, and facing a waiting list it couldn't triage. The NHS systems didn't talk to each other. The staff weren't technical. And nobody had yet named, clearly, what was actually breaking.
As lead service designer — via CX Partners for NHSx — I ran workshops with frontline staff to map the service as it existed, not as anyone assumed it worked. Then research interviews: service providers, users, people who'd fallen through the gaps. We synthesised the findings into a set of options prioritised by impact and feasibility, and presented them back to both the mental health service and NHSx.
The deliverable wasn't an app. It was clarity: what was broken, what was fixable, and in what order. It became the first service design case study of its kind within NHSx.
Read the full case study →Sometimes discovery ends with a prioritised backlog. Sometimes it ends with a clearly named problem. Occasionally it ends with a decision not to build something at all. That last one is often the most valuable outcome.
Not sure yet what you're actually working with?
That's exactly the right moment for a conversation.