Design a 90-minute idea workshop

This workshop turns one researched problem into a small set of concepts and a clear next test. In 90 minutes, participants generate options, improve a few of them, and choose what to learn next. The promised outcome is a testable proposal, not a validated innovation or a complete business case.

The sequence is an original facilitation synthesis. It draws on the Design Council’s distinction between exploring possibilities and focusing action, and on structured individual idea generation described by Wisconsin Extension and CDC. It is not an official Design Council workshop or a formal nominal group technique protocol. Design Council framework · Wisconsin Extension nominal group technique

Suitability and the finish line

Use this workshop when a team has evidence of a specific problem and permission to explore a solution. It suits a small service improvement, an internal workflow, or an early product concept with a manageable scope.

Do not run it to discover an entire market, settle a strategic conflict, or approve a major investment. If the challenge is “We need an AI strategy,” narrow it through research first. If the sponsor has already selected the solution, communicate that decision and design a different session around implementation questions.

By the end, each selected concept should identify a user, a problem, a proposed mechanism, a risky assumption, a test, an owner, and a review date. An acceptable result is also: “Our evidence is insufficient; this is the research question we must answer next.”

People, roles, and preparation

Invite five to eight people with different relevant knowledge. Include someone close to the user’s work, someone who understands delivery constraints, and someone able to own the next test. Where feasible, involve affected users directly and explain their role honestly.

Assign a facilitator, a recorder, and a decision owner. The decision owner explains the constraints and chooses which tests can proceed; participants help shape and assess options. Make this distinction clear before voting.

Prepare a one-page brief with:

• The user or affected group and the task they are trying to complete.
• Two or three relevant observations, with their source and limitations.
• A challenge phrased as an open question.
• Constraints such as budget, time, accessibility, and existing commitments.
• The decision to be made at the end and the authority available.

An example challenge is: “How might we help new support staff find an approved answer during a live customer conversation?” Avoid embedding the solution: “How might we build a chatbot?” has already narrowed the mechanism.

Send the brief in advance and invite corrections. Prepare the printable idea workshop worksheet, pens or an accessible shared document, a visible timer, and a place to capture unanswered questions.

The agenda: exactly 90 minutes

Time	Activity	Output
0–10	Frame the challenge and evidence	Shared boundary
10–20	Generate ideas independently	Individual options
20–35	Share and clarify	Understandable idea set
35–50	Combine and develop concepts	A few concrete concepts
50–65	Assess and shortlist	Reasons for selection
65–80	Design the next test	Test plan and assumption
80–90	Confirm ownership and close	Decision, owner, review date

The times total 90 minutes. Reserve the last ten minutes; if an earlier stage overruns, reduce the number of concepts developed rather than leaving without ownership.

0–10 minutes: frame the challenge

Present the brief in five minutes. Distinguish observations from interpretations. “Three people could not find the policy in a walkthrough” is an observation; “Search is the main cause of slow service” is a hypothesis requiring more evidence.

Use the remaining time for clarifying questions and a quick check that the challenge is worth addressing. Ask: “What do we know, what are we assuming, and what is outside today’s scope?”

If the evidence contradicts the brief, record the correction. If the problem itself is unclear, use the session to generate research options and say so explicitly. The Double Diamond is helpful here because solution development depends on a sufficiently understood problem.

10–20 minutes: generate independently

Give participants quiet time to sketch or write one idea per space. Ask for different mechanisms, not a target number of sticky notes. A contribution may be a changed handoff, a simpler instruction, a physical cue, or a service arrangement.

Offer prompts after the first few minutes: “What could we remove?” “What could the user do without waiting for us?” “How would this work with no new software?” Allow writing, diagrams, or dictated contributions.

CDC’s nominal group technique guidance separates silent generation from sharing and ranking. This workshop borrows the separation but allows collaborative development later; its sequence should not inherit claims made for the complete nominal group method. CDC evaluation brief

20–35 minutes: share and clarify

Go around the group, giving each person a short turn to explain one idea. Continue with additional rounds while time permits. Capture remaining ideas in writing rather than rewarding only those who speak quickly.

Ask questions to understand the mechanism: “What would the person do differently?” “Where does this happen in their day?” Defer evaluation until the options are understandable.

Group related ideas, but retain meaningful differences. A checklist and a coaching conversation may solve different problems despite both being called “onboarding support.” Do not let an attractive title conceal an unspecified mechanism.

