Problem
01
Our service works on screen but not in life.
02
Different teams own different bits and it shows.
03
We design features, not journeys.
Outcomes
- A service that works end to end
- Decisions grounded in research
- Fewer failures at the seams
Scope
In scope
- Research
- Journey mapping
- Service design
Not included
- Visual UI design, which sits under UX and UI design
- Engineering, which sits under custom software engineering
Approach
Discovery
We agree the users, the problem and the constraints, and how success will be judged.
Delivery planning
We shape the approach, sequence the work and set out costs, risks and a definition of done.
Build and test
We build in the open, test with real users and real data, and prove it before release.
Operational readiness, hypercare and closure
We hand over, support the first weeks of use, and confirm the outcome before we close.
Deliverables
Research findingsJourney mapsService design
Technologies
Research and synthesis toolsJourney and service mapping tools
Controls
Research participants give informed consent, and their data is handled under the privacy notice. Findings separate what users said from what the team inferred. The whole journey is considered, not single screens. Recommendations state their evidence and confidence.
Frequently Asked Questions
Is this just interviews?
No. Research feeds a designed service that works across every channel and team involved.
Do you design the screens too?
That is UX and UI design, which we do as part of the same team.
Ready to scope this?
Tell us the service that is not quite working and we will design it around its users.