Project at a Glance:
For the General Assembly User Experience Design Immersive, this student project was framed as a two week sprint to design a mobile app that addressed earthquake preparedness in Seattle. The team was composed of four people, including myself. Tools used included Sketch, InVision, Google Surveys, Google Drive, Slack, whiteboard, pen and paper. Skills used included user research, interviewing, hand-sketching, persona creation, user scenarios, wire-framing, user flows, comparative analysis, hi-def page design, and user testing.
The Pulitzer Prize-winning New Yorker article, "The Really Big One," pushed the potential for a catastrophic earthquake and ensuing tsunami to the forefront of public consciousness. It difficult to overstate the severity of the catastrophe that would result from a high-magnitude Cascadia Subduction Zone earthquake. FEMA estimates that over a million buildings would be destroyed. Everything west of I-5 would be decimated. And yet, despite the panic-inducing headlines, the residents of Seattle remain woefully unprepared.
Our project was to design a mobile application for the City of Seattle that would help prepare its citizens for a massive, regional disaster. In two weeks, my team researched and designed a retro-themed social video game platform that utilized a sense of nostalgia, wry gallows humor, player competitiveness, and existing social connections to drive engagement and education.
On this page, I'll walk you through my process, step by step, explaining my thinking, techniques, challenges, and iterations. I'll provide images, documentation, and work ephemera to illustrate how I got from the first stages to the finished product.
As this is a long document, you can click on titles within the table of contents to jump to sections.
We began our discovery process by researching the space, downloading existing preparedness apps from FEMA, Red Cross, and others. While they provided some good information, we found the existing applications far from engaging and as most of this information was available online, the impetus for downloading the app was unclear.
Our team discovered a program called SNAP (Seattle Neighborhoods Actively Prepare), as well as comprehensive joint exercises between federal, state, city agencies called Cascadia Rising. But we also found that these plans had not been effectively communicated to average citizens. We used much of our initial discovery work to inform our screener interview questionnaire.
2. User Surveys
Using Google Surveys, we canvassed 123 individuals to help inform us of our user base and to zero in on elements we wanted to explore in-depth. Of 123 responses, we found that 98.4% were aware of a possible earthquake and 91.9% considered disaster preparedness to be of importance. Yet only 22% had a preparedness app and only about half had some sort of survival kit. Only 8.9% of respondents knew where their nearest emergency shelter was located. This is in keeping with FEMA surveys that have shown that less than half of US residents have emergency supplies and less than a third update those supplies on a regular basis. Nearly two thirds of respondents chose an incorrect action for protecting themselves during an earthquake.
Some of our screener questions ultimately did not inform our product or our user interview approach. For example, we originally thought that we would use the app to during an actual event and so we considered it important to ask whether respondents used Google maps, although this information didn’t play a part in our final prototype. However, we used these 123 responses to shape our user interview questionnaire and scheduled in-depth interviews with eight individuals.
3. User Interviews
We spent a good deal of time developing our user interview questions and over the course of the sprint, this thoughtfulness paid off. Most of the open-ended questions came at the same concept but from different angles. The main thing we were trying to understand is what kept residents from proactively preparing for a disaster.
We asked how likely respondents thought it was that the “big one” would happen in their lifetime and then, as importantly, what they were basing that number on. We asked about whether they had experienced a disaster situation before and about the preparedness of their workplace or school. We asked whether they knew how to check if their home was structurally prepared for an earthquake. We asked them what they thought should go into an emergency kit. For those who hadn’t prepared a kit, we asked what was preventing them from doing so. The interviews tended to be about 15 minutes long and often led us in unexpected and fascinating directions. The conversation were conducted in-person and via Google Hangouts.
We essentially interviewed two types of people - those who had engaged in disaster preparation and those who had not. In comparison to the results of our screener surveys, we determined that we most likely oversampled prepared respondents, which makes sense, as proactive and engaged people are more likely to agree to participate in an interview.
Among all respondents, one of the most interesting and paradoxical drivers was fear. In some of our interviews, respondents were compelled to take action because they were afraid that the earthquake was inevitable. In other cases, respondents were too afraid, incapacitated by the belief that a Cascadia earthquake would be so catastrophic that no one would survive, rendering preparation useless. Still other responses indicated a lack of fear, manifested as skepticism that a quake would ever take place. Sometimes a respondent would oscillate between a number of these outlooks with in a single interview. For example, a person could say that they were skeptical that an earthquake could take place but, when pressed, would just admit that they didn’t want to think about the possibility because it was to catastrophic to contemplate.
Regardless, whatever design solution we created, we knew it was necessary to channel fear into purposeful action rather than paralyzed fatalism.
By pixelating the responses from our interviews and using affinity diagrams to find patterns among our sample base, we began to form our user personas. We knew almost immediately that we needed to create two personas because our respondents were so polar. On the one hand, we had Pat, an extremely prepared and proactive neighborhood and family leader that had developed a comprehensive preparedness plan and a robust emergency preparedness kit. Pat is motivated by a feeling of certainty that a disaster is imminent, by the belief that he will be safer if those around him are prepared, and by a desire to feel heroic. Pat wants to save the day.
On the other hand, the responses we gathered led us to create the user persona of Jesse, who is not prepared for a major earthquake. Jesse thinks he’s skeptical that an earthquake will happen (despite what seismologists may say), although it’s more that he’s uncomfortable thinking about it happening. In fact, when Jesse does think about it happening, he imagines that the disaster would be so huge that he probably wouldn’t survive, and he probably wouldn’t even want to. So what’s the point of thinking about it? There are more important, immediate things to think about. Jesse is more motivated by wanting to have fun, to enjoy life, and to value his friends and family.
Interestingly, we decided that our two user personas, Pat and Jesse, most likely knew each other.
6. Design Goals
Once we had an understanding of our user personas and had mapped out several user journeys, we were in a position to pinpoint some of our design goals. The first goal was to connect Pat to Jesse. We knew that, for both selfish and altruistic reasons, Pat wanted an easy way to help others. And even though Jesse wasn’t compelled to prepare on his own behalf, existing social connections could be leveraged to motivate him. This meant that the app needed to be social.
Secondly, scoping was huge issue for this project. Essentially, our user-base was every living person in the city of Seattle. We thought up a multitude of different functions including designs that addressed the needs of users during an earthquake, as well as in the aftermath of a disaster. Ultimately though, due to the two-week limit of our sprint, we decided to focus only on preparation for a disaster, and mainly on helping a user prepare an emergency supplies kit and to help a user gain an understanding of what their friends and family would be doing to prepare for an emergency.
Lastly, we needed a way to channel fear of a catastrophic earthquake into productive impetus. If a user is too afraid of disaster, it results in fatalistic paralysis, and if a user isn’t afraid enough, it manifests as skepticism and inaction. The application needs strike just the right balance. And it’s for this reason that we decided to solve the problem by framing it as a game.
Confronting what would most likely be the largest natural disaster in the history of North America by using a game solves for all of our design goals. Firstly, games are inherently social. Inviting friends and family to a game like Farmville and Words with Friends is now second nature to many users. Also, goals such as putting together a survival kit are easily expressed as a game inventory and can be rewarded. The natural competitiveness inherent in social gaming provides an internal impetus other than fear (or guilt) to become better prepared.
Another advantage of using a game is that it gives us a unique opportunity to abstract fear into something useful. In real-life, fear creates unpleasantness, fatalism and inaction. In a game, as in any fiction, fear creates drama and drama is fun. By setting a game in a person’s hometown and designing the main event as a very real-life danger of unprecedented proportions, we can create drama, a ticklish flavor of unease mixed with fun, which would not only make for an effective educational tool but also a really unique game.
Lastly, a game lets us set a specific countdown for an Earthquake. That’s one of the biggest reasons people don’t prepare. It could happen in a year or twenty years or five hundred years. Not even experts can say for sure. So how seriously should citizens take the possibility of one? With a hurricane, meteorologists can say three days ahead that a storm is going to hit and citizens want to prepare so much that the grocery stores get cleaned out. With a game, we can manufacture an artificial countdown for a disaster that, in the words of one of our interviewees, “isn’t polite enough to call ahead.”
8. Design Process
Once we had collectively agreed to the format of a game, we started white-boarding the user flows of our two personas. This was mostly talked out narratively (“So, Pat’s at the home screen, does he invite people to play first or enter his character information first?”) and drawn as we went. This process was a grind but by the end of our scrum, the game had taken shape and we had a tentative list of pages.
Next, we played a series hand-sketching games, in which we selected a chunk of the flow, drew for 5 minutes, presented our sketches for three minutes, and then critiqued for three minutes. We repeated this process many times, stealing and iterating upon each other’s ideas, until certain concepts rose to the surface and differing visions began to converge.
One of our initial challenges was making the game fun and addictive regardless of how it was helping users prepare. At first, the app just seemed like a collective shopping list. Our team spent some time looking at what makes games addictive and found that they commonly had short, manageable levels, were refreshed daily to drive users back, granted arbitrary awards and badges, employed progress bars, great graphics and catchy sound effects, and used scoreboards so that players could compare themselves. Almost all of these elements were used in our final design.
After we had developed a very basic understanding of what each page should look like, I started putting together low-fi wireframes using Sketch, while my team worked on creating an asset inventory for our final presentation. Once the raw wireframes were completed, we uploaded them to InVision and began user testing them. We conducted six full user tests, which led to a series of iterations.
9. Features (and Reasoning)
A player can customize their character, making them feel more connected to it.
When a player like Pat creates a team by inviting team members to join, he can send a custom message. This can be something funny or something heartfelt but helps leverage existing social connections to engage users.
Once the player selects the game duration, the game clock begins counting down to the earthquake. This creates a tangible urgency not found with actual
Here, players can see the points and levels of other players, with the goal of stoking the fires of competition.
This is where a player sees their status, including how many badges they’ve earned and how many points they need to earn to level up. The point of the game is to earn the rank of Seismic Hero.
A user can employ the camera on their mobile device to scan QR codes of products that they need in their survival kit. A player doesn’t need to actually buy the product but does need to prove that they are physically with it in order to gain points.
These are peripheral games that users can play to gain points. Each of these can only be played a limited number of times per day, which encourages users to come back to the app over and over. Much of the educational information comes through these mini-games.
When the countdown reaches zero, the earthquake happens, employing phone vibrations, animated graphics, sounds and text to create a satisfying climax that is half urgent and half funny.
Here, the user can see the final scores within their own team. This is where bragging rights are earned and rematches can be demanded.
It’s important that a user’s team can see how their team as a whole measures up against the best in the city. After all, more important than beating your friends and family is knowing that your friends and family are as safe as possible. If this convinces your group to play again, the app is doing its job.
Rather than forcing a player through a million forms, the app collects information throughout gameplay and compiles it in an emergency plan, that includes the survival kit checklist, nearest shelters, family rally points, safety tips for during and earthquake and other important information. A player can choose to export this plan to PDF or email.
After user testing Seismic Hero went through many iterations. During our two week sprint, our team conducted numerous user tests, which informed our approach to the final product. For example, our original design included an empty emergency kit that bummed people out. Since everyone starts with an empty kit, we didn’t want people to feel discouraged. So we swapped out the icon and added a friendlier prompt.
Originally, our icon for Quests was a little super hero. But several users told us they thought it was a Christmas tree! So we swapped that out for a book icon. But the book’s pages were white, which made it looked highlighted, even in other parts of the nav. So we designed an 8-bit book from scratch in all black.
Another change was that the “Export” prompt used to be a modal directly after the earthquake page. One user was let down by that and wanted a bigger pay-off after the climax. So we moved the export process to after the scoreboards and gave it it’s own page.
These are only a few of the changes we made and feel that real user feedback helped us make this app more useful and more fun.
11. Agile Method and Team Dynamics
Before the UXDI at General Assembly, I didn't know much about the Agile method. The more I learned about it, the more that I realized I already had an intuitive understanding of how it worked. The large-scale, interdisciplinary art projects funded and generated by the non-profit company that I started in New York, Satellite Collective, were constructed in a very similar way, though we didn't know to call it Agile. We always had a scrum leader (though, again, we didn't know that word), who was not the boss and didn't outvote anyone, but facilitated the workshopping process, organized the activities, and was responsible for driving the calendar and team check-ins.
The way that we ran the process had a bit of a twist which was that, at a certain established point, the pure collaborative framework switched to a hierarchical structure, in which someone was definitely in charge and was empowered to make snap decisions that had to be respected by the team. The reason for this is that collaboration, while it does often generate the highest quality and quantity of ideas, is relatively slow and deliberative. At a certain point in a project, decisions need to be made very quickly. It's similar to how congress is a slow, deliberative, collaborative body, while the executive can make very quick decisions when needed. If this process switch is outlined ahead of time, nobody is surprised or feels marginalized. Our team used this method for our project and avoided a number of heated shouting matches suffered by some of the other teams.
12. Future Iterations and Conclusion
As an application, Seismic Hero has vast potential for expanded functionality. For example, partnerships with retailers could give players a discounted rate on items that were needed for a survival kit. Even more seamlessly, a player could be offered the option to instantly order everything remaining on their survival kit list and have it delivered to their door via Amazon.
We can also the populations of different cities playing against one another. This earthquake is expected to effect the entire west coast. Portland versus Seattle anyone? We can imagine a more robust set of Seismic Activities and perhaps an alert system that uses push notifications in the event of a disaster to remind users of how to “win the game” as an earthquake unfolds in real life.
We designed Seismic Hero to educate the residents of Seattle; to simplify and consolidate the process of preparing for a disaster. The app offers citizens like Pat and Jessie an approachable way to begin proactively planning for what is expected to be an unprecedented catastrophe. By employing competition, snarky humor, delightful gameplay, and existing social bonds, Seismic Hero simulates the urgency necessary to get Seattle geared up for the Big One. We argue that funds spent building this quirky, funny, and informative app will ultimately save lives.