Games Researchers Play

Sean Sheehan
10 min readMar 15, 2023

--

Illustration by Zara Vasquez-Evens

Do you want to play a game?

I mean, who doesn’t? Games are more than just a fun way to spend our time; they force us to think critically, evaluate tradeoffs, and make logical decisions about our next best action. For these reasons, games can make for a powerful research tool to better understand how users think about the world around them and the relative value they may assign to a wide array of choices. Moreover, a good research game can provide a much needed commercial break from the more rote call-and-response interview relationship you may have with a research participant.

For our purposes here, I am defining a “research game” as a research activity that borrows heavily from the mechanics of games — game pieces to represent actions/ideas, rules/constraints, tradeoffs between upside benefits and downside risks — to help inform our understanding of user needs, priorities, and mental models. The participant drives the activity, with the researcher ensuring that they do so within the context of the rules. The participant should experience this as if they are playing a simple, objective-based game; however, the desired outcome is open-ended and unique to the participant’s perspectives and opinions. In short, there should be no way they can lose.

Research games can make the questions you are asking feel more practical and relatable to your participant, which can help increase the clarity and relevance of their responses while also helping them relax and possibly share even more. A well executed research game can yield a plethora of high-value data that greatly impacts the path you and the rest of the product team take.

Before you venture out to play a game of Pictionary: UX Edition, there are some things to consider as you construct the game or game-like activity you want to facilitate for your next research project. Each of these considerations will be illustrated through the example of a research game I facilitated when exploring users’ preferences and needs for an eCommerce Customer Dashboard.

What are you trying to learn?

This shouldn’t come as a surprise, but starting with a clear learning objective will play a big role in determining what type of activity you’ll be running. I’ve provided a few objectives and examples of research games I have used to address those objectives in the bullets below. Each example comes with a link to a template in Miro’s Miroverse complete with suggested probes to ask as you go through the game.

  • Are you seeking to illustrate which attributes/features of a product or service are differentiators vs. table stakes expectations? Maybe it’s a game of What’s It Worth to You?, in which participants match a series of attribute/feature cards with a corresponding bucket representing the amount of value it creates for them.
  • Do you have an existing product in which users are struggling to discover the features on their own? Maybe you run a game called What’s In a Name?, in which you present them with a description of the feature and ask participants to come up with a name they think most appropriately represents it. As an added step, you can then reveal the current name of the feature and have them critique it relative to the name they came up with and then select which they would prefer. This dovetails nicely with a card sort and/or a navigation tree test as a follow up.
  • Are you trying to determine which features among a large number of ideas on the product backlog are the greatest value for your users? This could be learned through a Buy a Feature game, in which participants go “shopping” for the features they would like to have. The Buy a Feature concept has been leveraged in Design Thinking approaches for some time now. I personally became familiar with it through training and certification from The Luma Institute.

The most important thing to remember here is that the game should be tailored to fit the research objective. You can borrow ideas from actual games you have played or come up with something all on your own. Feel free to get creative with it.

Defining Objectives: eCommerce Customer Dashboard Case Study

In a recent research effort I facilitated, we were hoping to determine what types of features should be included on an eCommerce website’s customer dashboard. The product team had a large list of features to choose from, many of which were already implemented on the dashboard at the time. I used a Buy a Feature game to help understand what users most wanted to have available on their dashboard.

What are the rules?

As Monica Gellar once implored in an episode of Friends, “Rules are good! Rules help control the fun!” To adapt her just a little: rules help create a repeatable structure to enable you to have more apples-to-apples comparisons across participants. They also enable you to introduce constraints that force participants to think critically about their choices. The rules of the game create space for you to ask follow up questions that help participants share their thought process.

Whatever rules you may choose to apply to your game, there are two key points to keep in mind.

  1. Keep the rules simple and accessible. While I love a good complex strategy game like Twilight Imperium or Warhammer 40k, I don’t have the 4+ hours it can take to run one of those games when I am conducting research. At most, you may have 25–30 minutes to run the game, so err on the side of simplicity and plan to have clear, visual reinforcements of the rules present when you build your stimulus.
  2. There should be no losing condition. Nobody likes to lose and even in a low-stakes situation like a research game, there’s a risk participants could become agitated or even shut down if they feel like they are getting it wrong.

Establishing Rules: eCommerce Customer Dashboard Case Study

The rules for the eCommerce Dashboard Buy a Feature game were pretty straightforward. The different features were grouped into “aisles” of a store, with each aisle representing a common thread that connected those features. Within the aisles, features were listed at three different price points ($50, $75, $100). If they didn’t find a feature they would have liked to see for sale, participants had the ability to purchase up to three “Wildcard” features for $100 each.

The catch was that they only had a budget of $900 and there were about $1,600 worth of features for sale — a good best practice is to give them a budget equal to ~⅔ of the total value of all features on the table. This would force participants to make some decisions about what was truly high priority. At least, what’s what I thought!

Build your stimulus

