01 / UNDERSTAND
What is a Lightning Decision Jam?
Lightning Decision Jam, or LDJ, is a structured workshop developed by AJ&Smart. It combines individual writing, prioritisation, problem reframing and action planning to move a team from a shared topic to a practical next step.
It is useful when unstructured meetings repeat problems without producing a decision. The format organises participation and selection; it does not establish that the most popular problem is the most consequential one.
Why use Lightning Decision Jam?
Separating idea generation from discussion gives people time to formulate their own contribution. A visible selection process reduces the need to negotiate every suggestion verbally. The important result is a bounded action with an owner, rather than a wall of notes everyone agrees to revisit later.
When to use it
USE IT WHEN
A team understands an everyday problem area but keeps circling it in meetings.
Several people can contribute direct experience of the same workflow.
The group can run a small, reversible improvement after the workshop.
When to choose another method
Use User Interviews when the team lacks evidence about the people affected.
Use a Co-design Workshop when affected people need to shape the proposal through a more open process.
Use an appropriate investigation or mediation process for serious harm or unresolved conflict; voting is not a substitute.
What you’ll need
Define the topic, decision owner and constraints before inviting people. Prepare a shared board, individual notes, voting marks and a timer. Explain who can commit resources. Offer accessible ways to contribute and read the board. Reserve time after selection to check risks and agree a follow through route. As a working agenda, reserve 10 minutes for context and positives, 10 for problems and reframing, 10 for alternatives and voting, and 15 for effort, impact and the next action. Adjust for access needs and group size; this is a suggested schedule, not a fixed official timing.
What the session needs
Keep the elements that help answer your question and support a decision.
One area the participants can influence, rather than everything wrong with the organisation.
Time to write before other people’s explanations shape the options.
A declared voting rule used to shortlist, with its limitations understood.
An owner, first step, review date and a signal to observe.
02 / PUT IT INTO PRACTICE
How to run a Lightning Decision Jam
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Frame the work and capture positives
Explain the scope. Invite individual notes about what is working before collecting difficulties.
Keep useful aspects visible so the improvement does not accidentally remove them.
02
Collect problems silently
Ask for one clear concern per note. Allow clarification without turning collection into debate.
Describe a recurring event, not a judgement about a colleague.
03
Prioritise a problem
Use the announced voting rule to identify a focus. Preserve the other concerns for review.
Treat the result as the group’s selection, not evidence of prevalence.
04
Reframe the challenge
Turn the selected concern into a How Might We question that leaves multiple responses possible.
Avoid hiding the preferred solution inside the question.
05
Generate and shortlist solutions
Have participants write independently, then vote on possible responses. Keep notes understandable without a sales pitch.
Invite operational, communication and process changes, not just new software.
06
Examine effort and impact
Use an Impact / Effort Matrix to discuss the shortlist. Surface the assumptions behind placement.
Include ongoing work for support staff, not only implementation effort.
07
Commit to an experiment
Choose a small next action with an owner and a review point. Explain what would justify continuing or changing direction.
Record unresolved objections and decide who must be consulted before proceeding.
Example: a handoff that keeps coming back
Fictional workshop example: a small design team reviews its handoff to development. Participants value quick access to designers, but describe repeated questions about error states. The group selects that concern and asks how it might make unresolved states visible before work starts.
Ideas include a checklist, a short walkthrough and annotations beside the relevant screens. The team chooses to try annotations on one upcoming feature, with a developer checking that the notes answer practical questions. This is a proposed experiment, not a proven improvement.
A designer owns the first version. At the next handoff review, the team will examine which questions still required interruption and whether maintaining the notes created disproportionate work. It will retain the useful direct conversation rather than treating fewer messages as success by itself.

03 / BELOW THE SURFACE
Below the surface: votes do not settle consequences
A workshop can distribute voting rights equally while distributing the effects of its decision unequally.
RESPONSIBILITY
Who has to make this work?
Name preparation and maintenance, not only the visible action.
EXCEPTION
Whose concern did the vote overlook?
Check consequences that popularity cannot settle.
REVIEW
What will change our decision?
Make the experiment capable of producing an unwelcome answer.
In the handoff example, a popular checklist might transfer preparation work to the one person already handling accessibility reviews. The group’s preference would not reveal that imbalance. After voting, ask who must do the work and who carries the risk.
Give those people space to identify a constraint or exception without making them win another vote. A minority concern about a serious consequence deserves investigation even when it attracts little support.
This is an editorial safeguard proposed for this guide, not a claim about an official LDJ stage. It preserves the speed of selection while preventing the session from confusing silence, popularity and informed agreement.
Lightning Decision Jam companion worksheet
Use this two page Design Iceberg companion sheet to record the challenge, shortlist and chosen experiment. The second page captures affected people, objections and follow up. For the original facilitation format and timings, use AJ&Smart’s resources linked below.


Practical tips
Explain the voting rule before participants see the options.
End with a first action someone can actually take.
Common mistakes
Letting explanations become speeches during silent work.
Treating the highest vote as proof of customer value.
Leaving ownership and review until another meeting.
What you’ll get
One focused improvement to investigate, a named owner and a review plan. Retain the reasons and concerns so the team can learn from the result rather than simply repeat the vote.