Allison Milchling. Product Designer.


Mobile Backpacking Guide. Ensuring Adoption.

PROBLEM: Backpackers are required to pack multiple printed and electronic resources to complete a trip safely

The trip planner web application was created as a simple, thorough tool for backpackers to plan safe trips. However, once on the trail, these backpackers had no way to benefit from the planning they did back home on their computer. People still needed to pack maps, elevation profiles, guidebooks, notebooks, and phones to be properly prepared for their trips.

I was tasked with creating a mobile application that translated the appropriate amount of information and resources over to a central mobile solution. This would ensure a substantial user payout during their trip.

HYPOTHESIS: Backpackers would benefit from a comprehensive mobile experience on the trail

I went through each feature in the desktop application and gathered the ones that would be the most relevant on the trail. I left out information that was important to know beforehand, but became less valuable once a trip started. For example, whether or not pets are allowed on the trail is a good thing to know beforehand, but once you're on the trail pet-free, that information has already served it's purpose.

My strategy for what to focus on broke down into three areas:

USER FEEDBACK: Hiker mobile usage falls on a spectrum

With limited resources allocated for user research, the feedback for version 1.0 was light and informal. After connecting with ultralight backpackers on Reddit and receiving notes from a couple of team members, I discovered that on-trail mobile usage fell along a spectrum.

The primary reason experienced, ultralight backpackers tend to pack their phones is for safety. Preserving battery life is important so that the phone can be used in case of emergency. Offline experiences (whether accessible digitally via airplane mode or physically as printed out PDFs) were essential for this group. This group's approach to the app was as a last-resort reference to check unexpected weather conditions and other volatile characteristics of a hike. For them, if everything was going well, they saw no need for this app.

I also discovered -- from the ultralight group's feedback -- that the largest pain point that backpackers have is getting trustworthy information regarding water availability. Our app needed to provide a preliminary approach to solving that problem in order to provide the missing link to a holistic backpacker resource.

“REI hikers” were the term we gave less experienced hikers who had a tendency to do less planning beforehand. From talking with this group, I realized that our app would be a larger factor in the success of their experience. This group would rely on the features of our mobile app on a more daily basis compared to the experienced hikers.

FEATURE EDITS: Important information needs to be the easiest to access

Below is how our initial hypothesis evolved based on user feedback:

Trip Main Page


Weather Forecasts

News and Alerts

Packing and Checklists



SPECIFIC CHALLENGE: Finding the right solution for itinerary planning

I received varied feedback concerning the process for planning each day’s itinerary. Although I created a very basic solution for 1.0, I needed to make sure it was the right foundation for future iteration. To narrow down the path daily itinerary planning would take, I started by building a prototype for each of the four different ideas that had surfaced in testing. The ideas were a bare bones planner, an incremental checkpoint planner, a map-based planner, and a planner based on a series of points on a spreadsheet. I embedded each idea within the main mobile project.

I am still collaborating with my client and the users in order to land on a solution that properly balances functionality for the widest group of use cases. If done the correct way, this feature has the potential to empower a larger range of backpackers. My hypothesis, based on prioritizing "REI hikers", is that text and map-based input will win out over the spreadsheet version.

REFLECTION: What I would do differently and future plans

Other Work

Partner Portal. Enterprise Architecture.

Data Configuration. Autonomizing Workflows.