2.2 Ideate Concepts and Develop Hypotheses
Generate ideas
This activity helps teams move from problems to testable ideas by:
learning from existing services and products
generating ideas grounded in real examples
framing ideas as simple hypotheses that can be tested and prioritised
How to do it
1. Share inspiration from real examples (10–15 minutes) Start by presenting short demos or examples of services or products that have addressed similar problems. As facilitator, you may need to prepare these between the problem definition activity and this activity.
Examples we often share include:
clear start pages – For when users not being prepared is a pain point
“check your answers” patterns – for when erroneous information submitted is a pain point
simple content changes with high impact – for when comprehension is a pain point
accessibility improvements – for when usability is a pain point
basic performance measurement or analytics – for when completion rates are low
Keep demos:
short (screens, not slides)
practical
clearly linked to the problems you’re working on
2. Review prioritised problems (5 minutes)
In groups, briefly review the prioritised problem statements.
3. Generate ideas as hypotheses (20–25 minutes)
For each problem, generate ideas using a simple hypothesis structure:
If we… [make a change], then we will see… [an outcome for users or the service].
Encourage teams to generate multiple hypotheses per problem.
Examples:
If we simplify the language on the start page, then we will see fewer incomplete applications.
If we show eligibility earlier, then we will see fewer users applying when they are not eligible.
Facilitator tips
Keep hypotheses simple and testable.
Focus on outcomes, not features.
Avoid jumping straight to large system changes unless necessary.
Run an event storming activity
Event storming is a collaborative activity used to explore how a future service should behave by identifying the key events, decisions, and outcomes that occur over time.
Event storming is used to:
design and test a future-state service
explore complex behaviour across users, organisations, and systems
surface assumptions before committing to detailed designs
Event storming is:
about behaviour and flow
useful for complex or rule-heavy services
collaborative and exploratory
It is not:
detailed system design
a replacement for journey mapping
required for all services
How to do it
1. Define the scope (5 minutes)
Agree what part of the future service you are exploring to keep the scope small enough to explore in one session.
For example:
“From submitting an application to receiving a decision”
“From booking an appointment to completing verification”
2. Identify future events (15–20 minutes)
Ask the group: “What happens in the future service?”
Capture events on post-its and arrange them in time order, for example:
Application submitted
Payment received
Eligibility checked
Application approved
User notified
Focus on what happened, not how it’s implemented. Encourage multiple perspectives (user, organisation, system).
3. Add decisions and actors (10–15 minutes)
For key events, ask:
What decision led to this?
Who or what triggered it?
Capture:
decisions (e.g. “Is the user eligible?”)
actors (citizen, caseworker, system, another agency)
This helps reveal:
rules and assumptions
points of complexity
hand-offs between organisations
4. Sense-check the future flow (5–10 minutes)
Review the timeline together and note open questions or assumptions for follow-up.
Ask:
Does this reflect our future vision?
Where could this break down?
Where is behaviour unclear or risky?
Create an action plan
Turn design ideas into next steps.
How to do it
1. Revisit the future vision
Briefly restate the future vision and key ideas or changes identified during to-be work.
2. Identify actions
Ask the group: “What needs to happen to move us closer to this future vision?” Capture actions in three categories:
Quick wins (low effort, high impact changes)
Next steps (changes that can start soon but need coordination)
Longer-term actions (system, policy, procurement, or cross-government work)
3. Assign ownership and timing
For each action, agree:
who is responsible (role or team)
when it could realistically start If ownership or timing is unclear, note it as an open question.
4. Capture and close
Agree how actions will be documented, shared, and followed up. Close by confirming what will happen next and who will take the outcomes forward.
Example case studies
Post-workshop pilots Action planning has been used after to-be workshops to identify immediate UI or content improvements, areas for supplier pilots, and reusable components to prioritise.
Multi-agency services Separating short- and long-term actions has helped teams make progress without waiting for large reforms, while acknowledging dependencies.
Was this helpful?