Role: UX/UI Designer, UX Researcher
Deliverables: End-to-End Mobile App MVP, Branding
Timeline: 200 hours
Tools: Figma, Optimal Workshop, Miro, Whimsical
In this project, I was the product designer. I worked with my colleague, who was the project owner, as well as the engineer/developer. He provided background on his project goals, desired features, and PCT resources.
• Branding: a name, logo, and styling
• Screens necessary for integral app tasks
• Style guide and annotated designs for developer handoff
According to the Pacific Crest Trail Association, thru-hikers range from their 20s to their 80s. Many of these hikers are app users, but some hike with paper maps only.
Our vision for the app was to provide users with environmental information along with the hike information (bear canister zones, cell service zones, etc); a more informative UI experience (labeling icons etc.; something the other app lacks, thus requiring a high threshold of existing knowledge to use); all in a personalized experience -- there isn’t one single way to thru-hike and the experience is very personal. We wanted the app to have flexibility to cater to different hiking styles.
I would consider myself a novice hiker, and that would be a generous description. I wasn't aware of the thru-hiking niche so preliminary research was crucial. I needed to understand when, how, why, where, and who was participating in this activity.
The industry is booming. Millennial and young people are driving the demand increase for hiking equipment. As young generations begin working and having disposable income participation in outdoor recreation is expected. to rise as well. (Young people are also more likely to use technology tools as well ✓. )
I audited the main competitor app FarOut (Formerly known as Guthook). Examining this app gave me insight into non-negotiable features we need to include.
I also took a look at more established, highly funded navigation and hiking apps like AllTrails and Gaia -- both far more fleshed out apps, but not as specialized for the thru-hiking niche.
Our MVP should consist of updated versions of existing apps features as well as the features users need that aren't currently being accommodated. I performed an audit to examine their design solutions.
The left screen shows the default app screen with a map selected. The red line indicates the main trail, the blue are side trails, and the bubbles are the waypoints. Users can pan and zoom in on the map.
__
From this screen, users can access information about the trail, start route tracking, or access quick tools. (Shown in the right hand screen). Here are some actions a user might want to quickly or frequently access.
All other actions are in the hamburger menu, or the elevation button, both of which take you away from this map page.
In some ways, a map is a map, and ours may not look so different. Users need to access similar things from this screen. I also wanted to center Traverse around the main map feature.
Aside from viewing waypoints in context of where they are on the trail line, users can also view waypoints in a list (much like the 'direction steps' function of Google Maps which we can see here in the left screen.
I noticed that users could search for specific waypoints, but I thought it would be great if users could search for waypoint types, e.g. water.
––
In the right screen, we can see the form to create a custom waypoint. Upon downloading the app and surfing around, I noticed this feature -- specifically the "choose waypoint type" portion. The app designers have added 8 pages of waypoint types, but you can't see what each icon means until you select it. As a non-hiker, I don't know what 90% of these icons are and I'm guessing I'm not alone here.
FarOut bundles their maps as whole hikes. Because we'll be starting with only just the PCT, we'll be tackling this section a bit differently as well.
I found this design solution a little clunky, hard to search and find what I was looking for, and overall a bit unrefined.
Through the generosity of friends and colleagues, I was connected with 4 different thru-hikers that agreed to be interviewed. 3 of them had used our competitor thru-hiking app, and one was an old-school hiker who used paper maps and improvisation.
Due to the pandemic, I conducted interviews over Zoom, each lasting 45 minutes.
What role does the hiking app play in user’s hiking trips?
How do people interact with hiking apps? Do they rely on them or use them as a fallback reference?
What are some frustrations users have about their hiking app, or what information are they looking for?
All hikers needed to see current location in relation to the main trail. Useful when exploring off-trail.
3 out of 5 hikers wanted map layers, and more hike info than just where the trail was in relation to them.
4 out of 5 participants said comments were one of the most valuable hiking app features
Water waypoints are important stops hikers make daily, and dry water sources was a common obstacle all hikers had faced.
All hikers listed connecting with nature, and to varying extents - discovery; as a primary motivator for hiking
4 out of 5 hikers wanted info about landmarks & potential points of interest for exploration
Despite my realization that we could not realistically create a magic bullet app to solve all of these people’s problems, I had gotten the sense through interviews that these people don't really want us to provide them with all the answers.
I've outlined the two ends of the needs spectrum that I identified through interviews. The hikers we're designing for are Kevin and Vanessa.
User interviews helped me gain insight into contextual considerations users had when using hiking navigation apps. Needs, preferences and fears vary hiker to hiker and thus information and features needed to fulfill motivations will vary as well.
THINKS
FEELS
SAYS
DOES
Task flow: simple, but not straightforward. Navigation and hiking apps don't have a definitive 'end' or 'fulfillment' marker. The task flow maps out common use cases.
The user flows are based off of Kevin and Vanessa: Kevin would use it mainly as a supplement to ensure he still knew where he was in relation to the main trail, and Vanessa would use it more intensively to find and save waypoints, and check her distance from them.
.png)
.png)
During the stakeholder kickoff meeting, I requested brand keywords. Working off those terms, I came up with a few different logo directions and names.
I generated probably 2-3 times as many of each as I would if I were working on a concept or personal project to make sure I had some option that successfully executed the stakeholders vision.
Some of the final options:
I presented this winnowed down list to my mentor after the stakeholder meeting and he provided me feedback from a visual design, technical standpoint. After making a few more adjustments, I was able to put together a few style tiles for the stakeholder.
.png)
A minimum viable product for this project was extensive because we were starting from scratch and the app was actually going to development. (I designed dozens of screens for edge cases and onboarding in addition to this MVP)
Here are Traverse's versions of the screens shown in the competitor app audit.
I took some inspiration from established navigation apps: Google and Apple maps (Apple maps has its flaws, but the UI is surprisingly solid). I showed my ideas to my stakeholder, as well as various friends and family members to get some outside perspective.
Here are the initial wireframes for the main tab in various states: the map view, expanded measurements, the quick actions, and search
.png)
The main app screen is the map. Here users can quickly access basic information: upcoming waypoints, elevation (top white icon), change the map layers (bottom white icon); view the weather (top right corner) or perform an action (plus button)
Users can access waypoint pages by clicking on icons on the map and then through to the full page, or via the list tab (2nd tab from the left).
Much like Google Maps' "steps" page; the waypoint list displays the upcoming waypoints in a list fashion so the user has the ability to view these in a spacial presentation (map screen) or as an ordered list. Users can search for specific types by clicking a waypoint type button, or entering a query.
The custom waypoint creation screen is similar to the list, users can specify what type of waypoint they're creating through tapping an icon. I anticipate users will want to create waypoints they don't want to publish to the world, (to agree on a meeting spot with a hiking partner for example), so they are able to leave the waypoint type unspecified.
The main map specifications I needed to include were:
• Recommended maps (app offers ups the next maps in the hike you're on)
• Downloaded maps
• Downloaded and currently viewing map
I did this through increasing the font weight and changing the color for the selected map, but I anticipate some users with a lot of storage on their phone may download a bunch of maps at once, which may make this list too long to be obvious. The bottom bar is stickied to the page and informs the user as to what map they're currently on, as well as where that is in relation to the hike as a whole.
I recruited 4 experienced hikers to participants in my usability testing. Two participants were people I had interviewed earlier in this project -- not ideal, but they perfectly fit this very niche demographic of thru-hikers that have used apps previously.
I performed moderated usability tests via Zoom, using a hi-fi prototype in Figma
"You’ve been hiking for a while and want to double check where you are. Open up and check the map. If you would continue interacting with the app after checking your position, please walk me through your next steps."
"You’re planning your day ahead, and you know you want to bookmark a cool viewpoint for today. Check the waypoints list, and navigate to the waypoint card for a viewpoint. "
"You’re spending the night in town and want to download the next sections of the trail while you have wifi access."
"You see a notice of a wildfire ahead. Go into the app and begin a a re-route log."
All 4 participants were able to deduce what was happening on the map screen, even if unfamiliar with the particular waypoint icons. The first task flow was largely exploratory.
All participants were able to complete the task in minimal steps, with few issues. 2 participants went through the list view, and 2 participants through the map view.
3 out of 4 participants had difficulty with the search function. The reasons varied: two participants assumed it would only search within their current hike, and one more similarly assumed but labeling didn’t clarify for them.
None of the participants correctly guessed the purpose of the orange caution icon. While some were close, the iconography is currently misleading.
3 out of 4 participants (all tasked with this flow) assumed “routes” had to do with downloading a new map section, not re-routes.
All participants struggled with labels and titles in at least one instance. The most frequent examples: copying coordinates action and search scope: current section/choose section
Lesson: Exact nomenclature especially for niche sectors is vital. Incorrect technical labeling can at worst completely impede usability.
The results of the usability test were surprising to me: the most common features and desires described during user interviews turned out to not be something that interested users, or the features they most valued while using the app.
For V2 I updated a lot of my labels to better fit. I also added additional screens such as a map showing the full hike including all sections, waypoint pages that are editable (for custom created waypoints), and more.
.png)
As mentioned earlier, this app is going to be publicly available so I designed a dozen or so additional screens for the developer that I didn't include in the MVP prototype. These include things like: the login screen, versions of the map and waypoint screens when you haven't downloaded a map yet, searching for maps when you don't have service, etc.
My developer is used to Figma design handoffs, so I didn't end up using a third party platform for handoff. Handoff was a multi-part process.
Outside of the time constraints of my and the stakeholder's schedule: this is my friend's passion project. I'm eager to continue fine-tuning and expanding the capabilities as resources and time permits. Hopefully we're able to do more research about how best to optimize within our resources.
Due to the granularity of the waypoint types, the optimal solution would be to create a fully custom icon kit that could include all these different waypoints and symbols.
Someday if we are able to purchase the super-granular data maps that would allow us to make real-time re-routes a thing, the re-route feature would need to be adjusted.
In this project I designed within a set of constraints that was new to me in this project (building a tool and the constraints around maps and scraping data) research was especially crucial. This was my first project in which I collaborated with a developer and had a formal design handoff. As we were designing from scratch, I created dozens of screens for him that are not included in this case study (e.g. page states where maps aren't downloadable, no map is selected, login pages, etc.)
I also learned how to design for a product aimed at amplifying an already complex experience. (building a tool and the constraints around maps and scraping data) In retrospect, the contextual and qualitative research needed in order to understand the user and their motivations was key (often more nuanced than to buy a product).
I like to get into the details and minutiae of the research and anticipate weird use cases, no doubt. But I need to be mindful of project scope ensuring feature implementation is realistic within the specified timeline, and whether adjustments need to be made. Through this project I think I struggled with confidence asserting my findings and decisions and thus sticking to the set timeline as initially planned. Something I look forward to bettering in the future.
–––––
From looking at other people's case studies as well as gaining a better understanding of the UX industry as a whole, I'm proud of my work. I think we took on an incredibly ambitious project (creating a whole brand identity, brand styling, documentation, prototype, additional screens for dev) that would generally take a design team months to complete and delivered on a very tight timeline.
.png){kind=small}
.png)
.png)
.png)
