If you’ve ever sat through a requirements workshop thinking it was wasted time, maybe you’re ready to take on some new tools to get what people really need out of their heads, and into the world. One tool that I started to use in 2002 is design games: game-like activities that help my team gain insight, understanding, and clarity while avoiding dry and often unproductive meetings.
I’m a passionate proponent of ethnographic field studies and other ways of gaining human-centered insight. At the end of the day, that work needs to dovetail with organizational realities and requirements—and understanding business vision and drivers is where we often use design games.
In this article, I’m going to talk about four things: why we use games, core game principles, how to apply games, and how to sell design games to your organization or client.
First, games create conceptual touchstones—shared references that bridge different points of view and provide a common platform for conversation. That’s what most design deliverables try to do, with varying degrees of success. That brings us to the second reason: games are participatory. Instead of the design team holing up to produce some artifact for approval, games can involve a broad spectrum of players, and that creates buy-in as well as common ground for conversations. The accessibility of gameplay means that it’s not just a team of specialists involved, and the diversity of viewpoints from a broader group makes for better insight and innovation.
Finally, games tap into different ways of articulating ideas that help bring tacit knowledge to the surface. Tacit knowledge is often the key to successful requirements, and yet design teams often miss the implicit assumptions and elements that people can’t articulate on demand: asking people what they really need is likely to give anything but. Games can help surface this missing understanding.
Three Game Examples
The IA Slam
Part roleplaying, part case study, The Information Architecture Slam is an ongoing session at the annual IA Summit. Other design slams have emerged as well, but the IA Slam is the gold standard. The facilitators role play various client characters, often an executive, a marketing manager, a product manager, and a project manager. Each character comes with a distinct set of quirks, priorities, and misinformation that teams have to digest as they are assigned a design brief for a product or service.
Teams spend time brainstorming and coming up with solutions, and then present to the whole group. Sometimes the solutions make sense, and other times they just offer comic relief; the important thing is that people work together collaboratively and stretch their imagination, empathy, and innovation skills.
Design the Box
The Design the Box concept (which I learned about from the JoelOnSoftware blog) is a way to puzzle out a vision statement.
In this game, individuals or teams create a box, as if the project is going to be sold at retail. Small groups work together to answer key packaging questions: What’s the tone? The name, the tagline, the short hook on the front to entice a consumer to pick it up? What are the features and functions, the details that connect this product to some real need? Those go on the back of the box. What about system requirements?
The output can be a digital rendering or an honest-to-goodness physical box. The key is that this artifact creates a touchstone for the project—a concise expression of what the project is really about. Designing a box constrains and focuses teams to discuss what’s really important, and for who.
Not only is the output playful, but you can create teams to work together on generating box ideas. Whether the group with the most ideas gets cookies, or the team that creates the best idea for customers gets to pick lunch, or if the team with the key positioning statement that reframes the product gets to have a go at the boss in a dunk tank, keeping box generation playful fits with the playful nature of the artifact itself.
Even though it’s a playful output, it’s highly practical; one client kept a box on his shelf for six months, and would toss it over anytime someone asked what his team was doing with the new intranet. People understood the core of the product immediately, and enjoyed the break from reading yet another document describing an initiative.
Variations of this game include creating the product press release, movie poster, movie trailer, magazine or newspaper article. The keys are 1) constraining the form so that the participants are forced to prioritize the many (conflicting) ideas they have about the product, and 2) producing a concrete touchstone that bridges competing viewpoints and perspectives.
MetaMemes is a hilarious brainstorming card game developed by creativity consultant Kes Sampanthar. (Where else do you get to combine the Heisenberg Uncertainty Principle, Grossout Humor, and banking for tweens?) There are 214 cards, which illustrate ideas, words, and objects. Players combine cards in their hands with cards from other players to create new ideas. After several rounds, each player has an opportunity to collect their best ideas, and the players vote to pick the winning idea from the group.
Unlike some other design games, MetaMemes is a commercial product designed to support creativity. The polish of a commercial product means that it can have more credibility than a homegrown solution. However, being completely finished and packaged can make it harder to adapt a commercial product to fit your specific situation. When a commercial product does fit your needs, it can save a lot of time and headache.
MetaMemes has recently launched a new version, called ThinkCube, that’s geared even more to the needs of teams brainstorming ideas. I haven’t seen it yet, but I’m eager to check it out.
Luke Hohmann’s “Innovation Games” Book
Luke Hohmann has collected 12 design games in his book “Innovation Games: Creating Breakthrough Products with Collaborative Play,” well worth checking out for more formats and examples.
Design Game Principles
While it’s great to talk about different design games, the real power comes from understanding the underlying principles at work so that you can successfully adapt and adopt for your own specific situation. Design games share six core principles with all games that help us recognize opportunities to bring games into play.
- Objectives: There needs to be some kind of goal or outcome that people can work towards. The more concrete and defined these are, the easier it is for people to participate. However, fuzzy objectives can be more rewarding, since they model real situations better. Consider more ambiguous objectives for teams that are already gelled and accept the ideas for design games.
- Constraints: There needs to be some limits on what players can or can’t do when achieving those objectives. Constraints should be relevant, related to each other, and present a coherent whole.
- Success criteria: There needs to be some way of knowing when the objectives are met. Clear success criteria help establish expectations and buy-in for game participation. Some games are more unstructured, with less well defined criteria. Classic role-playing games like Dungeons & Dragons don’t have a clear overall objective. That ambiguity can make such games better able to model some scenarios, but harder to sell inside an organization because they don’t have a set ending.
- Reward: Incentives that reward success can be intrinsic outcomes of the game (good results, recognition), embedded in the game itself (getting more Monopoly money), or external recognition or prizes (the winner gets dinner at a nice restaurant). Balancing rewards between players can be a challenge, and needs to be considered when adopting games.
- Play: The most important reward needs to be a sense of fun, encouraging interaction and intrinsic value for the game. That sense of play can be elusive—playtesting a design game in your own team is important to get a sense of what is fun, and what isn’t before you roll it out with a larger group. Play operates in the area of flow—balance the challenges of the game with the abilities of the players.
- Competition (sometimes): Sometimes, but not always, design games can involve individuals or teams competing to achieve those game objectives. While competition can be an easy game mechanic to introduce, it can also create the wrong dynamic depending on organizational culture and individual participants. Does competition make things fun, or turn people into raving lunatics bent on winning at all costs? If it’s the latter, you might look for more cooperative alternatives, including setting competition against previous performances, like beating your old record for ideas generated, instead of against other teams or individuals.
Design game organizers also need to consider whether the game should try to model the current situation (prototyping for example), or teach mindset and universals that support the participants’ needs such as roleplaying to encourage teamwork skills.
By keeping these principles in mind, opportunities for design games can emerge from the normal rhythm and flow of typical projects in your organization.
To learn more about game principles, check out “Rules of Play: Game Design Fundamentals.”
Taking advantage of those opportunities can involve three approaches to applying games:
- Modifying current activities: Find existing, accepted activities, like brainstorming or workshops, and look for entry points to introduce game principles. For a brainstorming session, this might include setting the outcomes (generate as many ideas as possible), constraints (time limit, ideas need to address a particular customer group), success criteria (simply counting the number of ideas), rewards, play (etc etc), competition (working in teams or individually, see who has the most ideas, who creates ideas that combine different disciplines or areas).
- Using existing game formats: You can use games that other people have developed—from Designing the Box to Metamemes to the IA Slam. Luke Hohmann lists 12 games in Innovation Games that can work for various situations.
- Creating new game formats: If you’re dealing with a situation that other game formats don’t support, you can create a new game. Before you make that effort, consider whether a game will give you better results, and if the extra effort is worthwhile. Creating a game from scratch can be rewarding, but takes a lot of time. This makes sense for activities that are frequent or are large enough that the extra effort is going to pay off.
Of course, all of this talk about design games is just talk until you can apply it on a project. The challenge is getting buy-in for using games. Sometimes the novelty of design games is a selling point, but the secret for us is that we don’t sell design games. In fact, I hardly ever talk about games with clients. Instead, I talk about design games in terms of what the activity is or what it does. Using language to reframe games puts them on an equal footing with other discovery and requirements activities. Some of the terms I use to talk about design games include:
- Innovation tools for structured brainstorming and increased creativity (MetaMemes)
- Team building exercises (Improv)
- Participatory requirements gathering (Design the Box)
- Live case study exercises (IA Slam)
- Facilitation tools
- Facilitated system modeling
- Artifact collection exercise (scavenger hunt)
No matter how you talk about them, design games can add vitality, energy, and fun to your work and change the game of requirements gathering with your team.