TurfQuest

Context

The goal of this project was to design a social scavenger hunt app.

This was my main project while getting my design certification from CareerFoundry between March 2020-May 2021. They provided us with a few prompts to choose from, and I chose this prompt in particular expecting that my game design experience would come into play.

Since it was entirely a design exercise, the app was designed but it never entered development.

Research

I started my research with a competitive analysis.

I chose to focus on two small-scale competitors. While not quite a scavenger hunt app, Pokémon Go was the first competitor I thought of. However, having played the game in the past, I already had a solid understanding of their business model.

I wanted to focus on smaller businesses that were definitively competing in the scavenger hunt market. To properly prepare, I needed to determine what these smaller businesses were doing to survive.

Competitor A: Actionbound

Actionbound is a small scavenger hunt app that focuses on bonding events for businesses, schools, and other groups.

All scavenger hunts in the app have been created by other users.

Competitor B: Let's Roam

Let's Roam has a larger presence than Actionbound and focuses on groups of friends.

It employs professionals who create all their hunts, ensuring their quality, but also increasing their cost.

User Interviews

Based on my research, I defined two main audiences:

• Primary Audience: 21-35 years old
• Secondary Audience: Families (35–50-year-olds mixed with 8-21)

Then, I interviewed 3 people in the age range of my primary audience. Each interview was conducted over video chat and lasted between 15-30 minutes. I observed several key takeaways, including:

• Rare Occurrence. People don't regularly participate in scavenger hunts.
• Competition in Moderation. While some people love competition, others are discouraged by it. These people tend to prefer cooperation.
• Hangout Duration. When spending time with friends, people normally spend at least 2 hours together.
• Planning is Frustrating. Planning an activity (scavenger hunt or otherwise) tends to cause the most frustration in users.

User Personas

Based on this research, I created two user personas to guide design.

Persona A: Jess

Bartender, 27

Jess is an adventurous soul with a penchant for exploring new city locales. A busy extrovert, the time she spends with friends over new craft beers and cocktails is treasured.

She hates any back-and-forth while planning, she just wants to make a decision. Her irregular schedule forces her to make most plans at the last minute.

Persona B: Martin

Management Consultant, 48

Martin is a busy man, trying to balance time with his family with his demanding work schedule. His busy schedule leaves little room for meticulous planning, and he's learned to love impromptu family activities.

Ideation & Design

I started with the features that I felt this design needed in order to thrive.

Merge Procedural Generation and Hand-Crafted Content

