END-TO-END MOBILE APPLICATION
Making it easier to compare hikes
Alltrails is a super popular app among outdoor lovers (including myself :) ) It offers an abundance of information about hikes across the world. I discovered in research that users love the amount of information AllTrails offers about each hike, but users can often feel overwhelmed when they’re choosing a hike. I created a feature that shows data about two different hikes on the same screen, which reduces the users’ cognitive load.
Roles
UX Researcher
UI Designer
Software
Figma
Miro
Maze
Survey Sparrow
Project Type & Team
Academic for Designlab
(Adding a feature to AllTrails)
Hours
80
Project Overview
Project Brief and App Selection Process
This project’s brief stated that I could choose any existing product to add on to and within 80 hours would need to have a complete feature finished for prototyping and handing off. I had recently been using the AllTrails a lot and from a personal perspective experienced a lot of pain points. So I decided to see whether other users had similar experiences, and whether I could address those in this project.
A view from a hike in Acadia National Park that I found on AllTrails
Evolution of my problem statement
This project’s greatest challenges were objectively crafting research and analyzing data to come up with the best solution for the most amount of users.
Challenge #1: Not solving the problem for myself
Because I am a regular AllTrails user myself, I came into this project with a bunch of ideas for features that would improve the app for me. For example, I’ve had a lot of trouble with keeping interesting and accurate records of hikes I’ve done, and would love more journaling features on the app. But by approaching the research as objectively as I could, I discovered that my ideas for features weren’t popular among a lot of users.
Challenge #2: Identifying the most appropriate design solution out of many problems discovered in research
I approached my research by first identifying features I found in competitor apps that AllTrails did not have. But asking users about these features in surveys and interviews revealed low enthusiasm for any of those features to be added to AllTrails.
I did note many other pain points that AllTrails users face. But upon analysis, I realized that many of the revealed problems didn’t fit well into the scope of this project because they related to features already present in the app. Through a pain point analysis detailed below, followed by activities such as user personas to better empathize with users, I finally decided on a feature to design and test: a side-by-side comparison table between two hikes to make it easier to decide between hikes.
Competitive Analysis
I selected the competitive apps Hiking Project, Gaia GPS, and Strava because they appeared most frequently in a Google search of top hiking and fitness apps.
While comparing them I asked myself:
What features do competitors have that AllTrails doesn’t?
How do users perceive these features?
Record keeping feature of detailed personal notes and photos at different way points along a trail (and can add those retroactively, something you can’t do in AllTrails)
Displays what times of year hikes are most popular
Gives more detailed description of flora and fauna
Offers history of trail
Users themselves rate the difficulty of trail (six different tiers)
Has an interactive elevation gain map experience to help users understand how elevation changes at different points of trail
Various challenges
Various clubs
Strong emphasis placed on personal athletic stats
Users can rate perceived exertion when they log a hike
User Interviews and Surveys
Objectives:
Understand the user experience of:
Researching and selecting hikes
Wayfinding and navigating
Organizing information about hike ideas
Keeping records of past hikes
Interacting with other users on AllTrails (including social networking feature in beta)
Gauge user perception of competitor app features
User Interviews
5 participants
All participants were AllTrails users of varying frequency
Conducted remotely on Zoom
Included activity: users showing me how they typically use AllTrails to select a hike
User Surveys
16 participants
All self-identified as hikers of varying levels
60% were AllTrails users, with some experience using competitor apps. 40% said they didn’t use any specific app.
Conducted using Survey Sparrow
Limitations
All user research participants were non-parents, able-bodied and the majority lived in Denver, CO
User Research Analysis and Findings
My data at first felt overwhelming and chaotic, and part of me was initially expecting a more obvious pattern of users gravitating toward certain feature ideas. But what I actually found was that out of the various feature ideas I asked users directly about, there were no clear needs or desires for a single one. So I made an affinity mapping (pictured) to cluster interview and survey results into various themes to better understand options to moving forward.
I made an affinity map to analyze the user research
User Pain Points in AllTrails Specifically
Social Networking Apathy
Many users weren’t aware that there was a social media feature in beta. Those who did know about it said they likely wouldn’t use it.
Whoa, that’s underwheming! It doesn’t even have the most basic social networking features that have been around since Instagram and Facebook. I can’t even comment on a post or see photos of their hike
- Interview Participant
Navigation Feature Bugs & Battery Usage
Many users weren’t aware that AllTriails has a navigation feature, and they did not find it useful when I pointed it out to them.
Users who did know about the navigation feature reported concerns that their cell phone battery would die while using it on long hikes and probably wouldn’t use it for that reason.
Inefficiency of Choosing Hikes
Numerous users shared that they love how much information there is on AllTrails but that this also makes it difficult to research and decide on hikes efficiently.
I love AllTrails the most because of there are infinite trails on it and reviews of them. But I wish it were slightly easier to sift through all the information. Even tools that seem to intend to do that, such as tagging ‘easy,’ ‘medium,’ or ‘hard’, aren't that helpful for me because there’s a lot more nuance to hikes than those three categories.
- Interview Participant
Mapping Pain Points & Solutions
Looking at a list of all of the different features I had brainstormed through competitive analysis and user research, I created a decision matrix chart (pictured) to prioritize a feature prototype that would both be meaningful to users AND fit within the scope of the project. For example, I was able to rule out addressing pain points related to AllTrails’ social media beta feature because users expressed apathy about social media altogether. An in any case, addressing those pain points would have been improving on an already existing feature, rather than building a new one, as was outlined in the requirements of this project’s brief.
With my decision matrix, I also was able to rule out several of my other ideas for features that had minimal user enthusiasm.
A decision matrix mapping out solutions to pain points
Decision Time
Deciding between filtered features
After ruling out features that weren’t important to users or relevant to project scope, I was left with the following feature ideas options:
A lite version of the app to use while navigating
(To address pain point of batteries dying while using AllTrails)A “suggested hikes” feature based on a user quiz and past activity
(To address pain point of making decisions about hikes)A comparison table to show the differences between hikes
(A different solution to the challenge of making decisions about hikes)
A light version of the app was intriguing to me, but it didn’t feel as resonant with users as the other options, nor was I as confident in my ability to design it as the others. To decide between the final two, I put each one into a user flow to visualize where it would fall in the user’s journey of using AllTrails. The comparison feature seemed to flow most effortlessly (as shown below), and voila! I finally landed on the exact feature to design.
A decision matrix of filtered features suited to project
User Flow
I created user flows at this stage of the project to support my decision-making in which feature to choose. The flow below (showing how a user would arrive at a comparison table) made more sense to me rather than a flow with a suggested hike feature.
Further Definition of Problem
Let’s revisit the final problem statement:
Users face a high cognitive load when choosing hikes
Because the sections above were dedicated to demonstrating how I landed on this problem as the one to design for, I wanted to make sure I had thoroughly empathized with users about this particular problem. I did this using the empathy maps and user personas below.
Empathy Map
User persona
Ideation
Patterns Research
Aka figuring out how in the world I would fit all the information that would go in a comparison table into the tiny space on a mobile phone
As users noted in interviews and surveys, AllTrails truly has an abundance of information for each hike. It was a mental puzzle to think through how I could easily compare two hikes on one small, mobile screen. Luckily, the Nielsen Norman Group came to my rescue with an article that shared best practices for a comparison table. It served as a guidepost for the prototyping stage ahead.
Highlights from the research:
A “compare” button is a popular interaction for displaying a comparison table
On mobile view, it’s best to display only two items for comparison
The easier to scan the better (through color coding, standard table design of rows and columns)
Sometimes tables are converted into two different tabs, but this will require users to engage in compensatory decision-making (that’s design-speak for needing to remember a lot of information as they flip back and forth between tabs).
Special thanks to Apple Watch and Fitbit for also serving as key examples I could iterate on!
Brainstorming through sketches
I put what I learned in my patterns research to the test by sketching out a comparison table view on a mobile feature, followed by a different design option that had more words explaining the differences. I selected the comparison table view because it felt easier to scan and digest the information. (Again, credit to Fitbit’s design, which I modeled this sketch after.)
Version 1: I selected this version because it felt easier to scan
Version 2: This version felt least likely out of the two to reduce cognitive load
Prototyping
High Fidelity Prototype
I used AllTrails’ current UI and style to put together the following prototype tasks I would ask users to do in testing:
Find the compare checkbox below one hike
See the UI “compare” card and understand they needed to add a two hikes for the compare button to activate
Collapse the “compare” card to be able to see more hikes on scroll
Find another hike to compare
Skim the comparison table to understand similarities and differences between each hike
Find the individual hike information page to ultimately be able to add the hike to a list and/or download its trail map
More details about my design decisions
Element #1
A pop-up card that teaches users how to access the comparison table
I wanted to make it as obvious as possible that users need to add two hikes for the comparison table to appear, so I designed a grey popup card that gives a preview of the side-by-side comparison layout users will see in the table after choosing two hikes. The card collapses once the user scrolls to give more room to view photos and read hike information.
I also chose a grey color for the disabled state of the “compare” button to again teach users they needed to add another hike to compare.
Element #2
A sticky element on the comparison table with map views and trail names
For the comparison table, I wanted users to be able to quickly distinguish which hikes were in each column, so I included a small map of each one below their titles and kept that information sticky on the scroll.
The information I decided to include in the table was based on asking users in research about the most important factors in choosing a hike.
Element #3
A dropdown accordion that explains hiking jargon
I designed a dropdown accordion interaction to be able to create a hierarchy of information. This way the most important information would appear first while users still have the opportunity to learn more about what a specific descriptor’s meaning by clicking on the chevron. In this example, I was keeping beginner hikers in mind— one user interviewee said she wasn’t sure about the meaning of “elevation gain”.
Element(s) #4
Easy access to detailed views of individual hikes
I wanted to ensure easy access to see individual details about each hike that would require a full screen view. So I included a link to those in the static portion of the page under “see trail details”. I also created an easy way for them to expand the map from the comparison table for a closer view of it.
These detail pages are also important because they offer users the “final steps” once a user has decided on a hike: they can either add these to a list (from the details page) or download the map for offline navigation (from the map page). These options are part of AllTrails’ current design.
I also added an easy way to add the hike to a list straight from the comparison table so users didn’t have to navigate to the details page just to be able to do that.
The full flow of my prototype
Test and Refine
Usability Tests
All participants were able to navigate through the comparison feature with success (which means they could search and add hikes to compare and also understand the data they were comparing).
Even though there was a high success rate, users provided a lot of helpful comments that informed future revisions to the design, which are explained in more detail in the revisions section below.
Importantly, the majority of users reported positive experiences with the new feature.
Summary of testing:
Completed virtually on Maze
12 participants
75% of participants had used AllTrails before
7 users (58%) use it occasionally
1 user (8%) uses it frequently
1 user (8%) has used it before but can’t remember the last time
“Super easy to use, seems like a great tool! ”
“I like the side by side layout a lot.”
“I like the compare option.”
Incorporating feedback from user testing
Revisions to the Design
Subtle changes to the compare button
Users said they didn’t understand why a compare button was there in an inactive state, so I changed the final design to have the green compare button appear once users have clicked checkboxes for two hikes.
Fewer basic definitions, more detail on accordion menu
A majority of users said they expected to see more detailed information about elevation gain rather than just a basic definition in the accordion drop-down. Users also requested more generally that starting elevation and an elevation profile be included in the data.
A few more data points and hierarchy changes
Users requested additional data on the comparison table that I included in the second design (traffic level, most popular time, and average completion time). I also made it possible to collapse different sections so it was easier for each user to tailor the comparison table to the specific data they scare about.
Conclusion
Key Learnings and Reflections
This was such a fun project to work on, and it was especially rewarding seeing users comment during testing that this is a feature they would actually want. It also provided several learning opportunities along the way.
Hypothetical Recommendations for AllTrails
In both the user research and usability tests, there were numerous points for AllTrails to consider that couldn’t be included in the scope of this project, including:
Adding and/or enhancing a “search” field of user reviews so its easier to find information about specific topics
Information about where to sit along hikes (such as benches)
More detailed information about whether a hike is dog friendly, ranging from general to very specific.
General: “many hikes say they are dog friendly, but it would be nice to know if dogs can be off-leash.”
Specific: “In summer, many lakes have blue-green algae which is lethal for dogs. I’d like to know if there are risks of this in the area or other things to watch out for.”
User Research Learnings
Looking back at my user surveys, there are several things I would do differently now. First, in trying to be economical (as this was a student project) I used a platform called Survey Sparrow that I wouldn’t use again. The free version was somewhat restrictive in the types of questions I could ask and led me to format some questions into ranked choice, such as one question about features that I asked users to rank in importance. I do wonder what the data would have looked like if I had asked users to rate each of these features individually instead.
In this project I also conducted user surveys before user interviews. If I could go back I would reverse this order, because I based my final problem statement on a high cognitive load deciding hikes much more on user interviews rather than surveys. While the user surveys offered valuable data about features I could rule out, I would have liked to include more questions about the final problem statement and the features I hypothesized—both the comparison feature I chose for the design and the “suggested hikes” feature I almost went with.
An example of a ranked choice question in my user survey that I wished I had structured as a rating each individual feature instead.
A Note on Accessibility
I am particularly passionate about accessibility and had been experimenting with different accessibility tools during this project. Using a Figma plugin from Stark, I noticed that the color contrast of a lot of the text in the original AllTrails app failed accessibility tests. In the version of my design, I adjusted colors slightly to create better contrast. (Note that as I’ve progressed in my UX experience since this project, I’ve noticed that grey colors in many apps rarely pass all color contrast standards, which is a norm I’m trying to better understand the reasons behind.)
Photo Credit: by Scott Osborn on Unsplash