An ambition without a usable brief
Turn competing stakeholder requests into a defined problem, audiences, decision owners and testable assumptions.
Service 14 / Direction
Product strategy, research & service design
Turn a business ambition into a product decision you can defend. Understand the users, test the important assumptions and prioritise a delivery scope before committing to implementation.
Problems worth solving
A decision-ready product direction before you commit to the build.
A service that loses people along the way
Map the whole journey, including staff processes, documents and failure points, rather than only the public-facing screens.
A roadmap built on untested priorities
Connect research and prototypes to scope, dependencies and acceptance decisions. Leave uncertain findings explicitly unresolved.
A focused advisory commission can end with a decision record and build-ready brief. Implementation is a separate scope. Explore ICT advisory, delivery & training ↗
Delivery sequence
Gather. Shape. Build. Refine.
- 01
Gather
Review supplied evidence and plan proportionate stakeholder and user research.
- 02
Shape
Map the service, frame opportunities and distinguish observations from assumptions.
- 03
Build
Create prototypes and test the questions that can change the product direction.
- 04
Refine
Record decisions, prioritise a staged roadmap and hand over a build-ready brief.
Make the important decisions before they become expensive assumptions.
01Research
02Prioritise
03Validate
Scope & deliverables
Where it fits
Applications & scope.
New ventures, digital transformation, public services and products that need a clearer direction.
What we can deliver
- 01Stakeholder discovery and user research planning
- 02Service maps, opportunity framing and evidence-led priorities
- 03Testable prototypes and a staged product roadmap
- 04Requirements, ownership, dependencies and acceptance criteria
Explore the system
System sketch / Illustrative research and prioritisation process
From assumption to a delivery decision.
Inside / Understand
Identify the user problem, existing evidence and the assumptions that need testing. Agree proportionate research and consent before collecting personal information.
- Problem
- A clear question
- Evidence
- Sources and limitations
- Users
- Relevant research participants
Illustrative service architecture. Detailed rules and responsibilities are agreed for each commission.
Acceptance, QA & handover
A useful starting point
Bring the context.
- The problem, stakeholders and intended users
- Existing research, service data and constraints
- Decision owners, strategic priorities and approval requirements
Acceptance & handover
Agree what good means.
- Assumptions distinguished from evidence and unresolved questions
- Priorities traced to user needs and organisational outcomes
- A scoped roadmap with dependencies and acceptance decisions
HandoverResearch findings, decision record, prioritised roadmap and a build-ready brief.
From requirements to operation
A complete commission, not an isolated build.
Establish the foundations.
The problem, stakeholders and intended users. Existing research, service data and constraints. Decision owners, strategic priorities and approval requirements.
Strategy & discovery ↗Make progress inspectable.
Implement the agreed scope in reviewable increments. Check user journeys, integration boundaries and failure conditions against the requirements, with unresolved decisions kept visible.
Review the delivery stages ↗Define what is ready.
Assumptions distinguished from evidence and unresolved questions. Priorities traced to user needs and organisational outcomes. A scoped roadmap with dependencies and acceptance decisions.
Research findings, decision record, prioritised roadmap and a build-ready brief.
Evidence and scope are different.
The related archive shows decisions embodied in an existing digital experience. It does not establish an independently measured research or commercial result.
A related working example
My Destiny Inc.
A connected organisation website with membership, events and foundation journeys.
Project case study · Archive captures
Explore the project ↗How do research and design become delivery decisions?
We connect observed needs to a prioritised journey and reviewable prototypes. Content ownership, accessibility, publishing responsibilities and acceptance are settled alongside the visual system, rather than after it.
Can you work with our existing systems?
Yes, where access and integration are authorised. We first establish ownership, documentation, dependencies and the boundaries of any replacement or connection. A commission does not require abandoning a system that already works.
What if the research changes the direction?
Findings can change the recommendation. We distinguish observations from assumptions, record the decision and prioritise the next step with the people responsible for the product.
How are security and personal data handled?
We identify data owners, information categories and permitted actions during discovery. Controls, retention, specialist assurance and any data-processing responsibilities are scoped against the actual service. A studio credential does not certify your future system.
What happens after handover?
Documentation, access ownership, training and operating responsibilities are agreed before release. Maintenance, incident coverage and further development have an explicit scope; they are not assumed to be unlimited.
A clear decision trail
Scope, assumptions, dependencies and changes recorded against the brief.
Evidence before acceptance
User journeys, permissions, failure conditions and operating requirements reviewed before release.
Ownership beyond launch
Source, documentation, training and recovery responsibilities agreed as part of handover.
Start a conversation
Tell us what needs to work.
Bring the brief, the source material and the constraints. We will help define the scope and the right next step.