July 2026

Building an Interactive Prototype for an In-Person Leadership Experience

A few months ago I got pulled into my first real pursuit working alongside our engineering team, and I said yes before I let myself think too hard about whether I actually knew how to do the job in front of me.

The brief Design a live, in-person experience for a group of leaders. Split them into roles. Hand each person a different slice of information, none of them the full picture. Put a countdown clock on the wall. The only way through is to talk to each other, fast, while the clock runs, with someone in the room whose job is to keep the conversation moving and call out what people are missing.

I'd led plenty of creative concepts before this. I had never built an interactive prototype. I didn't know the tools, I didn't know what was actually feasible to build in the time we had, and I definitely didn't know how many rounds of iteration it would take to get from "this is a cool idea on a slide" to "this is something a room full of executives could sit down and actually use." So I leaned in anyway, and figured out the rest as I went.

What I didn't expect

The mechanic matters more than the theme. It was tempting to spend all our energy on how the experience looked. What actually made it work was the underlying structure: asymmetric information, real time pressure, and a facilitator role with the authority to surface what individual participants were sitting on but not saying out loud. Get that right and almost any theme sits on top of it well. Get it wrong and no amount of polish saves it.

Working with engineers changed how I write a brief. I came in used to briefing creative concepts. Briefing something that has to actually run, with real state, real timing, and real edge cases, is a different discipline. I learned to describe behavior, not just look and feel, and to ask "what happens when someone does X" a lot earlier than I used to.

The prototype's job isn't always to survive. The specific version I built didn't make it into the final pitch. A sharper, simpler version of the same idea did instead. But the pacing, the escalating pressure across rounds, and the way the shared board revealed who withheld information and who didn't, all of that came directly from what I learned building the thing that got replaced. Half of what a prototype is for is teaching you, and everyone around you, what the real idea actually is.

I'm including a look at the prototype below, altered from the client version for confidentiality, plus a small interactive mockup underneath that illustrates the same interaction pattern in generic form: three roles, a shared board, a moderator, and a clock that doesn't care if you're ready.

The prototype

Screen recording of the decision console prototype: three role cards with live-updating readouts, a shared board, a moderator banner, and a countdown timer.
The actual console mid-round, altered from the client version for confidentiality.
Try a generic version of the same pattern
3:00
Role A

You know the budget is fixed.

Role B

You know the deadline just moved up.

Role C

You know one stakeholder will block this.

Shared board
  • Nothing shared yet
Facilitator: what are we still missing?

More from the Journal