Schnitzeljagd!
a scavenger hunt app case study
Schnitzeljagd (German for scavenger hunt!) is a mobile app that allows users to explore both new and familiar cities and neighborhoods through themed scavenger hunts. Schnitzeljagd is designed for users of varying ages, backgrounds, travel experiences and interests to enjoy and benefit from this app.
PROJECT OVERVIEW
My Role: UX Research, UX/UI Design
Tools: Marvel, Balsamiq, Sketch, Optimal Workshop, Usability Hub, InVision
Methods: User Interviews, Preference Testing, Card Sorting, Affinity Mapping, Wireframing, Prototyping
Duration: September 2019 - March 2020
Problem Statement:
Our users need a way to to participate and create scavenger hunts for their own enjoyment and that of the larger community, because they want to explore their surroundings by engaging in a fun, outside-the-box, challenging activity/adventure.
We will know this to be true when we see how many users are download the app and engaging with it on a daily basis.
STEP 1: COMPETITIVE ANALYSIS
I began by conducting a competitor analysis to better understand what other scavenger hunt apps already exist, what they offer and what gap there might be in the market.
Competitor #1: Geocaching
Geocaching is an app and website that essentially allows users to go on treasure hunts. “Caches” are hidden above ground in a specified location and when a player finds it, they open the box, take something, leave something, and sign the log book.
Image description: Screenshots of the home screen, sidebar and search function from the Geocaching app.
SWOT PROFILE
Competitor #1: GooseChase
GooseChase is an app/website that allows users to design their own scavenger hint using clues, images, and GPS coordinates. Games are by invitation only and not open to the general public.
Image description: Screenshots of the log in/sign up and “join a game” screens of the GooseChase app.
SWOT PROFILE
STEP 2: BUSINESS REQUIREMENTS
Target Audience
This app is geared to meet the the skill level and needs of the individual user playing. Scavenger hunts can be designed for children upwards of age 7 (birthday parties, corporate events)
Risks/Opportunities
We have an opportunity to build on Geocaching’s “find hidden object” concept by allowing a user to design a more fully realized, multi-step multi-location scavenger hunt. GooseChase has a few missed opportunities that we can capitalize on -their app is hardly usable unless you have a game to sign into and hints can only be designed on their website.
Competition
Geocaching is extremely established, stable and have spent years finessing their product. GooseChase is our direct competition as far as demographic and users are concerned; it is another scavenger hunt after all.
Conclusions
Despite the competition, there is still certainly room for us to thrive! By taking advantage of the shortcomings of our competition and creating an app with unique features, we will set ourselves apart.
STEP 3: USER STORIES
As a <ROLE> I want a <FEATURE OR ACTION> so that <DESIRED OUTCOME>
Map with scavenger hunt start points
As a frequent hunter, I want an integrative and interactive map with dropped pins indicating different hunt start points so that I can see all my hunt options in an intuitive way.
As a frequent hunter, I want to be able to tap the pins for a preview of the hunt, so that I can tell at a glance if it interests me.
As a frequent hunter, I want there to be a search by keyword option so I can browse hunts by their descriptors, not just their geographical locations.
Scavenger hunt to do list and progress chart
As a hunt player, I want to be able to see a list of all the tasks/clues that I’ve accomplished and what still remains so that I can track my progress.
As a hunt player, I want a visual cue, such as a colored in progress bar for a quick indicator of how much I have left to find.
As a hunt player, I want a small thumbnail of the map inlaid within the to do list screen (and vice versa) so that I can easily switch between screen views.
As a hunt player, I want the option to request a clue if I find I’ve been struggling for some time so that I can get back on track.
Build a hunt flow + invite players
As a hunt builder, I need a simple but well designed interface to design a hunt that takes all its components (hunt title, difficulty level, description each hidden item/task, geographical location, map links, keywords for SEO, clues, photos) into account so that every detail of the hunt is addressed.
As a hunt builder, I want the option to indicate whether my hunt is for the general public, or if it should remain unlisted for invitation only.
As a hunt builder, I want to be able to create a unique link or passcode to send to friends to participate in a private hunt.
Chat feature for teammates to communicate
As a hunt builder, I want to be able to communicate with the people playing my game so that I can assist them if necessary.
As a hunt player, I want to be able to communicate with my teammates/rivals so that we can keep each other in the loop when we are in different locations.
STEP 4: USER INTERVIEWS
Based on my findings from my competitor research, I was able to further hone in on what features I wanted my app to include and begin to formulate effective questions to conduct user interviews about their needs, expectations and previous experiences. I started the this process with an online anonymous survey (39 participants), followed by one on one interviews (3 participants).
My research goals were as follows:
1. To understand people’s mobile gaming habits/attitudes about mobile games.
2. To determine what do people look for in outdoor adventure activities. (What are they currently doing for recreation? What do they love about it? What does it lack?)
3. To identify what users want in a scavenger hunt app. (What would compel them to use it? What doesn’t appeal to them about it?)
4. General demographic info about survey participants.
Image description: Post its containing findings from user interviews, organized by participant and content.
STEP 5: AFFINITY MAPS
All three of my interviewees had really interesting things to say about what compelled them to try scavenger hunt style apps in the first place and why they stopped.
After these interviews, I was more inclined to see where I can go with search for landmarks as opposed to physical objects (like Geocaching) because it seems there’s a lot of room to explore how to make it a more unique and personal discovery.
I organized the findings from my interviews into affinity maps (image below) in order to find trends, themes and other overlapping insights from my interviewees to get a better sense of what features/experiences I should prioritize for my app.
Image description: Post its containing findings from user interviews organized into affinity maps.
STEP 6: USER PERSONAS
Using the information I gleaned from my research thus far, I was able to put a name and a face to my target user by creating user personas. In these personas, I included goals, needs, problems and behaviors in order to better empathize with my potential users and to develop a product that is truly centered around them.
STEP 7: USER JOURNEYS
Using the information from my user personas, I created engaging user journeys for them so I could better visualize the process the user goes through in order to accomplish a goal.
STEP 8: USER FLOWS
Creating user flows allowed me to see, step by step, exactly how a user must interact with my app in order to complete a given task.
STEP 9: SITE MAP
Creating a site map allowed me to put my user flows into proper context. The grey values of the site map help to communicate the page hierarchy. The lighter the gray, the deeper into the app the user goes. I conducted a digital closed card sort (20 cards, 6 participants) using OptimalSort to determine if the way I organized my site map was intuitive. Using the feedback from my participants, I made improvements and revisions.
STEP 10: WIREFRAMES
Armed with my research, it was time to take pencil to paper and begin sketching out different ways to approach the design of my app while keeping my user's problems and potential solutions the central focus.
My low-fidelity wireframes were are bare bones - I just wanted to get the main features to paper without overthinking and getting lost in the details!
Making mid-fidelity wireframes was an important step in generating more detail, getting a better sense of how a more finished product will look and feel, as well as learning how to use Balsamiq.
While the image gallery below is just the first of many iterations of high-fidelity wireframes, it was thrilling to see my app start to look like a real app! The process of learning how to use Sketch required some patience on my end, but it was absolutely worth it.
STEP 11: USABILITY TESTING
I animated my wireframes into a navigable prototype using InVision, that way I could conduct usability tests to see if my designs were on the right track. I developed a test plan and test script and recruited six volunteers to participate in testing. Moving forward in this design process depended on having real users interact with my prototype. By observing them perform tasks using the app provided essential insights and feedback, allowing me to iterate and reiterate.
I generated an affinity map using the most important takeaways from my user testing, organizing them by observations, errors, positive quotes and negative quotes. I also created a Rainbow Spreadsheet to visualize all my data in a glance. Using the information gleaned from these two methods of organizing data, I was able to compile a usability test report and identified the top 5 issues with my app based on user feedback.
Image description: Post it notes containing insights and feedback from usability testing organized by topic.
Image description: Rainbow Spreadsheet, a visual depiction of user testing
Iterate, iterate, iterate!
Along with revisions I determined were necessary based on user feedback, I made further changes to my design based on visual design principles, emotional design, grids/spacing and responsive frameworks. I also shared my prototype with other designers to get their feedback as well and to learn how other UX designers might approach the same problem with a different solution.
Below are some examples of my latest mockups.
Design Language
In an effort to ensure consistency throughout my app and to keep a record of all my design decisions, I compiled a design language reference guide which will be consulted for future iterations, by myself or by other designers who may work on the app.
Updated Prototype:
The latest version of my prototype can be viewed here.
Conclusions
My work as UX designer is never complete and apps are constantly evolving. With that in mind, I have a new problem statement in the works:
Now that we have a scavenger hunt app that allows users to explore their surroundings, we need to make sure the app is offering them the best possible experience as they participate in the hunt. We will know this to be true when users test alternate versions and determine which version they prefer.
I’m not convinced that the format of the hunt itself is the best possible way to go about designing a scavenger hunt. It feels like you can just play it from your couch, in theory - there’s no integration of GPS or location services to add to the challenge of the game. But at the same time, I want users who are traveling abroad without phone service to be able to play. So I want to be able to somehow address both those issues!
User testing and feedback played a tremendous role in the design decisions and iterations I made to this app and I expect that to continue to be the case going forward. Now that the aesthetics are more or less as they need to be, bringing a major structural change about will likely bring me back to the earlier type of feedback I received - users will tell me what they want and don’t want, what’s working and what isn’t, what compels them to use the app, what puts them off.
As far as timeline is concerned, I suspect the pace can be quicker than it took to get this point, as the major work is complete for the app - I’m just focusing on a particular element. I would hope I could make a significant iteration every two weeks, allowing for the week in between to be dedicated to user testing and feedback.