UX - Humans vs Zombies

Humans vs Zombies

User Centered Design Project

This project was a study of the game Humans vs Zombies in order to design a solution to help increase immersion in the game environment and improve the overall experience for the players while they balance the game with their regular activities.

Duration: 5 months (August 2016 - December 2016)
Role: Research, Design, Software Prototyping

Geo Spatial games such as Pokemon Go and Ingress are all the rage these days. However before these became popular, there were games such as Humans vs Zombies played without the use of technology. We call these Mass Spatial Games. They are identified as games played outdoors with large numbers of people and involves people interacting with other people as well as people interacting with the 3D space.

"The fear I generally feel is small compared to the anxiety of being a HvZ human in an apocalyptic world."

Humans vs Zombies (HvZ) is a zombie apocalypse game played on campuses across the world. It is essentially a game of tag but played by very large groups of people in wide open spaces. The premise of the game is to live in a fantasy world where a virus has attacked the human population that is slowly spreading like an epidemic. Over time the game has involved to include technology into the game play to facilitate communication and to keep track of players. It is a free game under the creatve commons license that any person, group or organization can adapt and play on their campus. The Georgia Tech campus has been conducting this game every semester since 2012.

  1. humansvszombies.org
  2. Gatech HvZ


The main goal of this project was to research game play and design & prototype a solution that would increase immersion into the game environment. We followed a double-diamond approach to the research and design of the project in order to acknowledge the wide scope of the problem space. Our only rule through the duration of the project was to let the research guide us to the solution. Our process had continuous feedback loops at every stage where we would receive input from UX experts as well as admins and players of the game.

User Research

Step 1: Identifying User Characteristics

We identified active and passive participants focusing on traits relevant to the game such as physical characteristics: athleticity, age, access to technology and presence on campus. Some other social factors that could differentiate between user groups were also included time, membership in academic organizations/peer groups, experience, etc.

Step 2: Defining Research Questions

The purpose of identifying these research questions was to figure out what type of data we needed to collect and the methods we had to use to collect it. This could be user volunteered information through interviews, surveys or ethnographic data.

Step 3: Identifying Social and Technical Context

Social aspects of the environment and the community relate to the problem space in a game like HvZ where human interaction is a critical aspect to study. Technical context of the game is important to not just understand how the game is being played currently but also to understand what type of solutions can be implemented feasibly. These larger systems are important when designing for the users.

Step 4: Primary Data Collection

We reviewed games from previous semesters by looking at Facebook groups, websites and other social media outlets as well as reviewed the official HvZ pages. We interviewed the administrators of the game and a few former players. We studied the rules of the game and paid attention to specific details that were emphasised in the rules. We studied how the game and the rules have evolved over the years in this Pre-Game Research phase.

Step 5:Task Analysis

This analysis was a combination of 3 aspects:

  1. Characteristics of the tasks performed by the users
  2. Characteristics of the environment in which the task is performed
  3. A heirarchical analysis of the decision making process in the task

We followed this approach to identify and study how the user's current approach to the task and how this might influence our design eventually. Any existing systems that were in place had to be studied in order to understand if and how current solutions to problems work and perform a literature review of these systems.

Step 6:Initial Usability Criteria

We listed out principles that we would use eventually while evaluating our design. This formed a basic in/out list for our designs.

  1. Focus on the users and the tasks not the technology
  2. Match between system and real world
  3. Affordance, Recognition rather than recall
  4. Visibility of system status and feedback
  5. Tolerance
  6. Aesthetiics

Step 7:Secondary Research

We conducted this stage of research closer to the actual game of HvZ played on campus. We wanted to obtain more complete and detailed data that best reflects the user’s problems. We structured our research in order to understand the user’s experience before, during and after the game. Major portion of our research was conducted during the game itself. Two members of our team participated in the game while the other two observed from the outside. Most of our research data comprised of ethnographic data collected through interviews.

Pre-game Survey
Participants: 80

Reach a large number of players and collect quantitative data. Collect data from both types of players: experienced and first time.

Diary Study
Participants: 2

Unstructured information we might otherwise not have specifically asked about. Reach a large number of participants and provides detailed data about experiences.

Participants: 2

Playing the game allowed us to observe the environment and player interaction first hand and get the "inside scoop" by being a part of the strategy conversations.

Participants: 22

Understand gameplay in its natural state. It allows for understanding gameplay but viewing from an outside, unbiased, perspective and allows for movement between factions.

In-game interviews
Participants: 10

Quick in-context interviews allowed us to capture player input as it was happening, giving us a rich account of experiences.

Post-game survey
Participants: 80

Assess players’ feelings post game and compare it with their opinions pre-game. The survey allowed us to understand how the attitudes of the players changed over time.

Data Analysis

