Scavenger Hunt Mobile Game
Research & Design
The goal for this project was to design an app from scratch that helps people play real-world scavenger hunts. Since players need an electronic device to play this game, the app should offer benefits that offline scavenger hunts cannot.
I used the steps of design thinking as follows:
- Understand: What are current mobile-based scavenger hunts like?
- Observe: How do people do outdoor recreation?
- Point of View: Understand desires, anticipations, and struggles through the eyes of a realistic potential customer of our app.
- Ideate: Systematically brainstorm and define user tasks to be in the app.
- Prototype: Make app designs, starting in extremely low fidelity (marker and index cards), progressing to high fidelity mobile screens.
- Test: Watch real people use the prototype.
- Tell Story: Convey the process to stakeholders.
Understand
Among the competitors in the scavenger hunting space are Geocaching, Let’s Roam, and Goosechase. Geocaching, the global treasure hunt game, ended up most inspiring this project, so let's look at its strengths and weaknesses.
Geocaching - Strengths and Weaknesses
Above is a flow, left-to-right, immediately after opening Geocaching, the app.
GC ("Geocaching") Strength: It is welcoming.
Geocaching's onboarding positions it as an opportunity for exploration, classic treasure hunting. It's easy for new users to get started, as it takes only three taps to log your first find (See screens pictured above.). After your first find, more treasures abound on the Geocaching map.
What does this mean for us? Prominent and easy-to-find map and camera can make a warm welcome to new users, since these features are familar to phone owners and immediately actionable.
GC Strength: The reward is a surprise ("What's in the box?").
GC Weakness: The reward is a surprise ("I don't know if this hunt will be worthwhile until I find the box.")
What does this mean for us? Offer, as much as possible, the option for users to see a destination on screen before venturing there. Have a toggle or setting for players to choose whether to look ahead or keep it a mystery (It is a game, after all, not a hike).
What does this mean for us? We should include comment sections, date stamps, and a photo helping players decide, should I visit this spot? Luckily, our app requires less maintenance because there's no hidden object to maintain.
Left: each puzzle has a description. Mid: past players leave feedback. Right: puzzle can display logistical info.
GC Weakness: Puzzles aren’t 100% quality-checked by the company; they depend on community feedback.
What does this mean for us? We have little doubt that advanced users will make creative puzzles with quality photos. The challenge will be to have a self-purifying repository--no crappy scavenger hunts. So, our users must be easily able to give feedback and nix poor-quality puzzles.
GC Weakness: The app feels clean and straightforward, but some screens have cryptic options. Other pages are friendly and anticipate user questions.
1st: "Waypoints" screens that don't explain the user task (They're probably in the help section somewhere.). 2nd & 3rd: Screens anticipate the user's questions. 4th: A lot of symbols that are hard for a new user to grasp, sprinkled on the map and on the menu.
A new app would be hard-pressed to compete with Geocaching using the same game model. Started in the year 2000 with the advent of GPS, the activity of Geocaching has an impressive legacy of simple fun for anyone with coordinate-tracking technology. I do not claim that a photo hunt is better than a cache hunt, but some contexts prefer photos. For example, a zoo scavenger hunt tasks users with photographing animals. These ideas led to the current project, where user follow instructions to something--anything inspiring--and, based on the description in the app, they have to find the spot and capture their own photo. Only after solving the puzzle do users get to view an archive of images from past players who visited the same scene. It misses the physical cache aspect of Geocaching but adds a new hunting style for sightseers. The result is shareable and comparable: photographs.
Now, let's develop our own scavenger hunting app.
User Stories
Imagining using a photo scavenger hunting app can help us identify distinct features the app would need. Here are some "user stories" that came from imagining using a photo scavenger hunt app.
As a hunt creator, I want my hunt page to have space for details so I can weave nuance into the hunts I create, and they make sense for others to play.
When I'm reviewing my hunt solution, I need to be able to make multiple attempts at the solution photo, so that I can submit my best one with confidence.
As a user, I want to see my solution in context of the hunt details, so I can review the adventure I just had.
As a hunter, I want concealed extra hints, so I can get help (only) if I need it.
We haven't done user research yet, so these aren't written in stone, so to speak. But these user stories divide the work ahead of us into understandable pieces. Here are some MVP features we can derive from the user stories listed above:
As a hunt creator, I want my hunt page to have space for details so I can weave nuance into the hunts I create for others to play.
A hunt page can have fields for creator's comments, extra clues, terrain comments, background information on the destination, precautions, scenic objects to look for, etc.
When I'm reviewing my hunt solution, I need to be able to make multiple attempts at the solution photo, so that I can submit my best one with confidence.
This is a "job story", the cousin of a user story, and helps discover situational needs that our app can address. In this case, imagining posting a photo solution to a scenic scavenger hunt brought up concerns that, as a player, I would take a picture, want it to be better, then go back to take another picture, multiple times. As an app designer, I think the player's ability to redo a photo should be built-in; players shouldn't have to cancel and restart a flow when they want to take another shot--especially if they're aesthetically minded. This app is photography oriented, not exclusive to photographers, but allows for scenic beauty.
As a user, I want to see my solution in context of the hunt details, so I can review the adventure I just had.
A photo submission will end where it started: the hunt details page, with the instructions, hints, and difficulty rating. But now that the user completed the hunt, the user's photo will fill in on this page. To make an analogy: When you get back a graded exam or finish an obstacle course, you get to look back on the challenges that faced you, so you can understand what your victory means.
As a hunter, I want concealed extra hints, so I can get help (only) if I need it.
Players will have the option to reveal clues when they are stuck. The clues won't show up to spoil the surprise, but they display if requested.
Observe
User Interviews
I interviewed three participants to find out...
1. What contexts facilitate outdoor recreation?
2. How do people play phone games--together/alone? What initiates it?
3. What frustrations and pleasures do users have with other outdoor game apps?
While it wasn't always clear how the conversations would inform the app, I made sure to trace around the three questions listed above and use the interview script as a guide (See the interview questions here.)
Among what surfaced were the following themes.
- Most interviewees use their phone camera—for funny or amazing sights, or logistics.
- Each participant referred a lot to the social aspect of recreation.
- The game apps that participants named were spoken of highly; e.g. chess, Geocaching with friends, Pokémon Go with friends.
I broke up the research into individual notes, and I tried to find affinities between bits of interview data. In the pictures below, first are the notes, where each interviewee is a different color.
Following it is the "affinity map", resulting from re-clustering the notes by topic. There's no single right way to cluster the notes, but I attempted to find relations that would be useful for designing a photo scavenger hunting app.
Analysis
Based on the affintiy map above, some design ideas come to mind...
Finding: All interviewees mentioned taking pictures with their phones at unplanned times.
Insight: Maybe they run into situations in the real world that provoke them to take out their phones for a photo.
Solution: We can structure the app to have the camera screen be the home screen, similar to Snapchat, so that when people run into an unexpected photo opportunity, they immediately think of our app and want to use it to take advantage of the opportunity. They know they can open our app and take a photo without friction.
Finding: Some users invest in games for the long run. A gamer from our user interviews described it: "Every time you progress up to a bigger person is because you mastered the move set,". Other users want "instant gratification... little wins".
Insight: Long-runners want to develop their ability as a player as they conquer increasing challenges and master new strategies to get the most out of the game. Short-runners play for instant gratification, the “little wins”. Short-runners don’t seek to climb ranks, but they still want a challenge.
Solution: Let players choose their battles. For each hunt in the app, users can rate difficulty so that other users know whether to invest in starting that hunt, depending on whether it is hard enough or too hard.
Finding: Some apps get used for a long time straight. One interviewee said, "...it's pretty easy to just spend hours" continuing to use her favorite app once someone gets her started.
Insight: When an activity continues to present new stimuli, users may continue the session indefinitely.
Solution: Offer hunt series for players with extra time. If our app can have series of hunts where one challenge points to the next, and that challenge points to the next, etc., people might extend their playtime.
Finding: People want to be social during recreation. One interviewee in particular talked about playing Pokémon Go, maybe primarily because family plays. "Every now and again... I play Pokemon Go with my siblings and cousins. ... Maybe two minutes a day, [do what I need to do in the game], and quit the app." Another participant said, "if there's no reason to go out," like a special event or fancy party, "we might as well go hang out on my friend's couch". Sometimes, socializing is more important than the destination.
Insight: To communicate with friends/family might be a reason people choose to play a game. Sometimes the “sense of belonging” or tight bond between people is what gives reason for playing a game or what perpetuates gameplay across days, weeks, or months.
Solution: Allow players to create virtual rooms for playing together. Allow players to “friend” each other using unique screen names so that they can create a virtual room exclusive to them while they play. Players can see other players’ solution photos in their room.
Finding: Some players are initiators and others wait to respond to invitation.
Insight: Players want to be able to participate in a way that suits them.
Solution: There could be an in-app way for players to create a game, invite, and see others’ invitations, with the option of notifications.
Finding: One interviewee likes physical mementos and souvenirs from places they visit. "[I] Brough a camera to the zoo. When I was a kid, I enjoyed making those little plastic figurines of the animals." Another likes enjoying the weather and just being out of their family’s house--a side benefit to playing outdoor games. All interviewees spoke about indirect benefits of participating in an activity.
Insight: Games with souvenirs and side benefits build goodwill.
Solution: Include a ‘save photo’ button that saves a picture directly to the user’s phone from inside the scavenger app to make it easy for players to take away a souvenir from their day out. Another way to give users value is to have the app display a new photography tip each day on the home screen.
Point of View
I believe, by giving a platform for saving, sharing, and relating over memories from outdoor destinations, that we will achieve giving Joan a fun alternative way to explore, alone or socially.
I believe, by enabling Monica to see her friends' and family's submissions in the app, that we will achieve Monica finding meaning in paying attention to her environment and competing outdoors.
Joan (below, left) is the primary person the photo hunting app is designed for, even though imaginary, and Monica (below, right) is the secondary. I made these personas so I know exactly who to keep in mind during this project, as they represent our true target audience. These persona are revisable. They came from consolidating themes from the sticky notes we arranged in the "Observe" phase. In other words, I invented well-informed representations of two types of people who may use our product, and I did it by mixing and matching roles that seemed to emerge from the qualitative data.
Primary persona | Secondary persona
Ideate
A Task Flow
Here is a task flow for Joan, our primary persona. Imagining the following task from her point of view helped me form one of the main flows: Submitting a hunt solution.
Joan's objective: “As an adventurer and memento keeper, I want an app-integrated camera and gallery, so that I can quickly take photos and keep my best ones.”
Preparing to Write Joan's Task Flow: Joan will know she’s finished when she’s looking at her photo on the gallery page. She already knows how to operate a smartphone camera app. She needs just to look around for the scene. She followed navigation directions, but she needs to have an inclination of how to hunt for the target once she's close, and be able to unlock more clues if she's stumped. She might want info on what time of year etc. the original photo was taken by the creator in case the environment changes. The only tools she should need are included in her smartphone and the app, with any exceptions being equipment required to get to the spot, like shoes.
Joan's Task
Entry point - Joan nears her GPS pin.
Success criteria - Joan sees her photo upload in the public gallery.
1. View hunt details, user comments, or sample photo
2. Open camera
3. Snap photo and view (opt.: save to phone)
4. Compare to sample photo
5. Opt.: Take more photo attempts
6. Submit her best photo
7. View public gallery of all past players' photos
8. (After leaving the page) Open gallery any time to view
From task flows like the one above and a user-involved research activity called card sorting, we blueprinted a site map to organize all the areas of the app. It has changed since its first form and it will change in future iterations. The goal is a site map that is intuitive, efficient, and pleasant to those navigating it.
Below you can see the process (left) of an in-person card sort, and result (right) of a remote card sort using OptimalWorkshop.com. I conducted a few of each.
Cards contained topics from our app, and we wanted to get insights from the way participants categorized cards into how the site map should be organized. Below, you can see how we took the yellow branch from a prior attempt at a site map and revised it (shown in the box on the right). We can rearrange the site map more in the future based on feedback, research, and testing.
Prototype
Let's start drawing the app screens themselves. We want low-fidelity (rough) drawings for the first draft. Only big-picture details are useful at this point. To make sure we stay rough for now, let’s draw on small paper using fat marker.
An idea for submitting a solution to a scavenger hunt, a flow
Low fidelity is good for experimenting because sticky notes are easy to scrap and restart. Polished prototypes take more time to draft, change, and redraft. So, let's gradually raise the fidelity. Next, details will be more concrete and sizing will be more accurate, but most details are still absent. Here is the same flow from the sitcky notes, now using the program Balsamiq:
Finally, we use a heavy duty design tool like Adobe XD to raise the fidelity more. Compared to the final product, this is still mid-range fidelity. As we approach high fidelity, making screens requires more time investment, so doing low-fidelity and mid-fidelity designs first saves work down the road.
Test
Usability Testing
At this point, we put the prototype in front of some volunteers (potential users) to test it.
In-person testing with a moderator (me) was chosen over unmoderated or remote testing, because at such an early stage in the project I wanted to know why each person navigated the prototype in certain ways. Qualitative data would help brainstorm future changes for the project. Something to be careful about here is a tendency to take the feedback of my 6 testers (a small sample size) with heavy weight—at the cost of forgetting this project’s personas. A positive with this is that I have the option to update the personas, Joan and Monica, based on qualitative data from usability testing. In-person moderated testing fits my project because, single-handedly, I don’t have the time to analyze dozens of testing sessions. A few quality sessions must suffice.
Here is the testing plan.
Background
Chasing Views is a scavenger hunt app for outdoor use, leading a user to locations such as mountains, lakes, artificial marvels and landmarks, city skylines, and impressive building fronts, where the user captures the solution to the hunt: a photo of the scenery. It is designed to facilitate exploration in the real world--for social game lovers, sight seers and collectors.
Goal
We want to see if new users grasp the concept of a photo scavenger hunt, and how easily they do the tasks, which involved using main features of Chasing Views. We'll evaluate the learnability, ease of use, and functional integrity of our first prototype.
Methodology
A test involves briefing, informed consent, observing the tasks, and debriefing.
Script
A Tester's Tasks:
1. Use search feature
2. Submit a hunt solution.
Full test script available: https://www.dropbox.com/s/aec5a3ljkoruq79/4.4%20Usability%20Test%20Script.docx?dl=0
Six people individually tested the prototype. The testing schedule is here: https://www.dropbox.com/s/f8p5fw49w0zrulc/4.6%20Rainbow%20Spread%20Sheet_%20Usability%20Testing%20CF.xlsx?dl=0
Test Report
Observations of usability testing participants were classified into these four categories:
- Errors ("mistakes" while using app)
- Positive quotes
- Negative quotes
- Other observations
Then, we rated observations by how critical they were and how often they happened. Note: P1, P2, P3, P4, P5, and P6 are participants.
After picking the five most urgent issues, we identified possible solutions. Here are two examples...
Understand, Observe, Point of View, Ideate, Prototype, Redux
We cycle through the previous steps of design thinking as needed, continually improving the design.
Gestalts
Gestalt-related fixes were made to some screens, including the one below. Left and right look like different screens, but they're really the same screen, before and after fixes.
Native Application
Next, we adjusted our app design--which could also be made into a web app--to be fit for a native app in iOS. Research on Apple's iOS human interface standards webpage led to the changes illustrated here. The first image below is a flow from before, and the second is after.
Style Guide
Making a style guide forced me to narrow down the styles and patterns going into the app. For example, I changed all the buttons to be the same height and width and have the same amount of roundedness in their corners. I still have a lot of colors, and having to display them all on one page as you see below reminds me that I want to condense and simplify even more.
Below are just two pages from the style guide.
Working with Peer Feedback
Here's an example of how I took peer feedback to adjust the design of a flow prompting sign-in during a game:
Learning about Accessibility
After learning about common Accessibility themes, I made some adjustments. Increasing size of text and buttons is already a good idea because Photo Hunt is meant to be used outside; people will be walking with an arm outstretched and more easily navigate the app when elements are big. You will see additional accessibility edits, too.
Conclusion
Reflection on Iteration
We started by studying the current scavenger hunting environment, our target audience, interviews, user flows, user journey maps, and personas to understand how our audience feels about games and outdoor recreation; and card sorting to get inside people's mental maps. With this information, we quickly sketched up designs on index cards using marker. Scrapping mistakes was easy because it takes just a minute to draw a new index card. As soon as we had the rough designs on paper, we gradually increased their fidelity from low to high. By the time our app screens were high-fidelity, many issues had already been solved--before they became problems--thanks to iteration in lower fidelities. As we got more test results and peer feedback, we kept adjusting design. We aligned screens to layout grids and studied Gestalts, accessibility requirements, and iOS guidelines. We also compiled the essential assets of our prototype into a style guide, where templates for colors, fonts, and buttons are centrally stored. To decide on a template forced me to consolidate my assets, like narrowing down my color palette. I threw out components that were out of uniform; the whole prototype had to be consistent.
We can continue to iterate forever. Pictured further down are some screens from the prototype so far, but they will always be a work in progress to enable people who use the product to accomplish tasks.
In this project, I got a peek at the value of rapid iteration. Most tasks were performed only once. They were arduous. During each task, I felt the need to come out with a complete and sensible product. Realistically, there's no way I can or should know in the early stages how the final product should work. In other words, this project for me felt like a waterfall-style project because it consisted of one long iteration. One iteration for me was a lot of work! If I were to start this project again from scratch, I would iterate quicker to try more ideas. I would let rapid research and testing determine the design, rather than making heavy, stressful, uninformed design decisions myself.
In aspiring to make rapid effective iterations is another lesson: Refrain from styling early prototypes. One example of how I painfully learned is when I picked a font to suite the tone of the app. I made all the fonts uniform in this style, and later, I decided against this font because I had been advised to use a standard modern-looking font for mobile apps. I had to change each screen's font again and nudge text on the order of pixels to re-space them properly. It sank my time. Early in the design process, I should never have made such specific styling choices. If it can wait until later, it should.
Pictured here are several screens from the prototype at the time of this document. I feel good about them but also uncertain, which is how I think a design researcher should.
