Designs the structure of a cross-functional workshop or design-thinking session using the Double Diamond and the Diamond of Participation, with explicit divergent, groan-zone, and convergent phases and a stated decision rule. Use when planning a workshop that has to both generate ideas and actually reach a decision, not just produce \"great discussion\".
Installs into .claude/skills of the current project.
Are you the author of Workshop And Facilitation Design?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/pilot2service-workshop-and-facilitation-design)
---
name: workshop-and-facilitation-design
description: "Designs the structure of a cross-functional workshop or design-thinking session using the Double Diamond and the Diamond of Participation, with explicit divergent, groan-zone, and convergent phases and a stated decision rule. Use when planning a workshop that has to both generate ideas and actually reach a decision, not just produce \"great discussion\"."
---
# Workshop & Facilitation Design
## Purpose
Designs the structure of a cross-functional workshop or design-thinking session.
## Anchored in research
- Perplexity research — running workshops and design-thinking sessions
- Design Council (2004) — the Double Diamond (Discover, Define, Develop,
Deliver): alternates divergent and convergent phases. A workshop meant to
both explore a problem and converge on a decision needs to make that phase
switch explicit to participants.
- Kaner et al., *Facilitator's Guide to Participatory Decision-Making* — the
Diamond of Participation: a divergent zone (generating options), a "groan
zone" (the necessary, uncomfortable phase where the group aligns on
meaning before it can converge), and a convergent zone (narrowing to a
decision). A workshop that skips the groan zone produces premature,
brittle agreement.
## Method
1. **Clarify the workshop's single deliverable and where it sits on the
Double Diamond** — is this a Discover/Define session (diverge on the
problem, converge on a framing) or a Develop/Deliver session (diverge on
solutions, converge on a decision)? Mixing both in one session without
saying so confuses participants about when they're allowed to disagree.
2. **Design the divergent phase first** — generate the widest reasonable set
of inputs (problems, ideas, options) before any evaluation. Introduce
evaluation criteria too early and the group anchors on the first idea.
3. **Budget explicit time for the groan zone** (Kaner) — the point where
diverse inputs collide and the group has to build shared understanding
before it can converge. Rushing this step produces a decision that
unravels once people leave the room.
4. **Design the convergent phase with an explicit decision rule** —
dot-voting, a scoring matrix, or a named decision-maker who breaks ties.
A workshop that diverges well but never states how convergence will
happen ends in a non-decision.
5. **Sequence the agenda in blocks with a facilitator role and timing per
block**, not just a topic list — who's driving, how long, and what
artifact comes out of each block.
6. **Plan the close: decision, owner, and next step, captured before people
leave the room.** A workshop that "generated great discussion" but ends
without a captured decision and owner hasn't produced a result.
7. **For fast-moving AI prototyping specifically, consider a real-time,
cross-disciplinary working session instead of a staged workshop.**
When development, design, and business stakeholders review and adjust
an AI prototype together, live, in the same physical or digital space,
feedback is immediate and the discover/decide cycle above can compress
into hours instead of a multi-day workshop cadence. This isn't a
replacement for the structure above — it's a format choice for when the
material under discussion (a working prototype that can be poked at
directly) makes live, side-by-side reaction more valuable than a
scheduled agenda with prepared materials. Use it for prototype review
and refinement cycles specifically, not for the initial problem-framing
work that still benefits from the Double Diamond structure in step 1.
## What this skill does NOT do
- Doesn't make the final decision for you — it produces a structured draft to
support a human decision.
- Doesn't confirm figures, market data, or competitor data from memory — it
uses the inputs you provide, or marks an assumption clearly
(`[assumption — verify]`).
- Doesn't facilitate the workshop for you — it designs the structure and
timing for the facilitator.
## Refinement notes
Areas to keep deepening with real practice:
- your own rules of thumb and heuristics for this technique
- concrete templates (into [`../../references/`](../../references/))
- reference cases / your own examples
- what this skill deliberately does *not* do (guardrails, common mistakes) —
add to the list above
This is an internal working note, not a claim about the skill's current
usability. Track depth privately via the `maturity` field in
`skills_index.json` (see
[`../../../meta/maturity_levels.md`](../../../meta/maturity_levels.md)).
**Don't add new fields to the frontmatter** — `name` and `description` are
the only ones allowed (see
[`../../../meta/frontmatter_schema.md`](../../../meta/frontmatter_schema.md)).
## Continue from here
- Next in this pack: [`../executive-narrative-and-storyline/SKILL.md`](../executive-narrative-and-storyline/SKILL.md) — Turns analysis into a narrative and storyline that serves executive decision-making.
- A ready-made skill chain for this situation: see [`../../../playbooks/`](../../../playbooks/)
- This pack's shared guardrails: [`../../CLAUDE.md`](../../CLAUDE.md)
## References
- [`../../references/`](../../references/) — the pack's shared background material
- Step 7's real-time cross-disciplinary format is grounded in the general
underlying idea only (live, siloless collaboration beats staged
handoffs) rather than in a specific named model — a named model and its
attributed originators could not be independently verified, see
[`../../../human-ai-collaboration-design/references/hitl-partnership-heuristics-research.md`](../../../human-ai-collaboration-design/references/hitl-partnership-heuristics-research.md)
- [`../../CLAUDE.md`](../../CLAUDE.md) — the pack's shared guardrails