We first decoded all the qualitative data from recordings, interviews, diary studies, etc and segmented them into affinity notes. We constructed an affinity map through the bottom up or deductive approach. We noticed some common ideas among different participants and hence we grouped these together into common areas. The affinity diagram allowed us to more easily see trends in issues across the people we interviewed. It was also a good way to get a feel of the players’ general thoughts about the game. We used the quantitative data collected from the surveys to confirm our findings from our affinity map. We had collected data such as player's preference to play as human/zombie, their knowledge about campus, etc. from a large group of people and therefore we were able to supplement our findings from the smaller sample set of interviewees using this more representative data.

Insights and Themes


Players enjoyed the immersive experience and taking on a role sometimes prefering one role: human or zombie


Players followed strategies to increase immersiveness as well as get around logistics of the game.


Stress was a big factor in the game. Some enjoyed it and some didn't but all players acknowledged it.


Players had tactics when dealing with tags and the process of being converted into a zombie.


New players were able to learn more about the campus as well as get to know other players.


There was an interesting group dynamic from the interactions in the game as well as when communicating through social media.


Some players like to practice suicide in order to turn into a Zombie early on in the game.

Problem - Increasing Immersion

  1. A large number of players would choose to turn into a Zombie on the first day in order to play the “more dominant” role. This disrupted the normal play of events that is similar to a zombie apocalypse.
  2. In order to log that a player has been converted into a zombie, players must obtain a Player ID from the newly converted human, sign into the Georgia tech HvZ website and enter this player ID. Many times this process can be time consuming and can remove the player from the experience of the game. This causes a delay in players entering this information which also forced the newly converted human to be removed from the game until his conversion was logged.
  3. If players didnt own smart phones or if their phones ran out of battery, this was delayed even further.
We identified that all of these problems compromised the experience of the game and hence increasing immersion had to be our main focus.


Billy: Human-Mole Person
"I've seen casualties. The texts never prepared us for that. War is hell."

Risk Averse
Likes Playing
Highly Stressed

Liz: Human-Average Player
“I can’t believe i’m still alive. I assume I am going to die.”

Enjoys Playing
Not too experienced
New Player

Kevin: Human-Hunter
“Anyone who tries to cross me will get a marshmallow in the face”

Prefers to play after tagged
Less Stressed

Cameron “Braaains and” Braun: Zombie-Support
“Reporting not running”

Average risk taker
Not Stressed

Amy: Zombie-Killer
“Would you rather be the lion or the gazelle”

Risk Taking
Very Experienced
Average Stress

Noah: Interested-Observer
“I don’t have time for this” “I followed a group of people wearing yellow bandanas”

Risk Averse
Low Stress


We began by splitting off and individually designing 20 divergent ideas and rapidly came up with more to solve that particular problem. We combined similar ideas that could work together in a single system to best solve the main problems identified in the affinity diagram. Through collaborative ideation and narrative development, acting out the story of how the concept is used, we honed in on our final design proposals. This allowed us to define features, address areas that might be problematic with the design as well us address issues with form factors and accessibility. We also focused on enhancing the player's experience in the game and increasing immersion and game feel and therefore refined our ideas keeping this in mind. We worked together as a group throughout the converging process so we could constantly build on each others’ ideas and eliminate them if we felt they did not address the problem well enough. Throughout the process we kept in mind the personas we had created since they best represented the people we observed through research. Particularly we wanted to keep in mind that we wanted to create an equally immersive experience for all the personas and did not want to skew the game towards one type of player.

Therefore, we kept all of these points in mind while narrowing down our ideas. The key method we used while doing so is by first dividing out 20 different ideas into groups based on the implementation. That is, we grouped designs based on form factor and device to human ratio. For example, designs that involved kiosks or screens around campus have a 1 to many ratio and are of a higher form factor as compared to wearable devices such as vests and watches. Once we grouped these designs together, we combined designs and eliminated redundant features. We then evaluated the smaller set of designs based on their usability, feasibility and of course how the increased the immersion of the game and how well they addressed the problems.

Audience Participation

Team Kiosk
Location Control

Communication Wearable
Flare Watch

Stun Tracker
Zombie Kiosk

Design Evaluation

We had a peer evaluation session where we displayed each of our four solutions with story boards to depict how they would be used. Fellow HCI students, game players and faculty voted on the designs and gave feedback on each following which we evaluated the designs based on the following criteria

  1. Feasability vs Usefulness
  2. Form Factor - Inch vs Foot vs Yard
  3. Scale - 1:1 device vs many:1 device
  4. Maintainability

