Game user researchers often talk about the importance of measuring design intent. What does this actually mean, though? Simply put, the design intent is the game designer’s vision. It is all the intentional decisions surrounding the fundamental aspects of a game that cause players to learn how to play the game, do actions, and make choices. A wider game development team works together to create rule sets, systems, images, characters, environments, music, sounds, and narratives that ultimately provide an engaging and interactive experience. Keeping in mind that every individual player has biases and past experiences that influence their interpretations, a researcher’s job is to measure how the different parts of the game support a player’s ability to make sense of what the designer intended. Measuring design intent helps development teams see if their design decisions take a player down the path to fun rather than frustration.
In this blog post, we provide a tool researchers can use for measuring this so-called design intent. Called Cue-Behaviors-Understanding, this tool can be used by researchers to do the following:
- Build deep knowledge of how a game works
- Provide a framework for evaluation
- Create a set of items for easy, rapid reflection with the development team
- Quickly populate a notetaking framework
- Jumpstart the organization and writing of a report
- Support the creation of how might we statements
If you are familiar with theories of habit formation and operant conditioning, then Cue-Behavior-Understanding will sound somewhat familiar. Let’s take a look at what these individual parts are and how they work together in the context of games.
Understand Deeply the Game You Are Supporting using the “Cue-Behavior-Understanding” method
Cues
Cues are the things in the game that cause a player to do something, act a certain way, or make a certain choice. Cues help players know what to consciously do. They also help players form habits that they can quickly recall without much thinking. Cues can be images, colors, characters, cut scenes, tutorials, elements of user interfaces, strings of text, sounds, music, scenery, and more. The number of cues you could zoom in on and evaluate is pretty high. A researcher will need to work with the development team to decide what specific cues to focus on for a particular study. Perhaps a cue might be as broad as the game’s environment and color scheme or as specific as an icon in the HUD.
There are many people on a game development team thinking about cues. In a level-based game, game designers think about how levels incrementally get harder by onboarding the player to new skills. The UI designer thinks about how to highlight this new skill with an overlay, pop-up, color change, or other clever experience design. A sound designer thinks about how to add multimodal feedback that distinguishes the new skill from those previously learned.
Because the number of cues in a game can be so high, consider a way to pick an area of focus. To do so, use cues as a talking point with the different members of the development team. Consider asking the dev team questions such as “What were you hoping the player might do when they see/hear/read things in the game?” Probe on why they made certain choices. This discussion will help you uncover what level of focus you will need to take.
Behaviors
Behaviors are what a player has to do to play the game. They are the actions they take and the choices they make. Behaviors happen not only because of the cues you give them but also because of the past experiences players bring to your games. Taking the example of learning a new skill during onboarding, a game designer hopes to see the player apply that skill at future levels. In other words, the cue would be the original level that taught the skill alongside the combined visual and sonic feedback elements. The intended behavior would be a player’s ability to apply that skill as the game unfolds.
Other behaviors that stem from cues might be revisiting the inventory or store after learning its location, leveling up if an item is badged, or pinching to zoom out to see the extent of a map. Behaviors are a great talking point to bring to your development team. You can easily ask them questions such as “what behaviors do you hope to see as the player progresses through the game?” or “how might the visual designs impact player actions?”
Understanding
After working through cues and behaving in a certain way because of them, players build knowledge about functionality and why their behaviors relate to making progress in the game. This knowledge is understanding. While a player may show that they can do a particular action again as they progress in the game, the only way they can build their own individualized strategy is if they have a full understanding of why that action is beneficial to them down the line.
Taking the puzzle-solving example into consideration one more time, a player might learn a skill at the early level and apply it once again at a later level. However, without fully understanding the skill’s relationship to the wider arsenal of skills they have picked up, they may get stuck. In this case, the understanding might be that the player can combine and repurpose skills in a way that is critical to progression.
Understanding, and a player’s ability to build it, is one of the most important aspects of an enjoyable player experience. Games are rewarding because they invoke a sense of competence because of the rapid building of understanding. Understanding can relate to core game mechanics, metagame mechanics, and even aspects beyond the game itself. If understanding is unable to be built, players will struggle.
Other examples of building understanding from behavior might be the moment a player determines how to divide up XP across different inventory stats. Because certain cues caused them to visit their inventory, level up multiple times, and experienced success after doing so, the player builds understanding of the value of their actions. Understanding can even be derivative of a game’s broader narrative or from the puzzle mechanics within. After reading the narrative texts and playing many of the puzzles, a player might discover that the game is actually a metaphor for human relationships. Building an understanding of the very intentional and poetic relationships between all the cues in the game is extremely satisfying.
Taking Notes
If you are tasked with leading evaluative research on a game that is in development there will be a need to get to know the game deeply. The framework of Cue-Behavior-Understanding provides a template for you to capture your impressions of the game you intend to evaluate in an organized fashion. Consider any reactions you might have as you play the game including those that are both positive and negative. Jot down your expectations on what you think will happen next based on what you see, hear or do. Think about the behaviors and actions you are needing to take and make a note of instances when you are both sure and not sure of what to do. Once you are done with your rough notes, reorganize them into the three categories of cues, behaviors, and understanding. Cues are the things you noticed that perhaps caused a reaction or a certain behavior. Behaviors are the actions you did along the way based on the cues. Understanding would be the notes you wrote down about why the actions you took might have been important. Be sure to also capture any areas where you were uncertain and bring those uncertainties back to the team. The table below shows an example set of notes that a researcher might take when playing through a game for the first time:
| Cues | Behaviors | Understanding |
|---|---|---|
| Green flash animation + “great job” sound when block skill is applied | Repeat action after seeing the first green flash and hearing the audio feedback | I should keep blocking |
| Level complete pop-up | Reads information before continuing on | Levels have success tiers and my strategy in the level yields one, two, or three stars |
| Level 1-5 onboarding | Equips gear, levels up character; visits the store | I need to pay attention to upgrades in order to achieve success in each new level |
| HUD | Checks information in the HUD at critical moments; is not surprised when health is low | I can keep track of health and other stats in real-time |
| Timer | Pays attention to the timer | Levels are timed, finishing with extra time gives extra XP |
| Dancing Bear | Notices bear; wants to protect bear | Unclear about this, need to check with the development team why protecting the bear is important |
Reflect with the Team
Now that you have taken your notes, you can bring them back to the team. Discuss the cues, behaviors, and understanding that you captured. Add two columns, one to capture actual design intent from the development team and another to capture what the development team thinks will be the expected outcome if a player were to play the game at its current state. The example below shows one row from the previous table. The green columns are populated with example notes taken collaboratively with the development team.
| Cue | Behavior | Understanding | Actual Design Intent | Expectations |
|---|---|---|---|---|
| Dancing Bear | Notices bear; wants to protect bear | Unclear about this, need to check with the development team why protecting the bear is important | Players use flowers to build a wall around the bear | Because we are missing the onboarding piece teaching this, we aren’t sure how the player will respond. Let’s see what we learn as it might give us ideas on how to design the onboarding |
Populate a Research Plan and Note-taking Sheet
You can easily turn the reflection done with the development team into a research plan. The overarching questions become:
- “How do players interpret the cues in the game?”
- “What behaviors do we see because of the cues?”
- “What level of understanding do players develop by the end of their session?”
For each participant that you observe, capture what actually happens during their play session for each row. The table below shows an example set of notes with additional participant columns in blue:
| Cue | Behavior | Understanding | Participant 1 | Participant 2 |
|---|---|---|---|---|
| Green flash animation + “great job” sound when block skill is applied | Repeat action after seeing the first green flash and hearing the audio feedback | Blocking is important, blocking has to charge up | Kept blocking successfully and continued throughout the session | Knew that she needed to block, but didn’t know block can charge up for more power |
| Level complete pop-up | Reads information before continuing on | Levels have success tiers and my strategy in the level yields one, two, or three stars | Aware of stars, goes back to get 3 stars in levels 1-3 | Aware of stars, goes back to get 3 stars in levels 1-3 |
| Level 1-5 onboarding | Equips gear, levels up character; visits the store | I need to pay attention to upgrades in order to achieve success in each new level | Upgrades gear three times, vocalizes value of upgrade as critical to winning | Does not upgrade gear, unclear on gear leveling when asked |
| HUD | Checks information in the HUD at critical moments; is not surprised when health is low | I can keep track of health and other stats in real-time | Aware of health depletion | Aware of health depletion |
| Timer | Pays attention to the timer | Levels are timed, finishing with extra time gives extra XP | Didn’t know there was a timer | Didn’t know there was a timer |
| Dancing Bear | Notices bear; wants to protect bear | Unclear about this, need to check with the development team why protecting the bear is important | Noticed bear, thought it was part of the background | Did not notice bear |
Organize Your Report
You can easily create a slide for each row of Cue-Behavior-Understanding and provide a summary of what happened across the participants’ experiences. Organize your slides with what caused the most struggle at the front of the deck. While some teams might be happy to hear recommendations from the researcher, you can also have a section on each slide called “How Might We”. This section is a question you can bring to the team to start thinking of ideas. For example, if findings demonstrate that players are unable to develop an understanding of a currency’s intended value and the observed behavior is that they do not use the currency much during their session, you can include the following question “How might we provide more chances for a player to use the red coins and experience a positive impact as a result?”
Streamline Your Workflow and Build Knowledge Over Time
The benefit of this framework is that it allows you to build templates throughout the entire process and repurpose them for future work. Additionally, if you launch even just one project during the evaluative research phase, you can begin to see patterns and establish best practices based on the results. Consider documenting how the team solved for the “How might we…” statements so future games early in development can use these solutions as learnings even before new research is kicked off. While Cue-Behavior-Understanding will not solve for every research project needed for a well-informed game design, the framework it provides allows for a researcher to get to know the game, reflect with the team, and easily bring back the insights captured during playtests.
