Excursion

App Design

Introduction

This project was an educational exercise to design an end-to-end mobile app. I chose to work on a hiking app with added functionality beyond what AllTrails or similar products offer.

Brief

From the project brief developed for this case study:

“Excursion is an app that provides a guided, curated experience of a hike. Like All Trails (an existing hiking app) it provides information on various trails and experiences, but will also have the capability to include historical/natural context and photos showing the correct turns to take. This information can either be crowd-sourced or provided by a managing entity (such as a national or state park).

A primary goal of the app is to enable users to experience and learn about the places they visit without removing them from their environment and company by demanding too much of their time.”

I specifically chose to focus on three tasks to limit overall scope:

• Finding a hike

• Going on a hike

• Creating your own hike

Here are the high-level design goals for this project:

• Generate the design for a mobile app that allows users to browse, undertake, and create curated outdoor experiences.

• Create the visual identity for the brand, including color choice, typography, logo, and UI kit.

• Design an example experience using a real-world hike.

I followed Material Design guidelines closely for this case study.

Tools Used:

• Figma

• Adobe Illustrator

• Adobe Photoshop

• Material.io

• Whimsical

• Google Docs

Here is a link to the final version of the Hi-Fi prototype:

Research

Goals

I focused on the following goals in the research phase:

• Discover how users interact with technology while experiencing the outdoors

• Understand how users interact with hiking apps and websites

• Uncover any elements or interactions that would provide a negative or positive experience

• Establish how other services accomplish a similar set of features

• Detail any common design patterns among similar services

My full research plan can be seen here.

Methodologies

I employed three methodologies:

• User Survey

• User Interviews

• Competitor Research

Results

My research report covering primary takeaways and actionable items is below. If you are interested you can view my User Survey Report here, my User Interview Report here, my Competitor Analysis Report here.

Assumptions

I made three assumptions that turned out to be incorrect. They are not included in the report because understanding these errors was an ongoing process from the late-research phase to after I generated a persona.

First, because I have worked on guided tour projects before I assumed the concept of “points of interest” would be widely understood. I started to realize that this is not true during my research process but did not fully grasp the lack of understanding until my first round of usability testing. In reality points of are interest initially confusing but users figure them out given room to experiment.

Second, I expected that the flows to add a hike to an app would be relatively straightforward. This is not the case. (This is not specifically research related, but it was an assumption that proved to be incorrect and dramatically affected my process.)

Third, it did not occur to me that a fundamental reason some people do not go hiking often is due to possible harassment or other human dangers. Due to my privilege, I only focused on safety issues that are likely to affect me such as animal sightings, trail issues, inclement weather, etc. A specific custom response to the survey first clued me in that I was not considering the concern of harassment or violence. After that I spoke with my mentor and informally asked questions of friends to figure out what this app could do to protect and allay fears.

The outcome is an expansion in scope. I initially planned to focus on the tasks and goals listed above, and to intentionally not design anything outside the project parameters. After realizing the errors in this third assumption I felt the need to expand the scope to include more safety features than initially planned.

As a result I designed a safety check feature. A user can list an emergency contact then set the app to text that person if the user has not checked in by a specified time. I do something similar whenever I hike alone: I leave a post-it note on my desk with the name of the trail I’m going to and when I expect to be back.

I also built a “Report an Issue” flow. This ties in with a feature I would add down the road if this app was actually being developed: live trail conditions displayed Waze-style.

Define

Persona

I built Mandy primarily around the input from user interviews. My goal was to create a persona that is interested in learning and motivated to go outdoors but has obstacles that keep her from doing so as much as she would like.

Sitemap

In hindsight this sitemap is laughably too simple.

I call this sitemap simple because I dramatically underestimated the complexity of the flows I was working with, specifically the add hike feature (labelled “Add Trip” above). This happened because I did not include task or user flows in my process for this case study. I ended up writing out the various stages of these flows while wireframing but I should have done it earlier.

Here is my UI Requirements Document where I break down what I expected to create for this flow. Below is a screenshot of the relevant section.

The fundamental misunderstanding was around the second stage named “Select Points on Map”. I thought that, similar to services like Google Maps, picking various points on a map could easily result in connecting those points with a path. That selecting various points of interest could automatically generate a trail to follow.

This, of course, does not work unless the paths have already been entered into your map data and even then there can be issues. I would have realized this if I had spent the time to make a task flow. Lesson learned.

Feature Roadmap

Here is the feature roadmap I built for this project. It ended up not being completely accurate, due to the learning processes around safety and flow complexity.

I decided to remove ratings of points of interest. At the end of the day they felt redundant. I initially included this feature as a way to crowd-source the vetting of points of interest. Highly rated points would be higher quality and could be promoted within the app. Once I made the shift towards a safer experience, I added language around the concept that public content added to the app would need to be vetted by a moderation team. At that point, the star ratings for points of interest did not serve their purpose and were removed. This concept could come back for future iterations, but it would be Tier 3 or below.

I also decided to add a Public/Private content feature. Private points and hikes would not go through moderation and could only be shared directly with other users. This small decision drastically increases the functionality of the app.