After evaluating our designs and obtaining feedback on them we zeroed in on our solution: A foot sized device, a kiosk, that will be placed in various locations across the campus that players can interact with in order to perform various tasks. We realised that such a device would not just be more feasable compared to a wearable but also easy to maintain for the game admins. It also eliminates the need for using a mobile phone while playing which provides the most immersive experience compared to the other solutions. By making use of existing artifacts such as college IDs we would be able to make the device usable by everyone without having to put in effort for setting up. Our objective of creating a design like this was to keep its usage to the minimum. Players should be able to complete their tasks in the least amount of time and focus on the game.

Output - Prototyping

Our prototype was a stationary kiosk, a physical machine that would count coins that signify either human stuns or zombie kills. After a user swipes his or her buzzcard (or for the sake of the prototype taps a general purpose rfid card) the machine will recognize the user’s identity and will display the player’s in-game statistics. If the player is a human he can choose to log stuns by inserting coins taken from zombies. Similarly if the player is a zombie he can choose to log kills by tapping the coin received from tagging humans. The machine will count the number of stuns or kills that are inputted and display the player’s updated game statistics when finished. The machine will then send this data via wifi to the HVZ website. This will allow users to track stuns and kills while keeping the player immersed in the experience of the game.

Storyboard - Current Interactions
Storyboard - New Interactions


Design Decisions

Interaction Design

We focused on enhancing end-to-end experience right from being human until after they turn into zombies. Therefore, we added features to incentivize players to continue playing throughout as well as introduced risk to allow players to feel more adventurous. In addition we made calculated decisions to ensure players spent least amount of time interacting with the device and playing instead. We chose interactions that are quick and have low error rates: coin acceptor and RFID scanner as compared to entering a code on a touch screen.

Visual Design (Graphical interface)

We made decisions based on mental themes we discovered from the language players used as well as references they made to video games. We decided to create an apocalyptic theme for our visual design to be in-sync with the game feel. We had very little necessary information on each screen and focused information that was optional to smaller areas of the screen.

Visual Design (Hardware Interface)

We added visual effects using light to give feedback on the location of the kiosk and response to user input. We also stuck to the apocalyptic theme for the outer body of the kiosk.

Prototyping Decisions

Hardware Engineering

We decided to use a Raspberry Pi with its 7-inch display in addition to an Arduino Uno to control the Input sensors and the LED lights. These are both fast prototyping kits that are easy to program in and are flexible in their usage. They are also small boards that are easy to fit in different form factors. We prototyped the outer shell of the kiosk using available raw materials: a camera tripod, laser cut cardboard and acrylic sheets and put them together using hot glue.

Software Engineering

We used Python's standard GUI library TKinter and MySQL for the development. We used a "duct-tape and glue" method of prototyping in order to quickly simulate the end to end experience of using the kiosk. We creating a local database instead of hosting it on a server. We hard-coded authentication and authorization to simulate the RFID scanning. And we relied on illustrations for most of the data on the screen only focusing on developing the critical user journeys.


We conducted an initial stage of user testing with our peers at a presentation session where we got expert feedback about the usability of the device from fellow students and teachers in the field of HCI. We evaluated the prototype using the pre and post game survey to compare responses from the previous game as well as measure immersiveness using a survey by Jennetta et al [1]. We measured basic values such as session time, errors, satisfaction, etc. to quantitatively evaluate the effectiveness of our prototype.

[1] Jennett, Charlene, et al. "Measuring and defining the experience of immersion in games." International journal of human-computer studies 66.9 (2008): 641-661.

Stun Tracker - Zombie Kiosk

Zombies are given a set of coins at the beginning of the day. Every time a zombie gets stunned he hands the human a coin. The humans collect these coins and the end of the day they can use this kiosk to feed the coins and collect HvZ bucks for their stuns. If a zombie runs out of coins for the day he is removed from the play. The kiosk can be used to record humans getting tagged. The zombie who tags the human collects an RFID tagged coin from the human and scans it at the kiosk.

Leaderboard - Audience Participation

A large display will indicate to the public how many humans and zombies there are; it will also list top players. Students and teachers will be able to vote for humans or zombies; this will affect the stun timer in favor of the winnin team. A kiosk will also allow onlookers to support specific players by voting to send humans things that will help them such as delivery food, marshmallows or socks.

Team Kiosk - Location Control

Kiosks located throughout campus will allow zombies and humans to "control" certain areas. Players can scan their buzzcards at a kiosk at any time throughout the day and the team with the most unique scans controls the kiosk. At 3 set times throughout the day, players will receive 50 HVZ bucks for each territory their team controls. Lights on the kiosk will display which team owns the territory and by how much.

Communication Wearable - Flare Watch

Players will wear a "Flare Watch" that will act like a homing device. Humans or zombies can hit the flare button when they spot a player on the other team. A notification then goes to other zombies/humans. The watch then indicated the direction in which the flare came from. Players can also see the location on a map in a phone app. The location will fade over time to give a "Flare".