Using Design Games

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.

Why Games?

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?

box_render_sm.jpgThe 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

metamemes_photo.jpgMetaMemes 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.”

Applying Games

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.

Selling Games

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
  • Simulations
  • 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.

Posted in Discovery, Research, and Testing, Learning From Others, Methods | 10 Comments »

10 Comments

  • Terry Bleizeffer

    July 19, 2007 at 1:23 pm

    Here’s another game format that can be used, though it’s fairly specialized. If you work on a large project, you might run into these two problems. First, many of the developers might not have experience using their own product (if the developers are very specialized) which causes several problems, such as difficulty in transitioning developers between areas and career development. Second, discussing user experience problems can feel very esoteric to developers who don’t use the product. One technique to address this is to create a competition in which developers are asked to complete a series of basic customer scenarios using their own product (but usually outside their own area of specialty), and while doing the scenarios they need to discover UX issues and propose solutions to the problems. The developers (who might work in teams, depending on the product) win awards for proposing the best solutions. This technique provides positive incentives to use the product (rather than executive mandate), and ensures that UX will be their focus while they do it.

    Of course, as Jess said in the article, just don’t call it a “game”! That’s the kiss of death for any game technique.

  • Nancy Frishberg

    July 20, 2007 at 1:33 am

    Delighted to see playful techniques promoted. For tapping into people’s tactile sensibilities, storytelling and collaboration, I have urged “Prototyping with Junk” (Interactions, Jan-Feb 2006) as a way to create very rough 3D prototypes that can be shared with a group. The article is accessible at http://portal.acm.org/citation.cfm?id=1109086&coll=portal&dl=ACM&CFID=28986594&CFTOKEN=33618158 ; ACM registration is required.

    Let me also draw readers’ attention to an important difference between the techniques mentioned above, and those advocated by Luke Hohmann (sic) in his Innovation Games® website, book and training: Hohmann urges product teams (represented by marketing, engineering, executive management, customer service, and any other relevant stakeholders) to take the role of observers, be active listeners and notetakers, while the players are the customers and users of the product or service. A great way to listen to customers!

  • Luke Hohmann

    July 20, 2007 at 4:09 am

    Jess –
    Thanks for the reference to my work. One minor point — can you please correct the spelling of my name? I missed this until Nancy forwarded it to my attention!

    I’d like to add a few more things. If you’re interested in some deep philosophical underpinning about games, I recommend reading James P. Carse’s wonderful little book Finite and Infinite Games. Innovation Games® is partially based on the notion that the (ideal) relationship with your customer is infinite and that finite games (such as the ones you describe) are played in the context of this infinite relationship.

    I’d also like to stress that there is a fairly substantial difference between the “Design the Box” exercise you describe (and it’s variants) and the Innovation Game® Product Box. In Product Box, the focus is external, on your customer. What do they want? How do they design the box? What images do they use?. In “Design the Box”, the focus is internal, on the internal product team. What does the internal team want? How does the internal team design the box? What images do the internal team choose?

    This difference in focus also results in a different process. In Product Box, we celebrate the many and varied boxes that customers generate during the game, as these create a rich source of information that we can mine for innovations. In “Design the Box”, the goal is create a unified consensus around what the team is going to do. Thus, while many boxes or data sheets may be created, the team works together until one is selected.

    When you’re looking to create the foundation of customer understanding that drives innovation, use the externally focused Product Box. When you’re looking for a fun way to help an internally focused project team gain clarity about what they want to build, especially at the beginning of a project, use “Design the Box”.

    To see some of the fun in action, check out: http://www.flickr.com/search/?q=Product+Box.

  • Holger Maassen

    July 20, 2007 at 6:39 am

    In my point of view there are roughly three related areas of human activity related to any kind of development – Often these sections are to some extent overlapping.
    __Creativity
    __Problem solving
    __Design
    Creativeness is the process of generating something new that has value, attraction and attaches importance to the user.
    Typically I use the term creative methods / creative techniques. But often it isn´t very helpful to be to technical – to formal – so I transform these techniques into games – to get a bigger involvement.
    The methods I use most are …
    __Brainstorming (or its variants)
    __Mind mapping
    __Storyboarding

    … and sometimes …
    __Provocation
    __Brainwriting
    __6-3-5 Method
    __Six Thinking Hats
    __Walt-Disney-Method

    Not only in my work brainstorming is by far the most known and widely used of all creativity methods. It is evident that this technique is an effective method that may uncover good ideas. However, it is questionable whether this technique is suitable and the one that best fits all situations. It is not enough to use creativity methods, it is necessary to select and use them accurately in order to maximise their performance potential.
    Especially in Germany is the mixture of fun ( e.g. the subject joy of use) or games and business a very negative, refusal combination.

  • Roger Evernden

    July 20, 2007 at 9:31 am

    Here’s another simple game to provoke discussion about the words we use and how we classify things. I started using this several years ago, and now use standard cards and materials that I have prepared in advance – but it can easily be adapted so that the players create the game pieces. I call the game Buckets (or Category Buckets).

    List the categories and words that you want to analyse or discuss. Put each on a separate card. You will need two or three sets of these cards, depending on how many teams are participating in the game. I use a set of about 200 key words and phrases – the actual number will vary depending on the domain that you are exploring.

    List any high-level categories that have been proposed. Write each one on an envelope or box (like a post box or voting box). I start with a set of 10 high-level categories, but again this can be expanded; if the domain has a large vocabulary, then you may want to introduce a hierarchy of categories that can be refined over several iterations of the game. Again, you need a set of these for each of the participating teams.

    Teams now put the categories or words on the cards into the envelope with the high-level category that they think is appropriate.

    Now the real fun starts. When all the words have been placed into their envelopes, teams compare and discuss their selections. This is where you find out nuances of meaning, different reasons for classifying in different ways, etc.

    Roger Evernden

  • Jorge Arango

    July 20, 2007 at 1:21 pm

    Hi Luke, I’ve corrected the spelling of your name in the story. (Sorry about this!)

  • Kes Sampanthar

    July 22, 2007 at 6:05 pm

    Jess,

    Thank you for the reference to ‘MetaMemes’ in your article. I like the way you use games in the design process. Games create a great environment to allow people to relax and have fun which is very conducive to creative thought and stimulates great conversations. Using games at work, changes the dynamics of a meeting can be far more productive than ‘business as usual’. I find games work really well when you need people to collaborate and work on fairly complex problems i.e. requirements gathering.

    The challenge you touch on in your article is the one I find very interesting; getting buy-in for using games. The stigma of playing games is definitely a barrier to getting people to adopt games at work. Over the years I have used different incarnations of MetaMemes at different companies and there is always a little hesitancy at first. During the game people relax into it and as they do the ideas come fast, but even after a successful session the participants seem a little embarrassed at having fun at work. I have explained and shown people the concept that thinking and laughing are not mutually exclusive, and to the contrary, laughing is a sure sign of a very creative session.

    In the new version, ThinkCube, I definitely downplay the game aspects to focus more on the innovation process. ThinkCube’s core mechanic is still fundamentally a game based on combinatory play, but some of the more ‘game-like’ elements have been removed. You can still play a game variant of ThinkCube, but through my play tests I found that having less game elements allowed for faster adoption than MetaMemes.

    I still fundamentally believe that companies that are open to playing games at work have a far better culture for innovation. I consider ThinkCube a ‘Trojan Horse’ to sneak fun and innovation into stuffy companies. I am providing the tools to start a grassroots innovation revolution one cube at a time (yes the pun is intentional i.e. help people escape Dilbert cube hell).

    I would be interested to hear other people’s experiences and thoughts on playing games at work.

    Kes Sampanthar
    Kes (at) metamemes (dot) com
    Founder and Director of Innovation at MetaMemes
    http://www.metamemes.com

  • Rory OConnor

    August 16, 2007 at 9:37 pm

    Jess

    I spend most of my time facilitating serious play with my clients. As a practicioner of LEGO SERIOUS PLAY(check out http://www.legoseriousplay.com), I have seen the power of play work in organisations again and again. The LEGO SERIOUS PLAY concept works on the basis of making the abstract (complex ideas or problems) concrete by getting the participants to construct LEGO representations. See the Heath Bros book Made to Stick to learn more about making the abstract concrete.

    The process LEGO SERIOUS PLAY enables you to explore relationships and connections between people and their worlds in enlightning ways. During the process you can get the participants to observe both internal and external dynamics, explore and test various scenarios and guickly gain an awareness of a variety of possibilities that are open to them

    During the play participants will communicate more effectively and engage their imaginations more readily . This tends to allow for taking dialogues to deeper levels as well as short-cutting to the real issues and new knowledge.

    LEGO SERIOUS PLAY is a process for groups and teams. It is a facilitated process based on the latest science about how our mind works. The common language – the bricks – treats everyone as equals and allows for everyones imput to be heard. We have found it extremely powerful and a valuable tool for those that are willing to try it. I agree with Kes though, the more stuffy companies and perhaps the ones that need these types of tools the most are unlikely to take the risk. As we say you need a Coreageaous manager that has a complex problem to solve. Anybody intrested in the science of serious play LEGO have nice PDF booklet outlining how it works. Contact me through my website if your intrested.

    http://www.truepotential.ie

    Rory

  • Brian Regienczuk

    June 5, 2009 at 2:51 am

    Love the article. Would love more links to and examples of bringing play to life at companies. I have found these types of activities to be excellent even if they are 10 minute starter exercises at the beginning of a very serious or technical client workshop.

    Getting people out of their everyday bagage and working together on a common and unusual scenario in the middle of “work” really helps collaboration, communication, and brings out various personalities/traits that sometimes remain hidden during routine business as usual. Thanks!!!

  • Chris Baum

    July 8, 2009 at 1:11 am

    @Brian Regienczuk Donna Spencer did a presentation about design games at the IA Summit this year. Download the mp3 of her talk here: http://boxesandarrows.com/view/ia-summit-09-day-1 (about halfway down the page) Presentation here:
    http://www.slideshare.net/donnam/design-games-presentation

Sorry, comments are closed.