Product strategy & design / Capability
Product discovery.
Work out who the product is for, what they need first and which assumptions to test before you build.
Talk through your idea
When to bring us in
Sound familiar?
- Everyone agrees we need a product, but not on what it does first.
- We have a long feature list and no way to choose between items.
- We’re not sure the people we’re building for work the way we think they do.
The cost of leaving it
The team builds the version everyone half-agreed on. Months later, the people it was for keep their old workaround, and the features that mattered most are still on the list.
Why us
What we bring to product discovery.
Designers who stay for the build
Design and engineering sit in one team, so the people who drew a screen are still there when it is built and tested.
Decisions in working prototypes
We settle the important journeys in prototypes people can click through, before anyone writes code that depends on them.
A view for every role
SoulCare gives coordinators, carers and families each the screens their job needs. We design client products the same way.
What the work includes
Agree what the first release is for.
We talk to the people who do the work, review what exists today and write down the assumptions the idea depends on. The riskiest ones get tested first. The result is a scope your team can argue with on paper rather than in code.
Stakeholder and user interviews
Structured conversations with the people who will buy, use and support the product.
Current workflow mapping
A clear picture of how the work happens today, including the spreadsheets and workarounds.
Assumption and risk review
A ranked list of what must be true for the product to work, and how to check each item.
First-release definition
The roles, tasks and constraints a useful first version has to cover, and what can wait.
Use cases
Projects we take on.
Scoping a first client portal
A professional services firm wants clients to see their own case progress, and needs to decide which updates are worth building first.
Replacing a spreadsheet-run operation
A field services business runs jobs from shared sheets and phone calls, and wants to know which parts belong in software and which don’t.
Testing a family-facing care app
A care provider is considering an app for relatives and wants to check what families actually ask coordinators before committing to it.
What you get
Outputs you can review.
- Interview notes and synthesis
- Map of current workflows and handoffs
- Ranked assumptions with test plan
- First-release scope and out-of-scope list
- Open questions for engineering
Where it matters
- Health & social care Carers record visits on a phone between homes, so we test task flows for speed and one-handed use with the carers themselves.
- Property & field services A repair moves between customer, inspector, worker and office; we map each hand-off before designing the screens for any one role.
- Fintech & professional services We design onboarding and approval screens with the later review in mind: what a compliance officer or auditor will need to see, and in what order.
Where AI helps
Useful, on a short leash.
Sorting interview notes
Group quotes from interview transcripts by theme, so the team starts synthesis from a draft rather than a blank wall.
AI workflow automation ↗Searching what already exists
Find earlier research, policies and support tickets that touch the idea, with links back to each source.
Knowledge assistants ↗
Where it stops: AI should not decide what users need. The interviews, and the judgement about what they mean, stay with people.
What’s changing
Shifts to plan for.
October 2025
WCAG 2.2 becomes an ISO standard
WCAG 2.2 was approved as ISO/IEC 40500:2025, which makes it easier for governments and buyers to require it by name.
June 2025
European Accessibility Act applies
Many consumer products and services sold in the EU, including online shops, banking services and e-books, must now meet accessibility requirements. Microenterprises providing services are exempt.
October 2024
UK public sector checks against WCAG 2.2
The government began monitoring public sector websites and apps against WCAG 2.2 AA, which adds criteria on focus, dragging and target size.
Process
How the work runs.
Agree the question
We write down the decision discovery has to support and who will make it.
Speak to each group
Buyers, daily users and support staff are interviewed separately, because they rarely describe the work the same way.
Rank what could fail
Each assumption is scored by how much depends on it and how little evidence exists, and the top few get tested.
Draw the scope line
The first release is written as roles, tasks and limits, next to a list of what has been deliberately left out.
Cost
What shapes the estimate.
Number of user groups
Each distinct group, such as staff, customers or partners, needs its own interviews and synthesis.
Access to people
Discovery moves at the pace interviews can be booked, so ready access to users shortens it.
Material you already hold
Existing research, support tickets and usage data reduce what has to be gathered from scratch.
Ways to work together
A first, fixed stage
Discovery, a prototype or a technical review with agreed outputs, so the next decision is made with something concrete in hand.
Delivery in phases
The build split into releases, each with a scope you review and approve before it starts.
Ongoing engineering
An agreed scope for support and improvements after launch, with response expectations written down.
Common questions
Before you get in touch.
Who from our side needs to be involved?
Someone who can make product decisions, plus access to a few people who do the work every day. Their time is the input discovery depends on most.
What if discovery shows the idea won’t work as planned?
That is a useful result. We set out what we found and the options it leaves, which may be a narrower first release or a different starting point.
What affects the size of a discovery engagement?
The number of user groups, how many people we need to speak to, the existing systems involved and how much is already documented.
Further reading
- One record, three apps: designing a shared live record What it takes for a dashboard, a mobile app and a family app to read and write the same live record without copies.
- What to put in a software brief before anyone builds What to write down before asking anyone to build software, and what to deliberately leave open.