As game developers, we are all familiar with the importance of playtesting our products on potential end-users, but is there a place for them earlier in the process? 

Unlike more traditional game development processes, this project began as a research project with an overarching goal of involving impacted communities in the process of designing solutions. We were tasked with ensuring that community voices could be heard throughout our design efforts, so we began by having some of our earliest brainstorming sessions with the target communities (in this case Marin and Alameda counties in California, two communities directly impacted by wildfire risks). Our internal team did a little bit of pre-brainstorming to generating some starting ideas that could be used to support the conversations with residents, but even that pre-brainstorming was based on the results of interviews with residents that took place before design even began. Here's how it broke down:

Step 1: Interviews

Our partners at UC Berekeley made contacts with residents and local leaders in Marin and Alameda and conducted preliminary interviews to understand their concerns and pain points, and what actions were already being taken to prepare for and mitigate wildfire risks. 

Step 2: Internal Brainstorm

Our team reviewed the results of the interviews and brainstormed several game ideas that could potentially address some of the concerns and pain points. We kept it fairly open-ended at this stage and did not commit to any specific ideas, but we created some storyboards and very rough prototypes to use as boundary objects when working with the communities, helping us all envision a shared goal. 

Step 3: Community Co-Design

We held two design workshops, one in each county, where we took giant printouts of our storyboards and well as blank story boards, we shared the rough interactive prototypes and some insights from our brainstorm, and then we invited the participants (residents and local leaders/decision-makers) to contribute to the storyboards by writing or drawing over the ones we had made or the blank ones. This results in rich discussions and ideas, which we documented and published in our first paper. 

Step 4: Reflection and Ideation

After both workshops we reflected on thoughts and ideas from the communities. We had to abandon some of our initial ideas that did not align with what the community wanted to see in a game. For example, we had one idea where the player is the mayor making decisions for a town, which participants reacted negatively to (believing that it might lead the player to think too highly of their ability to make community decisions and also that it misrepresents how community-level decision-making occurs). Another idea we abandoned was a game where the player could drive around rescuing their neighbors, which participants said would send the wrong message (individual residents are not responsible for saving each other and there's the potential to interfere with the rescue efforts of first-responders). 

Step 5: Iteration with Experts

As our developing continued, we began playtesting our prototypes and demo versions with groups with different expertise. For example, we tested with other serious game designers, who provided insights into how we could improve the playful elements and the user experience. We also playtested with natural hazard experts who shared their thoughts on how the games could present different information or calls to action, and how to align the games with the messaging experts would want people to know. 

Step 6: Testing with the Communities

We returned to the two counties where the initial co-design happened once we had more playable versions, and did final rounds of testing and iterating with each. We uncovered some persistent issues with the user experience that made the games difficult to play, and we also found some issues with how people were interpreting things within the games. These final rounds of testing allowed us to polish and fine-tune the game to meet the needs of the target communities.