Fluent Hoopla Labs: Building Competence through Mind(set) Games

The problem

When AI tooling arrived in our organization, our team got the unspecific directive to “use AI.” Given no guardrails, people respond with either avoidance or unstructured experimentation. Neither builds durable fluency.

My role

"You built the FHL repo yourself, wrote the onboarding, led the working sessions during the week, and ran the learning shareout for the team. And the work didn't end there. It catalyzed a v-team that's been executing against the vision ever since."

— Karlee Boillot, Senior Product Designer

I designed a voluntary program for Fluent’s Fix-Hack-Learn hackathon week. For Spring’s FHL, lovingly nicknamed Fluent Hoopla Labs, I delivered the pedagogical strategy, facilitator materials, and repo, and ran the Day 1 sessions. I scaffolded Days 2–5 with pre-seeded materials and additions I built progressively through the week, giving self-directed projects the structure they needed. I coached participants through the week as they applied Day 1’s mental models.

What I built

The repo	A shared monorepo for ~40 people working across a week, with clear branching conventions, setup scripts, and progressive materials
Game engine framework	Five pre-built runnable game apps with a shared prompt template, facilitator notes, and a 3-hour session agenda
The whodunit live demo	A worked example building a game engine from scratch for AI-scalability, demonstrating schema design, constraint definition, iterative refinement, and system prompt mechanics in real time
The Days 2–5 curriculum	Self-guided materials for applying the week’s skills to real design system problems like token generation, component documentation, design review, and accessibility checking

The pedagogical architecture

Day 1: Displacement learning

The goal of Day 1 was to set everyone up with the proper baseline. I created an FHL repo for the team to use and ran the setup sessions to get everyone to the starting line. Once admin was out of the way, the play began.

I avoided teaching prompt engineering through design system work so people could let go of domain knowledge and engage with a new skill. Plus, FHL is supposed to be fun. Diving into design system schemas would have been a normal Monday.

"The Fluent FHL AI project was your brain-child, and your prior share-outs were the exact knowledge I was building on to enable the system that you saw possible."

— Mitch Fraser, Senior UX Engineer

The solution: deliberate cognitive displacement. I built a game engine framework and told the team to take their design system hats off; we were going to make games. If I could get the team to think about the least common denominators required of all flavors of relay games, Catch Phrase or flip cup, I could teach them how to make durable component schemas.

The whodunit demo ran the moves live: brainstorm commonalities into a schema, layer in hard and soft constraints, lean on trusted references like Clue’s rules. I’d planted a topsecret.md file the model could see but didn’t let the audience read it. The model knew something the room didn’t, and that shaped its behavior.

Same schema, different mystery every time

None of this required knowing what a design token is. But in an afternoon the team was equipped with the mental model.

It’s the system’s job to define the scaffolding, the shape that is transferable, repeatable, durable. That’s the game genre, the umbrella. The partner teams define what the specifics look like. The schemas, the rules, and knowing how models interpret them all equips a more efficient design team.

Days 2–5: Transfer and application

"FHL was a masterclass in seeing ... a need and producing a bunch of days worth of content to get the team jazzed ... for scary AI learning. It was organized but flexible and your leadership that week prompted so much exploration and GOOOOD work."

— Stephanie Sullivan, Senior Product Designer

Displacement learning produces transfer. Participants didn’t leave Day 1 saying “I now understand how to write prompts for design system components.” They left having built a game schema or two. Further experimentation during the week gave them time to get comfortable working in new ways.

I encouraged the team to explore what they wanted. I provided mentoring, troubleshooting, helpful tips, additional materials, and suggested prompts. Apply the thinking to whatever they wanted: more games or real design system problems. I unblocked and helped participants move forward. A sample of the branch list tells the story.

Durable systems thinking

The workshop’s durable proof is the work that came after it. I architected the fluent-design repo the week after FHL, and a team of designers and engineers has been building inside it ever since.

"You have been a standout leader for the team, particularly through your work on FHL. Your leadership shows up not just in driving outcomes, but in how you bring others along."

— Domonique Stanford, Senior Content Designer

Six weeks after FHL, when the team hit a real problem, they could recognize the pattern. This is a schema problem. I need to define the least common denominators. In not so many words, “I need a hard constraint here.” Hands-on experience and a low-stakes environment created durable fluency.

FHL Wrapped: a celebration of the team that built it with me