Ctrlk
GovStack Website
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Outcome

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

Event storming diagram
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?

Outputs

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.

Output

Was this helpful?