A small design brainstorming session can turn a vague challenge into a focused set of possible solutions. With the right preparation, a group of four to eight people can generate useful ideas without letting the loudest voice, the first suggestion, or an unfocused discussion take over.
1. Define the purpose before inviting anyone
The quality of a brainstorm depends heavily on the question you bring into the room. “How can we improve the product?” is too broad for a short session. A better prompt identifies the audience, situation, and desired outcome:
- How might we help first-time users understand the setup process in under five minutes?
- How might we make the checkout experience feel more trustworthy on mobile?
- How might we help a busy manager find the right report quickly?
A useful design-brainstorm question is open enough to allow several answers but narrow enough that participants understand what they are solving. Avoid embedding your preferred solution in the wording. “How can we add a tutorial popup?” limits the group before it begins; “How might we help new users complete their first task?” leaves room for different approaches.
Write down the intended output as well. You may want ten raw ideas, three concepts to develop, or one experiment to prototype. These are different goals and require different amounts of time. For a small session, a practical target is to produce a broad list, cluster similar ideas, and select two or three concepts for follow-up.
2. Choose the right people and format
A group of four to eight participants is usually large enough to provide varied perspectives and small enough for everyone to contribute. Include people who understand different parts of the problem, such as a designer, product manager, developer, researcher, customer-support representative, marketer, or subject-matter expert.
Do not invite people only because they are senior. A hierarchy can make junior participants reluctant to challenge assumptions. If a decision-maker must attend, establish a rule that ideas are evaluated after generation rather than during it.
For a remote session, use a video call and a shared whiteboard or document. For an in-person meeting, provide a wall, large sheets of paper, sticky notes, thick markers, and a visible timer. The tools matter less than the ability to capture every contribution and keep the group moving.
| Session choice | Best use | Watch out for |
|---|---|---|
| In person | Fast sketching and energetic discussion | Side conversations and dominant speakers |
| Remote | Distributed teams and searchable notes | Silence, multitasking, and technical friction |
| Hybrid | Teams that cannot meet together | Remote participants becoming observers |
If the session is hybrid, give remote participants equal access to the board and ask everyone to join individually when possible. A room microphone pointed away from the group can make online participants miss important comments.
3. Prepare a lightweight brief
Send a short brief before the meeting, ideally at least a day in advance. Include:
- The design challenge and why it matters
- The users or customers affected
- Relevant constraints, such as time, budget, technology, accessibility, or policy
- What the group will produce
- Any background material participants should read
Keep the brief factual and compact. Too much research can cause people to defend existing conclusions instead of exploring possibilities. If you have user quotes, support tickets, analytics, or previous research, select only the evidence that helps participants understand the situation.
Prepare the workspace before the session starts. Create areas for the prompt, individual ideas, grouped themes, decisions, unanswered questions, and next actions. If you are using sticky notes, decide in advance whether one idea should occupy one note. This makes later sorting easier.
It is also helpful to assign roles:
- Facilitator: explains activities, watches time, and protects participation.
- Scribe: records decisions, questions, and important context.
- Timekeeper: gives warnings and helps the group move between activities.
- Decision owner: confirms what happens after the workshop.
One person can handle multiple roles, but the facilitator should not have to capture every detail while managing the conversation.
4. Open the session with clear working agreements
Start by explaining the problem, the outcome, and the agenda. Participants should know whether they are expected to create rough ideas, select concepts, or make a final decision. State that the first part of the session is for generating possibilities, not judging them.
Set a few simple agreements:
- Build on ideas before criticizing them.
- Give quieter people room to speak.
- Keep one conversation active at a time.
- Make ideas visible instead of relying on memory.
- Treat sketches and notes as disposable drafts.
- Separate facts, assumptions, and preferences.
A short warm-up can make the group more comfortable, but it should connect to the work. Ask participants to sketch three unusual ways to organize a familiar object, or to describe a frustrating experience from the user’s perspective. Avoid a long icebreaker that consumes the time needed for the actual challenge.
5. Start with silent individual idea generation
Discussion-first brainstorming often favors people who think quickly out loud. Begin with silent work so each participant has time to form ideas independently. Give the group five to ten minutes and ask everyone to write one idea per note.
Useful prompts include:
- What would make the current experience dramatically simpler?
- What could we remove rather than add?
- How would we solve this if we had almost no budget?
- What would a premium version of this experience feel like?
- What could we borrow from another industry?
- How could we help the user recover when something goes wrong?
Encourage quantity and roughness. An idea can be a sentence, a quick flow, a small sketch, or a question that reveals an opportunity. Participants do not need to defend their notes yet.
When time ends, ask each person to share their ideas briefly. The facilitator should clarify unclear wording without evaluating it. If someone begins explaining a complete solution in detail, thank them, capture the core idea, and move on so everyone gets equal time.
6. Use structured techniques when the group gets stuck
A general prompt is not always enough. Choose one or two techniques that match the challenge rather than trying to use every brainstorming method.
Crazy Eights: Fold a sheet into eight sections. Participants sketch eight different approaches in eight minutes. The short time limit discourages polishing and encourages variation. This works well for interface layouts, service touchpoints, and physical concepts.
How Might We prompts: Break the challenge into smaller opportunities. For example, “How might we reduce uncertainty before purchase?” and “How might we help users compare options?” Generate ideas for each prompt separately.
Worst possible idea: Ask the group to invent intentionally terrible solutions. Then reverse the ideas to discover useful principles. A “checkout that hides all costs” may reveal that transparent pricing is essential.
SCAMPER: Explore whether you can Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, or Reverse an existing part of the experience.
Role-based thinking: Ask what a first-time user, an expert user, a support agent, or an accessibility specialist might notice. This can expose needs that a general discussion overlooks.
Do not use a technique simply because it is popular. If the problem requires technical feasibility research, ideation alone will not provide the answer. The session should produce hypotheses for investigation, not pretend to resolve unknown facts.
7. Share, cluster, and name the themes
After individual generation, place all ideas where the group can see them. Group similar ideas by relationship, not by whether you personally like them. For example, notes about search filters, clearer labels, and better sorting may belong under “help users compare options.”
Ask participants to silently move related notes first. Then discuss ambiguous placements. Give each cluster a short descriptive name that captures the underlying opportunity. “Add a tooltip,” “show examples,” and “include a guided tour” might become “provide help at the moment of uncertainty.”
Clustering helps the team see patterns and prevents the selection process from rewarding a single polished note over a larger body of related thinking. It can also reveal gaps. If every cluster describes a new feature, ask whether there are ideas involving content, service, communication, or process instead.
Keep the original notes intact where possible. A discarded idea may become useful when combined with another concept later.
8. Select concepts with explicit criteria
Evaluation should begin only after the group has generated and organized ideas. Define selection criteria before voting so the criteria do not change to favor a preferred concept. Common criteria include:
- Value to the target user
- Alignment with the design challenge
- Feasibility within available resources
- Confidence in the supporting evidence
- Potential to learn something through a quick experiment
- Accessibility and impact on different user groups
Use dot voting for a quick prioritization pass. Give each participant three to five votes and allow them to place more than one vote on a strong idea if that matches your rules. Voting identifies interest; it does not prove that an idea is correct.
After voting, discuss the leading concepts against the agreed criteria. A simple two-by-two map can also help, such as user value versus effort. Avoid treating low effort as automatically better. A difficult idea may be worth exploring if it addresses a serious user problem, while an easy idea may be irrelevant.
Select two or three concepts for the next step. Record why each was selected and what uncertainty remains. This prevents the session from ending with a vague list of favorites.
9. Turn ideas into actionable next steps
End with a concrete handoff. For each selected concept, record:
- The user problem it addresses
- The proposed experience in one or two sentences
- The riskiest assumption
- The smallest useful prototype or test
- The person responsible for the next action
- The date for reviewing what was learned
A prototype might be a paper flow, clickable wireframe, scripted service scenario, landing-page draft, or short interview guide. Choose the cheapest representation that can answer the most important question. If the uncertainty is whether users understand a new navigation structure, a rough prototype may be enough; there is no need to build production software first.
Separate discovery tasks from implementation tasks. “Interview five target users” is a discovery action. “Estimate the engineering effort” is a feasibility action. “Update the interface” is an implementation action. Assigning all three to a single vague owner makes follow-through less likely.
Reserve the last five minutes to read back decisions and unresolved questions. Send the notes soon afterward while the context is fresh.
Troubleshooting common problems
One person dominates. Use silent writing, round-robin sharing, and a visible time limit. The facilitator can say, “Let’s pause there and hear from someone who has not spoken yet.”
The group criticizes ideas too early. Create a separate “questions and concerns” area and ask people to capture concerns without stopping generation. Return to them during evaluation.
Ideas remain too abstract. Ask who the user is, what they do, what they see, and what changes. Replace “make it easier” with a specific behavior or moment in the journey.
The discussion drifts. Point back to the prompt and place unrelated topics in a parking-lot section. Review the parking lot only if time remains or assign it to a separate follow-up.
Participants say there are no constraints. Add a deliberate constraint, such as “What could we do without changing the underlying system?” or “What could we test this week?” Constraints often produce more concrete ideas.
Remote participants are quiet. Use written contributions before verbal discussion, call on people by name in a supportive way, and confirm that everyone can see the board. Short breakout pairs can be more comfortable than a large-group conversation.
The team cannot agree on a concept. Do not force consensus prematurely. Select multiple concepts for small experiments, or ask what evidence would distinguish them. A testable disagreement is more useful than a compromise no one believes in.
Limitations and follow-up
A brainstorm is an idea-generation activity, not user research, usability testing, prioritization strategy, or proof of market demand. The participants’ experience can help identify possibilities, but it cannot substitute for observing or speaking with the people who will use the product.
Small groups can also reproduce the assumptions of the organization. Include different perspectives, check ideas against existing evidence, and look for users who may be excluded by the proposed experience. Treat accessibility, privacy, safety, and legal requirements as design considerations from the beginning rather than late-stage checks.
The session is successful when it creates a shared understanding of the problem and produces a manageable set of learning-oriented next steps. Schedule the follow-up before everyone leaves. Without an owner, a question, and a date, even an energetic brainstorm is likely to become an attractive collection of sticky notes rather than progress.