Hiking App Redesign

Context

This was a self-directed project completed in 2021.

AllTrails is an atlas app that uses a crowd-sourcing approach to compile hiking, biking and nature trail maps from around the world.

My objective was to audit the app for usability pain-points and offer solutions

Deliverables

Lo-fi wireframes

Programs Used

Balsamiq | Miro | Lucidchart

The Problems

An Atlas That Defaults to Lists

The app defaults to List View instead of Map View on the opening the Explore page (which functions as the home page and introduces the user to the hiking trails around them). 

The problem with List View is that it prevents the user from orienting themselves geographically, and compounds that disorientation by defaulting to trails listed by popularity instead of proximity. 

Most users will pull up the app at home to, say, plan a trip for a weekend versus arriving at a destination and trying to find a nearby hike. The later is a useful feature, but a map view offers more useful and actionable information up front.

Also the small texts “Map” or “List” in the upper right-hand corner are not obvious as as buttons or as a means of changing the interface.

Obscure Labeling

Map-View provides useful tools, but they’re obfuscated by their icons and labeling. AllTrails offers the ability to change the style of map-view (to show topography or a satellite-view for example) as well the ability to overlay the map with weather radar, pollen severity, fire history and more. This is great for trip-planning, but it represents those tools with two unlabeled icon buttons that both show variations on a “stacked planes” symbol. It then uses equally synonymous names (Overlays and Map Layers) to describe these tools (names that are only visible once the buttons are clicked and the user is transferred to an entirely new page.

Inconsistent Navigation

The navbar disappears when the user visits particular pages within the app and the navbar itself changes completely when the user enters the Record app within the AllTrails app. This forces the user to use an in-app back button to regain navigational ease and confuses them once the familiar navbar is replaced with a new one.

Illegible Text and a Granular Rating System

User-generated photos are used as the backgrounds for the Trail Info Cards and since most nature trails are through the woods, the photos are often full of sunlit foliage making the white text titles hard to read even with the help of the black gradient applied to the bottom of the card.

AllTrails asks users to rate each trail via a 5-star ratings system. The five stars and the subtle difference between the yellow and white used as their activation colors take a moment to discern even if the user has no eye-sight issues.

In addition the five-star system is likely to bog down the user with whether they should go with the 4.3 star rated trail vs a 4.5 star rated trail, when most trails lump themselves into 4-ish stars or 2-ish stars anyway. Besides, users are inconsistent in how they judge a trail: some reviewers give every trail they like 5 stars, while others may reserve a 5 star rating for trails they find to be exceptional and others will dock a star because a trail was too hard; others because it was too easy.

A ratings system should focus on providing the user with quickly digestible, pertinent information.

Dangerous Ambiguity

One of AllTrail’s key features is the ability to load a trail-map and record the user’s journey along it. If a user wanders off trail, they may need to retrace their steps to recover from getting lost. If the user thought they were recording but weren’t - they would have no breadcrumbs to follow back to the trail. It’s therefore critical that the app unambiguously tell the user whether it’s recording or not. The app currently uses a red button for both states with the only difference being the presence of the pause button when recording which is too easily misconstrued.

The Solutions

A New Default

A major issue with the original app design is its defaulting to List View instead of Map-View. The problem with List View is that it prevents you from orienting yourself geographically, and compounds that disorientation by defaulting to trails listed by popularity instead of proximity.

Filters have been placed inline with these Info Layers and Map Type so that everything a user needs to thoroughly explore an area is readily available without having to lose sight of the map.

Clarifying Usefulness

In my redesign I’ve changed unlabeled tool icons Overlays and Map Layers to text drop-downs Info Layers and Map Type since the concepts are too abstract to translate well into icons. In addition these terms are more differentiated and better describe the tools they contain.

The integration of the dropdowns has the additional benefit of of allowing the user to choose a new Info Layer to load without an intervening trip to a navbar-less menu page.

Slide On Up

My proposed design features slider access to List-View. This more seamlessly integrates both views by allowing the user to browse the trail cards without triggering a reload plus it keeps the user oriented by showing trails that are already in view on the map, listed by proximity to the user’s location or a selected waypoint.

Pruned & Consistent Navigation

In my redesign the navbar is a reassuring constant on every app page

I’ve also condensed the original five buttons into four. Plan and History were both lists of bookmarked trails, so I combined them via the My Trails button. Record has changed to the more descriptive Load Map, since you must load a map to record anyway.

Legibility is Accessibility

In the Trail Description Card I’ve moved the user images to their own frame separate from the text description instead of using the photos as backgrounds for the description header. A separate frame for images vastly improves readability of the important information on the card.

An Simpler Ratings System

In changing the 5-star rating system to thumbs-up or thumbs-down, I hoped to declutter the interface and create a more useful means understanding which trails are worth one’s time. Green and red color-code well or poorly rated trails which stand out at a glance as opposed to all yellow stars. The nitty-gritty as to why a trail is liked or disliked will be evident in the trail description page, where tags and reviews can give insight into reviewers’ decisions.

Retaining the number of ratings in parentheses is important though, as the user needs to know how popular or how untraveled a trail is for safety reasons as well as how the ratio of recommendations versus dislikes stacks up.

Skeuomorphing Icons

AllTrails offers the ability to save trails to a favorites list via clicking a heart icon. I chose to change heart icon to a thumbtack to avoid unnecessary presumptions about a user’s intentions. My reasoning was that a heart implies a basic level of affection for a trail whereas a thumbtack is neutral. A hiker might need to favorite a trail simply as background information or because it’s an uninspiring trail but necessary to get where the hiker needs to go. Requiring a user to make an emotional statement in order to bookmark a trail is not necessary and at worst, might make a user pause before clicking. Additionally, the thumbtack keeps to the theme of the app as it is representative of how one might mark points on a paper map.

Menu Stability

My new design maintains a stable navigational environment working off the same architecture as the redesigned Explore page (map view, slide-up detail cards). The navbar now stays the same as in the rest of the app. The tools specific to the Record/Load Map page can now be accessed via a long click on the map instead of taking over the navbar.

Visibility of System Status

The record button now signals to the user in two ways (via color and text) whether it is engaged or not and doesn’t interfere with the navbar. This should cut down on the frustration of forgetting to hit record, or the user not being sure if they are currently recording.

Better Access to Information

In the old app, you could not easily reference the trail information for the trail you were on as it required you leaving the “Record” environment.

It’s now easy for the user to call up the trail description of the trail they’re using via the swipe up tab. Beneath the description card is a link to load a different trail as well as a chronological list of user activity while recording.

There was no indication on the original Record page that a map was or was not downloaded. I’ve added a red banner across the top of the map to remind the user that the map they’re viewing has not been downloaded and tapping on it links to the download page.

The Take-Aways

I would conduct significantly more user research at all stages of the project to provide evidence for or against my hypothesis and to limit the influence of my biases.