Case study: designing “Take a Hike”

Native iOS app for BC Hikers

Take a Hike is an iOS app that allows hikers to both mark and follow hiking trails (similar to the way Runtastic tracks your run). It makes finding information about hikes easy (information like difficulty, dogs allowed, km long etc), and helps users stay on the right trail. Users are able to upload the information themselves and other users are able to confirm or edit the information.

I chose to make this app because I and other hikers I’ve talked to find it difficult to find and follow hiking trails in BC as they are not well marked.

A couple years ago, search and rescue came up with the #trailheadselfie campaign. They encouraged hikers to post a selfie on instagram with the trail head and hashtag it #trailheadselfie. There was a CBC article saying that rescue decided this was a bad idea because trails in the lower mainland are networks. They branch off and lead to many other trails, so where you start is not necessarily where you end up.

This reminds me of the time I tried to find “lost lake” based on a stupid arrow at the trailhead. I ended up on top of the mountain, only to learn I had made a wrong turn somewhere and the lake was actually near the parking lot. I was also wearing shorts in the snow (I wasn’t aware there was any snow in July) and got swarmed by the morning flies (that’s actually a thing, they’re gone in the afternoon).

It is also difficult to find information leading up to the hike (is the road paved or is it a service road? Do you need an off-roading vehicle? where does the trail start? etc).

This app can combine a trail map, user generated directions to the hike, user generated hike information, and photos all in one place.

Target market:

  • Anyone who enjoys the outdoors can benefit from this app
  • Locals and tourists who want to go hiking but are unfamiliar with the trails
  • Those who are not die-hard hikers but hike occasionally and don’t know where to get information

User Research

I interviewed 3 people and got 32 survey responses.

Based on the surveys and interviews, the most obvious frustrations people have when hiking is that they sometimes hit unexpected problems such as bad trail and road conditions, bears and closed trails.

The majority of those surveyed could not find driving directions that led them to where the hike starts but instead lead them to coordinates below the summit, or to a service road meant for trucks not hikers. Another issue the majority had was finding the trail start from the parking lot.

I also noticed photo taking is a common theme among the surveyed. The majority of people carry a camera or cell phone when hiking for the purpose of taking photos and social media sharing.

Based on the themes in the data collected I created the following personas:

Primary persona: these users hike occasionally for the visual aspect and to take photos. They care about finding picturesque hikes and want to find information quickly and easily so they can be well prepared for their hike.
Secondary persona: represents the “some” that carry Fitbits and hike for excersize

Based on the above personas I came up with these features:

The perosonas helped me to prioritize the features in order to come up with an MVP

The features on the yellow stickies are needed in order for users to be able to reach their goals. The features on the hot pink stickies would add additional value to the app but are not necessary in order for users to reach their goals. The feature on the light pink stickie is not needed since fitbit users can just use the fitbit app.

Having user accounts is necessary in order to have user generated information. Since a main frustration is inaccurate information and directions, users need to be able to get verified information via other users who have recently done the hike.

The “alerts” feature is a way in which users can submit notifications (such as a bear siting or snowy trail) quickly. The alert appears on the hike’s profile page so that users can prepare for unexpected problems on a hike.

Since users are into taking photos, they can explore hikes by viewing scenic photos of that hike. They can also browse hikes on the map or search for them by name.

Users can also add hikes to favorites so they can find them quickly later.

Since photo taking is a major theme in the research, its important that the information is organized in a visual way, such as browsing through hikes by photos.

In order for the app to be populated with photos it needs a feature which allows users to upload photos to the app and categorize those photos by hike name.

Most users are frustrated by incorrect directions and incorrect hike information and user reviews can solve this problem. There must be a feature which allows users to submit and read reviews.

The “track” feature allows users to track their path along the trail, then submit it to the app. Other users can view these maps to get a better idea of where the hike begins relative to where they are. This can help when users are unable to find the start of the trail.

At the end of the hike, the “track” feature can show a summary of the km hiked, how long it took and average speed. This can be useful for the secondary users that hike for exercise.

User flow & wireframes

There was a lot of back and forth when I was turning my user flow into a wireframe. As I was creating the prototype I realized that the user flow was missing a lot of pages and some of the flows lead to dead ends which meant a lot of “back” buttons.

The process of adding photos for example, was supposed to be:

add photos-> allow camera access -> camera.

Then I realized the camera page has several options: choose from camera roll, download image, delete image, use image.

These were all features that were added only to the prototype as I realized they were missing and are not part of the flow.

Some pages I felt were not necessary to have as a page in themselves. For example the “recommended hikes page” could be a horizontal scroll on the home page instead.

I also had to change the order of some pages, like the allow location page, which comes after the login in the prototype.

Wireframes and usability testing

There were 3 tests done of the wireframe.

Most of the reviews were UI related (photos are missing, no icons in the navigation etc.) I’m not sure if the testers knew that was intentional.

All 3 reviewers were able to name all the features on the home page and confirmed most of the features for the MVP were of value (for ex. search, map view, reviews, and trail info.

Originally I had “Search” “Explore” and “Track” as large buttons on the home page. These buttons are also in the navigation. The reviewers pointed out that the space those buttons took up could be replaced with something more valuable like the weather, since those features are also part of the navigation.

Based on user tests I also changed the order of the navigation features.

Right: original home page, Left: revised home page

My biggest challenge at this point was making the pages look less cluttered without taking away any content or functionality:

The main hike page had too many buttons, the information was cramped and the photos were too small.
By combining multiple pages into one long page I was able to get rid of the buttons, and users won’t have to go back and forth between pages, they can just scroll down. The photos and map are expandable, and there are more pixels of space between content.

The surveys and interviews showed that users had a huge interest in taking photos when hiking. Since the scenery is important to users, photos should be focal and visible. It was challenging to make the photos focal at the same time fit many on one page. I didn’t want to put a cap on how many photos users are able to upload.

Originally the photos were small, making difficult to focus on one photo at a time.
Looking to the airbnb app for inspiration I made the photos larger and kept the vertical scroll

Next I wanted to make it easier for users to search for a hike. Not being prepared for a hike was a main frustration among those interviewed. By adding a search filter users can go on exactly the kind of hike they’re up for.

Users can search for hikes by duration, difficulty, how beautiful the scenery is etc.



The best part of designing this app was finding out that other people have the same problems as me when they go hiking.

I especially like that the app and all its features were created based on the frustrations and goals of real people, and everything in the app serves a purpose to its users.

I learned that designing an app (or anything) requires finding different/better ways of doing the same thing. Even if it has all the features it needs, there’s probably a better way of presenting and organizing those features, for example, making one long scrollable page versus multiple pages.

This can be applied to so many things, like writing code, cooking, driving — there must be a more efficient way to get from Coquitlam to West Broadway!

I also learned that although there is somewhat of an order to the design process, it is anything but linear.

I found myself going from prototype, back to the research phase, to changing my user flow to changing my prototype and looking back at the research again. Every time I did this I was able to make small improvements which eventually lead to major changes of some pages.

The main takeaway is that nothing is ever finished; there is always room for improvement.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.