Design Games: Scavenger Hunt

This is the first in our series of Design Games.

A design game is basically a fun activity played by a small team and used to provide input to a design problem. They may involve users of a product, a project team, stakeholders, or even management.

The most important aspect of design games is that they are fun! Design Games involve play to promote creativity and idea generation. They are also hands-on. They are not about talking about an idea, but about creating it. As such, our insights and learning happen from the playing of the game, not talking about the issue.

They provide something useful. I’m not talking about silly filling-in-time activities that you are made do at training or planning days. Design games should always provide something that you can use for a project. Design games may provide outputs like:

• useful insights for a problem
• prioritised lists of features
• ideas for terminology
• an understanding of how people think differently

Design games are planned and structured. They are not just about getting people in one place to work on a design. They have a goal and are planned so that goal is met.

Description of Scavenger Hunt

A scavenger hunt involves people looking for a set of objects or information within a defined amount of time. When used for systems like websites, user guides, map interfaces you can learn how easy or hard it is to find things.

A scavenger hunt really is just one form of usability testing. But it should be quick, informal and fun. It is a great, quick game to highlight usability problems to subject matter experts, management and the design team.

Tips

Tips for running a scavenger hunt:

• Provide a set of items or answers for people to find. Allow them to choose which ones to hunt for.
• Put the pressure on with a time limit and offer a prize for the most accurate answers (awarding for accuracy rather than just number completed means people have to actually think about whether they have the right answer).
• Increase energy by having a number of hunters all in the room at once.
• Do this with the design, management or subject matter team as a way to quickly show the usability of a system. If they can’t find answers under time pressure, external users aren’t going to!

Prepare

You’ll need a system to work with. This may be an existing system (to show its current usability) or a prototype of a new system.

You’ll also need a list of things to hunt for. They should be able to be answered with a simple answer, not needing a lot of interpretation—after all, the point of a scavenger hunt is to find objects. For example ask “How much money should you provide in Divide the dollar,” not “What games are good to run with stakeholders”.

Provide a longer list than you may need for the allocated time. This allows people to choose what to look for, and also puts some pressure on them. Pressure mimics a real-life situation where people may need to find an answer quickly.

You may need to ask people not to use the search facility, otherwise they may just grab some keywords from the list of items and search for them—this may not mirror normal behaviour.

Run

Provide participants with some background about what they will be doing, and what system they will be using. Make sure you clearly explain the reward system and what counts as a ‘correct’ answer. Also tell them about time limits and how you will let them know how time is progressing.

Provide the list of items to look for, and the start page of the system they will be using.

Let them go!

At the end of time, go through the answers and score correct answers. Discuss any that were particularly easy or hard, and ask about any they chose not to answer.

Analyse

You should be able to learn quite a lot from this activity. Look for:

• What objects were fastest and slowest to find
• What objects were answered correctly and incorrectly
• Which things did people not attempt, and why

For the items that were slower or incorrect, analyse why. The labelling might have been poor, the content hard to understand, or the participant may not have known enough to complete the task.