What form your stimulus takes will be a function of how you will be conducting your research. If you’re in person, make sure you budget some time to have tangible game pieces, such as cards or game boards, prepped and printed. You’ll also need to ensure you have any materials you need for participants to play on hand such as sticky notes, Sharpies, dry erase boards, and markers. If you’re running research sessions remotely, virtual white board programs such as Miro or Mural are more than adequate to get the job done. In either case, this is a great opportunity to involve your partners in design to ensure that your game emphasizes visual communication. It’s not a bad idea to have a dry run of your research game with another member of your team just to make sure directions are clear and your stimulus is doing its job.

If you are running the session remotely, be prepared to help troubleshoot technical difficulties with the platforms and tools you are using. This can be up to and including moving the game pieces yourself with the participant’s direction.

Stimulus Development: eCommerce Customer Dashboard Case Study

The Buy a Feature game was facilitated via remote one-on-one sessions, so the entirety of the game board was built and run through Miro. Since we were working with potential features, we used it as an opportunity to design wireframes of what the feature may look like to give participants an even more tangible experience. To make the in-game logistics flow smoother, I used virtual sticky notes to represent the participant’s money and settled up each feature purchase with a “cash register” that was visible on the screen. This ensured participants were aware of how much money they had remaining in the budget at all times.

A digital white board showing aisles of features that can be purchased. Yellow features are $50, pink features are $75, and purple features are $100. The participant’s budget is located on the right side of the board with green squares representing $100 bills, blue squares representing $50 bills, and red squares representing $25 bills.
The Buy a Feature game board in Miro

Facilitate your game

Your data collection period has arrived and it’s now time to put your research game to the test. Make sure you dedicate sufficient time to give your participant an overview of the rules and the stimulus before you dive in. Once you get rolling, keep an eye on how they make decisions within the context of the rules. Did they quickly make some initial moves? Did they seem to waffle back and forth on committing to another decision? Are they sitting in silent thought before taking action? These are all opportunities to ask probing questions:

  • What, if anything, about those quick initial moves made them so easy for you?
  • I noticed you were going back and forth between a few options there. What, if anything, was causing you to change your mind?
  • I am getting the sense that you’re thinking about what move you might make next. What’s top of mind for you right now?

Remember to make it light and fun, it is a game after all.

Facilitation: eCommerce Customer Dashboard Case Study

I encouraged participants to think out loud as they evaluated which features they wanted to purchase. A guided tour of their thought process helped put their decisions into context; they were very transparent about the larger needs or tasks these decisions ultimately served. In one instance, I had a participant express buyer’s remorse after purchasing a feature. I responded in character: “Well, the Features Marketplace does accept returns.” The participant chuckled, returned the feature for a refund, and then explained why they had changed their mind afterwards. Interestingly, they opted to keep the money rather than put it towards another feature purchase.

Analyze the outcome

The beauty of a research game with a framework of rules and standard “game pieces” is that it makes pattern identification much easier. You can quickly suss out common decisions made and where the outliers may be. Moreover, by actively probing into these decisions during gameplay, you should also have the logic that explains these patterns. For something standardized like a game, I tend track results in a spreadsheet with inputs selected via drop down menus to ensure data consistency. I can then run a myriad of Counts, If statements, etc. that can quickly illustrate patterns.

Analysis: eCommerce Customer Dashboard Case Study

Using a fairly simple spreadsheet, I was able to quickly show how often a given feature was purchased and highlight trends about how participants’ budgets were utilized. An interesting takeaway in my case was that participants only spent ⅔ of their budget on average. The learning being that participants had a “less is more” approach to what they wanted to see on the dashboard and would prefer not to clutter the space with every bell and whistle.

Translate the game to reality

The game creates a construct within which participants can interact with ideas and concepts that may otherwise be abstract to them. It helps them contextualize what you are asking about and make decisions within constraints. When you are sharing your findings, it’s important to translate them back out of the framework of the game and into real world implications for product decisions.

Translating the Game: eCommerce Customer Dashboard Case Study

The most important element of the Buy a Feature game to be translated was the concept of money. In the context of the game, money was a proxy for the priority and desirability of the feature in question. It shouldn’t be translated literally that a participant is willing to pay $50 for Feature A and $100 for Feature B. Instead, it’s a story of where participants would place priority given a finite amount of resources or space to place it. This helped drive home this idea of “less” being “more.” Participants certainly had the ability to throw even more functionality into the dashboard of their dreams but opted instead to prioritize the few things that were the most critical for their needs and objectives.

Share more than your findings

Design Research is all about surfacing the underlying human truths that drive users’ expectations, preferences, and patterns when interacting with products and services. That said, it is equally important to share how you got there. If you come up with an innovative approach, like a research game, share how you did it, your materials, and your analysis tools. You never know if others on your team can repurpose your approach for other work. Research teams become more effective as they share ideas that worked, as well as those that didn’t.

Game on

There is so much that can be learned about users’ decision-making processes, expectations, and needs when observing them in the context of a well-constructed game. It also presents a means to inject some life and energy into your data collection efforts for you, your participants, designers, business partners, and/or clients. No doubt there will be a way to gamify your next study so go ahead, roll the dice.

Special thanks to Zara Vasquez-Evens for the beautiful cover illustration that so wonderfully drives home the spirit of conducting research through games.

--

--

Sean Sheehan

Research Director at Craft. Enthusiastic design researcher and engaging workshop facilitator!