In this space, hunts are normally either procedurally generated (Pokémon Go), or they are hand-crafted, either by users (Actionbound) or by professionals (Let's Roam).

For our app, we would utilize procedurally generated stops and weave them together by hand to create a wealth of quality content.

Free Pre-Made Hunts

Any existing hunts would be free to play. This would include all hunts crafted by our team, created using procedural generation, or those made public by our users.

Paid Custom Hunts

Creating brand new or customizing existing hunts would cost money.

Local Business Partnerships

We would partner with local businesses to heavily favor their locations in our scavenger hunts.

Their businesses would often be the start or end point of a hunt in the area. These businesses could even add unique goals tied to their location, such as "Ask about the deer on the wall."

Hunt Scheduling

This feature was specifically designed to alleviate the frustrations expressed in interviews over planning activities.

The organizer would select a few days and times that worked for them and send it out. Each invitee would then select the days that best worked for them, simplifying the planning process.

Sitemap

With the key features decided on, I created a sitemap to guide interface design. I then refined it by performing a card sort using OptimalSort with 9 participants.

My initial sitemap utilized a strict hierarchy. The main focus was on two key sections: hunts and connect. These two housed most of the app's features, which would later prove to be less than ideal.

Rapid Prototyping

When turning an idea into a tangible design, I almost always start with this step. It doesn't take long to create some rough sketches on post-it notes, and it makes iterating through design ideas quick and painless.

This stage is solely focused on layout, so I always choose small sticky notes to force myself to ignore the fine details. Focusing on layout allows me to scrap ideas or add new ones without wasting unnecessary time or work.

At the end of this phase, a handful of designs emerge from the scrapyard of previous ones.

Low-Fidelity Wireframes

I took the best results from my rapid prototyping and scaled them up. I sketched out line drawings to flesh out a lot of those details that I purposefully avoided in the previous step.

If I were to do this again, I would conduct testing with these wireframes, as I would have been able to more quickly adjust to the feedback I received later on.

Mid-Fidelity Wireframes

I used Adobe XD to build more accurate line drawings, which allowed me to hone in the details without getting into UI design yet. I then connected these together into a flow to create a testable prototype that resembled an actual app.

Naming the App

Before testing, I felt that I needed a name. I decided on TurfQuest to give the app a sense of adventure within your own neighborhood: "Questing on your Turf!"

For theming, I renamed all scavenger hunts to "Quests" and was ready for testing!

Usability Testing

I tested with 6 participants to better understand the strengths of the app and where we can improve. Tests were conducted using video chat and screensharing and lasted between 15-30 minutes.

Test Results

Confusing Button Placement. Half of the testers did not expect that the buttons to progress would be at the bottom of the screen.

Payment Apprehension. The act of paying money for quests caused multiple testers pause.

Unexpected Payment. 5 out of the 6 participants expressed surprise after learning they had to pay for custom quests. The first indication of payment was after people had already put in the work of creating the quest. This may have added to their apprehension towards paying for the quest.

Hunt Scheduling Confusion. None of the testers understood how the hunt scheduling system worked. Each was also confused as to why they were doing it.

Hunt Scheduling Lacked Value. After hunt scheduling was explained, none of the testers saw value in the feature.

Revisions

Based on this feedback, I devised several key changes and fixes.

Cut Hunt Scheduling. Testers were being confused by a feature that they saw no value in. At best, this would end up as a sunk cost feature that required a lot of work for very little return.

Renewed Focus on Custom Quests. The previous design didn't highlight custom quests enough. Our business model relied heavily on users purchasing custom quests, so we needed to provide them a dedicated space to remind users of their importance.

Communicate Costs Early. An indication that custom quests cost something would need to be shown from the start.

Add In-App Currency. Adding an in-app currency would reduce player apprehension towards purchasing a quest by giving them an alternative method to pay for it. I named this currency "TurfCoins."

Side Quests

To support the new in-app currency, I added weekly challenges that allowed players to earn TurfCoins.

Called "Side Quests," these challenges are:

Location Agnostic. Players can participate in these challenges in cities, suburbs, and even some rural areas.

Unintrusive. Challenges can be completed during users' regular weekly routine with only minor detours.

Quest-Focused. The easiest way to complete side quests is to participate in a quest.

Every week, the main side quest was a tiered walking challenge. At different milestones, players would be rewarded based on how many steps they walked that week.

Other Side Quests would include:

1. Visit a Park 2 Times
2. Meet Up with Another Player
3. Visit a Restaurant

Revision Results

With the key changes decided on, I started by revamping the sitemap, making the hierarchy stricter and more balanced.

A stricter hierarchy would reduce confusion from many different intermingling functions. Most functions were rearranged to reduce the reliance on interconnectivity while vital connections remained.

To revise the designs, I repeated the earlier process:

1. Rapid Prototyping
2. Low-Fidelity Wireframes
3. Mid-Fidelity Wireframes

Finalizing the Design

I performed some basic A/B testing using UsabilityHub on the home page to better understand how to layout the "Your Activity" section.

These test results were interesting: the poll data indicated that the swiping action was preferred by users. However, the comments all pointed towards the swiping aesthetic as more pleasing, but no tester mentioned anything positive about the swiping action itself.

My takeaway from this was that people wanted to scroll but wanted a less cluttered look than the one provided. I merged the two designs to create a more aesthetically pleasing scrolling action.

High-Fidelity Wireframes

I then began work on the actual UI design of the app, resulting in the first high-fidelity wireframes. I decided on fonts, colors, and other formatting and put it all into a style guide. There were a few minor iterations afterwards based on an accessibility review and other designers' feedback.

Below are the latest iterations of the design.

UI Design

This was my first true foray into UI Design. Over the previous months, I spent time learning more about graphic design fundamentals. At this point, I had learned the basics and was excited to put that knowledge to the test.

Colors

I chose blue to encourage players to focus while on a quest. To contrast it, I originally chose an orange color to represent excitement, but struggled to find a shade that provided a pop of color without being overbearing. After several rounds of iteration, I decided to use a muted brown instead.

Fonts

I added two fonts, Omnes (for body) and Henriette (for headers). I chose both these fonts for their playfulness, which I wanted apparent throughout the app.

Looking Back

Overall, for my first real foray into UI design, I'm happy with the result. There are improvements that could be made, particularly in the choices and usage of color. However, I still feel that the end result represented the app well. With all these decisions made, it was time to put it together to create a final prototype.

The Latest Prototype

As with my other prototypes, I built this latest one in Adobe XD.

Peruse at your leisure, there are more sections of the app than I showcased in this case study.

Learnings

After completing this project, I walked away with several key learnings.

Test Early, Test Often

After my first usability test, I found that I needed to rethink a lot of my design. This meant taking several steps back to reevaluate the goals and features. However, nearly all of the tests' findings could have been found using low-fidelity wireframes.

Conducting testing earlier would have allowed me to pivot designs more quickly. I likely would have saved many hours of work on features that ended up being cut, such as the scheduling feature. Since this project, I've learned that even a single test in the early stages can save a design that is headed for trouble.

UI Design Can Heavily Influence Preference Testing

I found that my A/B preference testing was not as effective as I would have liked. The goal of the test was to determine the more user-friendly action. However, because one of my designs had a more polished look to it than the other, many testers were basing their decision off of how attractive the interface looked.

In future tests, ensuring that all versions are at the same quality of UI design can hopefully help alleviate this issue.

I Needed More Experience in UI Design

Arriving at the final UI design required a lot of time, research, and effort on my part. I struggled with how to properly utilize color, fonts, shadows and borders. I needed to expand my graphic design knowledge base.

After completing this project, I pulled together a collection of graphic design resources, including books, blogs, and videos. I also started saving references to UI designs that I like, so that I can reverse engineer what it is that works for them. Over the years, I've been using this collection to improve my UI design on various projects.