This collaborative activity will help everyone on your team to think about user experience. Includes a workshop recipe so you can try this with your team.

Ever since enjoying Stephen Anderson’s presentation on What board games can teach us about designing experiences, I’ve wanted to try board game design with our team. We’ve got several game enthusiasts on the team, ranging from the casual cribbage player to the hard-core collector, so it seemed like a great fit for us. Also, we needed a group activity that forced us outside of our comfort zone but was still relevant to our design and development practice.

Getting uncomfortable

We have weekly show and tells, agile retrospectives, monthly UX meetings, and monthly dev meetings in which we discuss industry topics and try to solve problems. Our goal is to improve our work, share ideas, and collaborate to improve our practice. But it’s hard not to get drawn into old chart-toppers like, “Should we use hamburger menus?” and “Are we writing good Jira cards?” Valuable questions for sure, but they’re not exactly forcing us outside our comfort zone.

Why tabletop games

Anderson’s idea is that the act of designing tabletop games has strong parallels to designing experiences. (He expanded his talk to include "tabletop" instead of "board" to include trading-card games). Both fields involve similar skills and challenge. Both must organize information, keep people engaged, and learn from user-testing. His main point is that game designers have something to teach experience designers: game designers test early and often, modify designs based on feedback, and have fast build-play-iterate cycles. Those three points are critical.

In agile, the spirit of rapid iteration is often lost in the letter of the everyday practicalities of delivering features and meeting deadlines.


It becomes all too easy to stop iterating. After all, iteration is hard. Iteration means re-working what you just finished. Iteration requires time, energy and discipline. 

I find Anderson’s premise compelling on a personal level. My family plays a lot of board games together. Although we rarely agree on restaurants, movies or travel destinations, board games are something we enjoy together easily. And games run deep for us; I remember my grandfather making me a game out of wooden blocks that was very similar to the Jenga of the 80s. My husband worked on a passion project a few years ago that let tabletop players collaborate in a virtual space. At least two closets of our house are dedicated to game storage; we used poker to teach probability to the kids at a young age (don’t judge, it works); and we each have passionate opinions about Free Parking in Monopoly. 

Bringing the experiment to Industrial

But as much as I play games, I don’t know much about designing them. The first challenge for us as a team was to gain consensus on the point of the activity and the goals, then to decide how to give enough structure to the activity so we could learn from it. 

Instead of designing a structured activity and foisting it, untested, on the team, I decided to test the waters at our monthly UX meeting. Hypothetically, if we were to use game design as a learning activity, how would we go about it? 

My expectation was that the team would be kinda interested, and that there might be a few ideas. I saw myself standing at a whiteboard, waving my arms around a lot, trying to instil excitement into a tepid crowd, a note of desperation in my voice.

Um, yeah. Turns out, people are kinda passionate about games. The session quickly turned into an hour of passionate, rowdy, and opinionated brainstorming. 

In short, it was pretty awesome. Rowdy isn’t what we need when we’re trying to get our client work done. But when we are trying to force ourselves to take creative risks, disrupt our internal processes, and spark collaboration, rowdiness is perfect. It pushed us outside the bland civility of, "Is that Jira card ready to move to Test?" to the controversial but constructive, "I don't agree with your idea and here's why."

Sometimes a little controversy is a great catalyst.


In the end, we needed three separate sessions to get from open-ended brainstorming about the concept of game design, all the way to a playable prototype. If you want to use this for your team, here’s the recipe that ended up working for us. Let us know if you try it and how you adapted it to work for your team.

Tabletop game design workshop

Session 1: Setting the stage

Time: 60 minutes

Supplies: a whiteboard

What: Introduce the idea of tabletop game design as similar to experience design and discuss as a group (information organization, visualization, testing, collaboration, etc)

The goal: Decide on the logistics of your next session which will be the design and build session. What limits you will put on the sessions? What kind of supplies will be allowed? Who will bring what?

In advance of the next session: Get 3 containers and label them - Place, Characters, and Objective. Encourage everyone in the office to contribute to them by writing ideas on slips of paper and putting it in the containers. We needed this external ideation to help us find a starting point. We found that as a group we had so many ideas for games and narrative that we were having a hard time deciding where to start. This way, everyone gets to put their ideas on paper and the random draw adds an element of fun to the whole thing.

Session 2: Design and build

Time: 2 hours

Supplies: raid the stationery cabinet for big sheets of paper, markers, coloured stickers, post it notes, some dice, and something for players. I brought a box of Crazy Bones, these little colourful plastic figurines, but you could use coloured paperclips.

To begin: Draw one slip of paper from each of the 3 containers. 

We got lucky, and drew three things that went well together:

  • Place: Trappist 1
  • Character: Assassin
  • Object: Alien Invasion

We agreed afterwards that if we had drawn three things that didn’t work together (for example, we could have drawn The Kremlin, Talking lobster, and Make a million dollars) we would draw again until we had something to work with. We wanted to challenge ourselves, but within reason. 

Then the hard part: design and build a game. Ask questions like, how do you win? How do you move? Are there traps or dangers? Should this be relaxing, friendly, or stressful?

Warning: this session will get loud and messy. Just like it’s messy when you start a digital project with very little information.

The goal: build a rough, semi-playable prototype. If you are like us, you will probably end up with something that’s too complicated to play, but with lots of creative ideas. 

Session 3: Learn, play, learn

Time: 2 hours

Learn: Take time as a group to recap what you found out about the process and the parallels to experience design. We filled an entire whiteboard and could have kept going. I'll share our lessons-learned in a follow-up post.

Revisit the prototype and recap the rules and elements of the game. As a group, look at what can be removed from the prototype to make it playable. Focus on the playability of the prototype, not the fun. (Hint, this is your MVP). Can players move and make progress, and is it finishable?

Play: Play the game. This is a disruptively simple idea. You might look at your prototype, which won't be very polished, and think it won't be playable. Just start. You will find out immediately if it's viable. If it's not, tweak the rules or components and try again. 

Learn: Talk about what you learned and how you would improve the game. For example, we learned that our MVP was actually quite playable. But we also noticed that it needed some randomness to create a sense of risk. Also, that we needed systems for tracking progress. 

Board game prototype

Session 4 and beyond?

Whether you continue to Session 4 and beyond is up to you. I know we’re going to keep working on our game. And the approach is simple: Play-Refine-Learn.

I’ll talk more about the parallels we discovered between tabletop game design and experience design in my follow-up post. But the key lesson for us was in the early testing and the focused collaboration. Instead of one of us mocking up a game then handing it to a builder, which probably would have resulted in a more polished prototype, we designed and built our prototype as a group, and tested it together. It was more chaotic and less comfortable than we’re used to, but we learned what needed to be improved in our design together. And, because our first prototype was assembled quickly and was completely unpolished, we felt no regret in removing or rearranging components.