Flywheel
Research
Understand users, operators, and needs. Define the right problem to solve before any solutioning happens.
What this phase is for
Research establishes who the work is for, what they're trying to achieve, and what would count as a win. It's the outer loop of the flywheel — done thoroughly at the start of a programme or a track, and re-engaged when test findings suggest the framing itself has shifted. Once a track moves into Design, the inner loop takes over: Design ↔ Test iterates at a higher cadence, with Research re-engaged only when something foundational shifts.
For digital teams this typically spans pre-AOR through planning intervals; for engineering teams, concept development through capability requirements refinement.
How to run a Research prompt
Every Research prompt on this portal is a one-line invocation you paste into a CLARA-enabled LLM. CLARA confirms which artefact you want, asks for the few inputs she can't infer, reads the relevant Confluence pages, drafts the artefact, and files it back into the programme's Knowledge Base under the agreed path.
Early access on ANZ C now. For planned availability in other environments see /tools/clara.
What to do, in sequence
The phase, broken into stages. Read top-to-bottom; each card links to the prompt that does the work.
Stage 1
Discovery
Build understanding of the current state. Surface what's already known, capture a baseline of the existing or legacy system, and design the qualitative field engagement.
1. Surface prior knowledge
Pull what the team and the wider organisation already know about this problem space.
2. Baseline the current state
Run a DASH baseline survey with users of the existing, legacy, or competitor system. The numbers captured here become the comparator the new system's Test results will be measured against — without them, future success criteria stay aspirational rather than verifiable.
3. Evaluate the existing product
Run a Nielsen heuristic usability evaluation of the existing, legacy, or competitor product — from screenshots, a live URL, or a deck — into a scored, evidence-anchored report. The severity-rated findings become candidate problems that feed the synthesis and the impact ranking.
4. Generate the interview guide
Translate the outcome question into a field-ready interview guide — questions, listening signals, and probes.
Stage 2
Synthesis
Turn transcripts and field observations into a single Research-synthesis page covering themes, friction, problem statement, and success criteria — produced in one pass so all four are internally consistent.
1. Synthesise the research
One pass over the transcripts and observation notes produces themes, friction points, the problem statement, and success criteria as a single page.
Stage 3
Artefact production
Compose the synthesis into the durable artefacts that pass into Design. Each domain has its own chain — start with the foundational artefact and let the downstream ones follow. The digital and engineering chains run independently. Within digital, the PRD only needs the persona, so it can run alongside the journey-map → service-blueprint branch. Within engineering, the capability spec and mission thread both branch off the operational scenario and can run in parallel.
1. Draft a persona
DigitalComposite user archetype grounded in the research synthesis.
2. Map the user journey
DigitalCurrent-state experience, friction points, moments of truth.
3. Map the service blueprint
DigitalFront-stage and back-stage of the user experience.
4. Rank the problems by impact
Consolidate the synthesis's friction into a single ranked Problem-impact analysis — reach, severity, evidence, and leverage — so the PRD builds for the highest-impact problem first.
5. Draft the PRD
DigitalProduct Requirements Document — the artefact that passes into Design. Builds for the top-ranked problem from the Problem-impact analysis.
Before you leave this phase
The exit gate. Confirm each item is true before moving on.
Problem framing is current
The problem statement reflects what the team now knows — and it's a problem, not a solution in disguise.
The research surfaced something new
Research that only confirms prior beliefs has produced no new information. Even a refinement should look different from the previous version.
Success criteria are measurable and capability-focused
What the capability or product has to be able to do — and to what threshold — for the next stretch of work to count as a win.
PRD or operational scenario is current
Digital teams: PRD. Engineering teams: operational scenario, grounded in operator reality.
Common pitfalls
Recurring traps to watch for as you work through this phase.
Confirming, not discovering.
Research that only validates pre-existing beliefs has produced no new information. If your synthesis sounds like the brief, go back to the field.
Skipping the synthesis pass.
Jumping from interviews to solutioning loses the layer where the actual problem gets defined — and where the four sections (themes / friction / problem / success criteria) get reconciled.
Synthesis-as-summary.
Insights are not bullet points of what people said. They are the patterns underneath what people said.
Treating the AI output as final.
The prompts produce first-draft artefacts. Manual editing and refinement after generation is the norm, not the fallback.