Designing a Practice That Outlasts the Workshop
The Harvard Business School Digital Initiative wanted a durable way of working that would keep inclusive design alive after the engagement ended, when no outside facilitator was in the room.
The brief
A different design problem than a workshop
The output is a team that knows how to do something they didn't know how to do before, and a set of tools they can actually use on their own.
That's a different design problem than delivering knowledge. The question shifts from what you teach to what capability you leave behind. The brief required designing not for the moment of delivery but for the months after it, when the HBS Digital Initiative team would apply what they learned to real projects without external support.
I joined as Lead Facilitator, Designer and Coach through Superfriendly, collaborating with David Dylan Thomas, author of Design for Cognitive Bias.
A workshop ends. A practice continues.
Designing for a practice means designing for the moments when no facilitator is present — when a team member needs to explain why a metric is biased, run a power mapping exercise, or push back on an assumption in a sprint review. The curriculum had to create that capability, not just the memory of having learned something.
The architecture
Six sessions, each building on the last
The facilitation architecture was six interconnected sessions, each assuming the vocabulary and instincts developed in the one before it: a practice built in stages.
6
Interconnected sessions
6
Participants through the full program
1
Living playbook the team owns and evolves
- Cognitive Bias FoundationsDavid Dylan Thomas grounded the group in a shared vocabulary for the specific ways bias surfaces in content decisions, metric choices, and design assumptions.
- Goals-Setting & CommitmentPushed the team past abstract values to articulate what inclusive design actually meant for their work: specific, measurable commitments tied to real projects and real decisions.
- Community, Power & Pod MappingMade power dynamics visible and diagrammable: who does this team currently center? Who is most affected by their decisions but has the least voice? Where does the gap between intention and impact live?
- Problem FramingTrained the team in a specific discipline: staying with the uncertain, messy work of understanding before moving to solution. Jobs-to-Be-Done framing built the reflex of interrogating the problem before designing for it.
- Applied Practice — DI People PageApplied everything to a real project — the DI "People Page" — using journey mapping, values-based prioritization, and lo-fi wireframes as thinking tools rather than deliverables. The point was practicing inclusive decision-making on something that actually mattered; the wireframes were scaffolding.
- Synthesis & Playbook DevelopmentConsolidated the team's shared language, exercises, and decision frameworks into a living document they could reference, teach from, and evolve independently.
The artifact
The Inclusive Design Playbook
The primary designed output was a custom Inclusive Design Playbook: a living document capturing the team's principles, exercises, and decision frameworks in a form they could reference, teach from, and evolve. The language and frameworks are the ones this particular team arrived at through this particular process, rather than generic inclusive design theory.
Designing it was its own design problem. It had to be specific enough to be useful, structured well enough to function without a facilitator, and feel owned by the team rather than handed down to them.
- Bias-informed design principlesThe cognitive bias vocabulary from sessions 1–2, translated into actionable principles for the team's specific design context.
- Ethical research methodsResearch frameworks that center affected communities as active participants in the design process, not subjects.
- Participatory frameworksPower mapping and community mapping exercises documented with facilitation notes so the team could run them independently.
- A commitment frameworkTools for keeping inclusive design visible in day-to-day work — in standups, sprint reviews, stakeholder presentations — not just dedicated sessions.
- A living documentDesigned to be returned to as the team's practice matures. The test: could someone who wasn't in the sessions pick it up and use it?
The reflection
What's different here
The facilitation design took the same skills as any complex UX problem: understanding what the user actually needs (capability, not just knowledge), sequencing the experience so difficulty builds appropriately, designing exercises that translate theory into embodied practice, and creating artifacts that outlast the engagement.
The difference is that the interface was a room of people, and the product is a changed way of working. There's no Figma file for that and no launch date. The only measure: six months later, does the team still use what they learned?
Never design an exercise that produces an output the room won't own.