35–50 minutes: develop concepts

Form pairs or small groups around a few promising directions. Each group completes a concept statement: “For this user and situation, we propose this change, because we expect it to address this problem.”

Ask them to sketch a short before-and-after journey or a simple interaction. Include what staff must do behind the scenes. A concept that appears effortless to the user may create substantial operational work.

Require each group to identify one assumption that could make the concept fail. Keep development rough enough to change. The aim is to expose how an idea works, not to make a polished pitch.

50–65 minutes: assess and shortlist

Agree criteria before expressing preferences. For this session, assess relevance to the observed problem, plausible user benefit, ability to test cheaply, and unacceptable constraints or harms. These are practical criteria; adapt them to the decision.

Have participants record an initial assessment independently, then discuss disagreements. A simple preference vote can focus attention, but it does not validate demand or prove feasibility. Ask an advocate of each shortlisted concept to explain the evidence and the weakest assumption.

The decision owner selects one or two concepts for testing and states the reason. If the preferred concept depends on a missing capability, that dependency may need a test first. Record promising alternatives so that the choice remains traceable.

65–80 minutes: design the next test

Complete a test card with the hypothesis, participants or setting, method, observation, decision rule, owner, and date. Ask: “What is the smallest credible test that could change our mind?”

For a proposed information aid, a paper prototype with realistic tasks may reveal whether people understand it. It will not establish long-term adoption or financial return. Match the strength of the conclusion to the test.

Write a decision rule in advance: what result would lead to revising, stopping, or continuing? Avoid choosing arbitrary percentages for a tiny sample. Define observable behavior and the learning sought, then acknowledge remaining uncertainty.

Check permissions, access, and operational constraints. A test that cannot be run is not an actionable output.

A CLOSER LOOK

Leave with a testable question, not a winning slogan.

1. 01
   AssumptionNew staff can recognize which entry on a proposed answer page applies to a realistic case.
2. 02
   Small testAsk intended users to work through a realistic task with the prototype.
3. 03
   What to observeWhere they hesitate, make errors or ask for help.
4. 04
   Decision & ownerName who will review the observations and decide what to revise.

Plan the test in the workshop. Run it afterwards.

80–90 minutes: confirm and close

Ask each owner to read the test card aloud. Confirm the next review meeting and where evidence will be recorded. The decision owner states what is authorized and what needs additional approval.

Close with a brief reflection: “What did we learn about the problem, and what are we still guessing?” Preserve those uncertainties alongside the concept rather than deleting them from the summary.

Hypothetical example: finding approved answers

A support team’s brief reports that new starters struggle to distinguish current policy from older guidance. During ideation, participants propose a chatbot, a curated landing page, clearer document ownership, and a coaching buddy.

Development reveals that a new search interface would still surface outdated material. The team shortlists a small curated answer page with visible owners and review dates. Its central assumption is that new staff can recognize which entry applies to a realistic case.

The next test uses a rough prototype and representative tasks with a few new starters. The team will observe wrong selections, hesitation, and requests for help. It plans to revise confusing labels before considering a broader pilot. None of these hypothetical results is presented as evidence that the concept works.

Common mistakes and adaptations

The sponsor pitches a favorite solution first. Present the problem and constraints, then let people generate independently.

Ideas are selected for presentation quality. Use the same concept fields and criteria for every option. Rough sketches should receive equal consideration.

The session celebrates volume. Count neither cards nor votes as customer evidence. Evaluate whether the team can explain a worthwhile next test.

People cannot challenge a popular concept. Invite specific doubts and thank contributors for making assumptions visible. Edmondson’s research links psychological safety with learning behavior; a workshop script alone cannot establish those interpersonal conditions. Edmondson’s study

For remote sessions, distribute the worksheet beforehand and use one shared capture space. For more than eight participants, use parallel small groups with fewer concepts each and a pre-agreed selection procedure. If access needs require more reflection time, collect individual ideas in advance and use the same meeting time for clarification and testing decisions.

Evidence and follow-through

The sources support broader design and participation principles. They do not establish that this exact 90-minute agenda is superior to alternatives or that its outputs will become successful innovations. The timings, prompts, criteria, and example are this guide’s practice guidance.

After the workshop, send a concise record of the selected test, rationale, owners, and outstanding questions. At the review, examine observations before discussing enthusiasm. Use a premortem when a concrete pilot plan exists, and innovation management to connect this small experiment to a broader portfolio.