Meeting facilitation, Miro, and magic wands

Even a library is louder than a crowd when the word "working session" is brought up in a meeting.

It's not a comfortable silence. You can actually feel the room collectively decide to wait each other out. I've sat in that silence a few times, and as a UX designer, I needed to fix it. I needed ideas that weren't my own from experts brimming with knowledge. I just had to unlock it for them, because a blank slate is anything but inspiring.

Facilitation is design work. I mean that running a workshop is a design problem the same way building a product is a design problem. You have users. You have a goal. You have constraints. If the experience you design is bad, people disengage. Same as any screen you've ever put in front of a test participant.

The difference is that most of us were never taught to think of it that way. We were handed a Google Meet link and told to "run ideation."

So let's talk about what actually works.

The board

I introduced my organization to Miro, and I've been in enough sessions to know that an empty board is not a workshop. The board has to be built before anyone enters the room. This is the invisible work of facilitation that everybody benefits from. Assign your sticky colors in advance. Blue for user needs, yellow for feature ideas, pink for constraints, whatever. It sounds overly rigid until you're trying to make sense of 80 identical yellow notes. And it's not just you that's getting overwhelmed...

I had amazing success laying out a competitive audit using Miro. We picked apart what we liked and what we didn't, and I had to explain almost nothing because I laid out the board in a way that led my team through the task. Saying "lightning rounds" doesn't spark ideas, and mentioning "card sorting" can elicit a trauma response. Skip the labels and lay out the task without expectations.

Use the templates as scaffolding, not as the session itself. A Crazy 8s board you've modified for your team's specific problem will always outperform a Crazy 8s board you opened at 9:58 for a 10am call.

The magic wand

Then comes your prompts. A dev team has constraints, but sometimes staff get so hooked on working in those restraints, they let their dreams fizzle away. That's why I use my magic wand:

If you had a magic wand and could build anything for this user — no technical constraints, no budget — what would you build?

What the magic wand actually does is remove the internal censor that most people carry into a room full of engineers and stakeholders. The one that whispers: we'd never build that, they'll think this is stupid, that would take years. Permission to dream is rarer than it should be in professional settings. When you give it explicitly, people take it.

The ideas that come out aren't shipping next sprint. The fantasy only reveals what someone actually believes would solve the problem. A magic wand answer is often just a real answer with the fear taken out of it. From there, you work backward: what's the smallest version of this? What principle lives inside the wishful thinking?

I've watched features make it into products that started as a magic wand answer. They're usually the most interesting ones.

The structure

If you're structuring a workshop, here's roughly how I'd move through it:

Start with an opener. Just talk with your team for a bit, because their work is about to be scrutinized in real-time, and cat discussions do a pretty great job at diffusing a room. You'll find better ideas if you leave room to breathe.

Then give some time for genuine problem alignment. A conversation about who this user is, what they need, and what prompted the project. Put the problem statement somewhere visible on the board and leave it there.

Your board is already laid out, and someone on your team has likely already started brainstorming ideas because cat conversations bore them and they're ready to go. Once you've explained the task, let them be the technical model for others to follow behind.

From there, share and cluster. Let people walk through their ideas without debate, just clarity.

And one secret? Don't go over your scheduled time. If you need more time, schedule a follow-up. This keeps trust between you and this crew that you respect their time.

None of this is revolutionary. The revolutionary part is the facilitator staying out of the content — not putting your own stickies up, not steering the ideas, not treating the session as a chance to advocate for the thing you already think you should build. The job during the session is to watch the room. Draw out the person who's been quiet. Redirect when the conversation drifts. Keep time.

Do the real thinking before you walk in, so everyone else can match the real thinking while they're there.