Wireframes

Here are the sketched wireframes:

And here are the digital wireframes:

Some pages (such as the home page) made their way essentially as is all the way up to Hi-Fis. Most pages received more attention.

Usability Testing Round 1 - Wireframes

At this point I conducted an initial round of Usability Testing. In general I received positive feedback. You can see an affinity map of the results below. Here is a link to a larger version that’s easier to read.

Primary takeaways:

• All added features outside of what AllTrails offers were confusing.

• The add hike flow feels daunting even before you tap into it.

• The point of interests were initially confusing, but participants quickly figured the system out.

These takeaways prompted me to move in a direction of easily understood features and functions. I considered tutorial flows on first use of a feature, but realized that would likely create more problems than it fixed. As my mentor said: “people don’t read”. It is infinitely better if the confusing parts of an app explain themselves and that the app does not penalize experimentation. Show, don’t tell.

The major takeaway from this first round of testing was a way to improve the add hike flow. One participant suggested that users could add the hike as they went on it. This appealed to me for several reasons:

• I had not found a good way to allow users to create points of interest within the add hike flow. It is extremely unlikely that a user creating a hike would only want to use preexisting points. In this model, users hit a button when they reach something they know about/want to explain and the location is automatically gathered.

• This method addresses a safety concern that was developing: people could hypothetically create impossible or extremely dangerous hikes without having to complete the hike themselves. This model makes it significantly more difficult to create fictitious hikes. With the added step of a moderation and approval stage this feature is considerably less risky. (The comparison I make is to the game Mario Maker from Nintendo where users can create their own Mario levels. To submit them they have to beat the levels themselves so that unbeatable levels do not get uploaded to the service.)

• This solution also eliminates my worry about how to connect points together into a cohesive path on a map. Track the location data and you have a visualization of a hike, including automatically tracking distance and elevation change.

I wish I had thought of this solution myself but I ran with the suggestion and implemented it in the next round of changes.

In areas where GPS signal is weaker this method would not work, at least as well. Eventually, to accommodate those hikes, the ability to upload GPS data from a dedicated device would need to be implemented. Dedicated GPS devices generally have the ability to mark way-points, and that information could be extrapolated to use as locations of points of interest. I decided to leave that feature off this case study as it is out of scope.

Design

Logo

The logo for this project came together quickly. I knew the concept of what I wanted when I wrote the brief.

The initial sketch was just to get my concept down on paper.

I used the silhouette of the first big mountain I climbed (Cathedral Peak in Yosemite’s Tuolumne Meadows) as reference.

The only thing I feel is missing from this logo is some indication of the educational aspects of the service. I briefly considered including a signpost or something similar but that over-complicated the design.

I wanted the typeface to feel organic, as if it was the handwriting of someone who had written out a set of instructions for a hike on a piece of paper that you’ve got in the side pocket of your backpack. Kalam (the typeface) doesn’t evoke all of that concept, but it serves my purposes.

Style Tile

Here is the Excursion style tile:

For the primary and secondary colors I compiled a set of photos I took while hiking over the last few years and identified the more common colors. The blues are taken from the sky (though I had to shift them a little bit to account for accessibility contrast with text). The grays are from the shadows.

I snubbed green because the shades I found in the photos I had taken were not particularly satisfying and the direct competitor to this hypothetical app, AllTrails, uses green heavily.

The other option I considered was a lighter stone-gray shade. It just wasn’t as compelling as the darker gray.

All of these styles are implemented in Figma. See below:

UI Kit

Here is the Excursion UI Kit:

This is the final version of the UI Kit. I built the first version prior to starting hi-fis and continued to iterate as I went. Most of the items here were heavily inspired by, or in the case of the icons taken directly from, Material Design. Notably the text entry fields aren’t exactly as specified Material.io.

Here are some of the variants in action, using the icon component.

Hi-Fi Designs

At this point I generated the first draft hi-fi design of the app. More learning occurred here, largely (again) because I skipped the user/task flows.

This learning process primarily involved stripping down the primary actions of the app to the most efficient, most concise versions. Specifically, I included four pages of configuration choices between choosing to go on a hike from the hike details page and actually starting the hike. The stages:

1. Parking information/navigation to the trailhead

2. Safety check/safety information

3. Type of point select: which types of points would be shown to the user while on the hike: navigation, information, and/or warning.

4. Location tracking

These steps were not necessary in this form. The flow in my head was: find a hike to go on, set up that hike, go on that hike. All I needed was: find a hike to go on, go on that hike. The user can then alter the configuration within the hike, like in the drawer accessible within Google Maps’ navigation mode. I implemented a similar drawer with the ability to select the types of point shown on the map and various other configuration options including the ability to suggest an edit for the current hike.

The remaining information was moved to the hike details page.

Here’s a link to the final version of the design.

Add Hike Flow

I wanted to highlight the add-hike flow as it proved to be such a thorny design problem. Here are some images, shown sequentially from beginning to end:

I omitted some interstitial stages here to cut down on the number of images. One user commented that even though the concept of adding a hike to an app like this was daunting, after going through the other tasks and using the app for a period of time, this entire flow felt like they were on autopilot. The conventions established elsewhere provided the education and I did not need to add any tutorial flows.

I’ll call that a win.

Testing

Usability Testing Round 2 - Hi-Fis

In the second round of testing I wanted to see if the work I did improved the experience of the primary tasks I designed around. I also wanted to know if adding tutorials or other forms of education was going to be necessary after the changes I made. Here is the full testing plan.

Affinity Map

After completing the Usability testing I created an affinity map to highlight patterns. The image is a little too big to display correctly through this Squarespace template, here’s a larger version.

Usability Test Results

Here are the actionable items generated during Usability Testing:

• Add an initial splash screen prior to on-boarding that goes into a more detail on what the app does.

• Provide a tutorial when users start a guided hike for the first time that includes instructions on the drawer and its functions.

• Add the route on the map for the section of the report flow where users indicate the location of the issue.

• Place the public/private sharing settings at the beginning of both add content flows. Previously this step was the final stage before reviewing the addition and submitting it. This will eliminate any confusion around the sharing label (as this decision will be the first thing they encounter upon attempting to add content) and will set the mindset for the rest of the process.

The full Usability Testing Report can be found here.

After experimenting with the first two actionable items I altered my plans slightly.

The first item, adding in a splash screen with information about the app, did not feel great. As soon as I implemented it in a basic form (a single page with some copy) I wanted to remove it, so I did. If I continued development on this project I could return to the idea after further rounds of Usability Testing. The right way to do this is to emulate other apps and provide a several page flow with illustrations, photos, and maybe a little animation specifically targeted at areas of confusion around the functions of the app. This flow is a little out of scope for this particular case study.

For the second item, providing a tutorial, my mentor suggested that the only real problem with that section was that participants of usability testing did not know about the drawer. Before participants left that section of the prototype I prompted them about the drawer and that allowed them to intuit the reason for/function of any aspects they were unsure of. To alert users that the drawer existed I added a brief animation of it bouncing up when first starting a hike.

I implemented items three and four. I also fixed a few typos and consistency mistakes throughout.

I want to highlight a specific comment one of my participants made during testing:

“It’s only frustrating when I can’t click on something. I wanted to experiment more, try things out!” - Participant A

I consider this a big success. I received several other comments in this vein. I’m proud that my design with its complicated functionality elicits these responses.

Final Design

Here is the homepage of the final design.

The best way to view this design is in the prototype. You can view it as an embed below or by following this link.

You can press “R” to start the prototype over from the beginning. I recommend viewing in full screen.

The specific tasks that should be functional copied from the usability testing script:

• Your first task will be to find a hike you’ve heard about from a friend: Timberline Falls.

• Next, I’d like you to go on the hike through the app. Once you reach a “Hike Complete” page you’ve succeeded.

• While on the hike you saw a moose and want to report it so others will know. Your next task is to report that information.

• Your next task will be to add a new point of interest to the app.

• The final task will be to add a new hike to the app.

Conclusion

This case study was significantly more complicated than intended. I am quite happy with the final product, though of course there are still improvements I could make.

The safety considerations of this project are the stand-out learning experience. What are the features of a hiking app that would support a user in feeling safe to go on hikes? I have tried to find the answer with this case study, in large part due to a comment made in an anonymous survey response. This learning process provides evidence of how important user research and understanding one’s own perspective and bias is.

As I mentioned above, I will not attempt another design process without including task/user flows. Omitting them was a mistake that cost me a lot of time. I have already gone into detail on the add-hike flow: that was the prime example in this project of too much time spent when it was not necessary.

Adding a public/private system for user added content is what would give Excursion the highest chance for success were it to actually be developed. The ability to create custom hikes is an interesting addition, but being able to create custom hikes for friends and family without requiring a moderation process is a potential game changer. I want this product, three of four participants in the second round of usability testing wanted this product. I consider that a success.

If I continued with this project, these would be the next steps:

• Continue to add features, specifically:

  • Workshop some introduction flows prior to the login section.

  • Difficulty rating for hikes similar to ski slopes, something to give a general idea of how hard a hike will be

  • Design the profile/settings pages of the app to support the various existing features

  • Add a pin/password system for disabling the Safety Check feature (this would be toggle-able)

  • Create a sharing function for completed trips, custom points, and custom hikes.

  • Add the ability to upload GPS data from a third party when a given hike is out of service range.

• Monitor responses around understanding of app functions

• Refine language: some participants responded negatively to specific word choice. It would take more testing to narrow down whether those specific instances should change or stay the same.

• Speak with a developer to ensure that all features, existing and planned, are viable to develop and produce.

Here are the things I will do differently for my next project:

• Continue to hone my Figma skills and consistency. I did a better job on this project than previous case studies, but I still have room to improve on layer naming, style management, and component management.

• Always include task and user flows in my process.

• Simplify my flows. I have a tendency to include extra pages and steps that are not strictly necessary.

• Keep an open mind to alternate solutions (such as the bouncing drawer to prompt users to investigate that functionality).

Thank you for reading through this case study on the Excursion app design.

Other Case Studies