TRAIL LISTINGS

PROBLEM: Guidebook-level hiking information is digitally inaccessible

A lot of factors go into planning a safe and fun backpacking trip, but just discovering when and where to go requires a lot of work across multiple references. There was no central place online to browse this information all at once. This barrier contributed to the fact that most backpackers didn't take the time required to understand the region they want to hike in. Most people were dangerously underprepared for their trips. And the group this decentralized information effected the most were the people who found it to daunting to an obstacle to the resulting fun - the people that decided hiking must not be for them.

HYPOTHESIS: An online database will empower more people to go hiking

If a service existed where people could submit their route and gain access to the information about the region all in one place, their trip planning process had the potential to change completely. My goal was to create a database of regions that consolidated all of the important information. Experienced hikers and researchers would manually input data for each region into a backend system. Then, public users would be able to search by location or upload their GPX route to access detailed results. The information would help users understand all aspects of the region - from water sources to park fees to potentially dangerous wildlife.

USER FEEDBACK: Backend data components need to be more clearly defined

Once the initial wireframes had been translated to staging, our researcher started to use the product to create region listings. After completing a few regions, she shared her feedback. Some of the biggest insights are listed below:

WHAT DIDN'T WORK: A checkbox with more than one option

The most important insight from the feedback was how unintuitive the input format was for the majority of the fields. In an effort to simplify the UI, I had created a really bad idea where a user had to click a checkbox multiple times to choose between four general options: affirmative, unknown, negative, and unset. This oversimplification went over the heads of the user at a basic level: they disregarded it. But even once they became familiar, it still was so simple that it created ambiguity around what was being defined. It was a really bad idea.

The great thing about this checkbox failure was that in redesigning it, I also discovered that the “unknown” option needed to be removed completely. Although marking things as "unknown" was a big aspect of the initial design, it threatened the value of our service. I moved to marking options as only affirmative or negative. My new philosophy was that if there was any potential for a data point to be relevant, then it was to be be marked as affirmative. Including "unknown" had provided a way for the information this service reports to be less trustworthy since we'd be reporting that we simply didn’t know. And because I was including a notes field for every data point, clarification on the degree of likelihood could be mentioned there if needed.

ADVANCED INPUT: Creating a mobile trail recording tool

Although the main method of data entry would be manually on the backend of the web app, a certain level of data was impossible to catalog without going directly to the field. The best way to provide guidebook-level detail was to have real people hiking the trails and recording its characteristics in real time. In order to make this possible, I developed a complimentary trail recorder application.

Based on a GPX route, a user would be able to walk the trail, record their route, and document the important details that are so great to know, but so hard to find online. This tool had to be simple and intuitive for ease of use while multi-tasking on the trail. It also had to include all of the essential data points. I rearranged the proposed flow so that users would be able to focus on the right things before, during, and after the hike.

REFLECTIONS: Early usability testing is critical for backend design

Because the bulk of this project was essentially a database design, all of the interaction design decisions directly affected the strategy for backend development. Unlike frontend changes, certain backend changes can essentially call for starting over from scratch. This was the case after our first usability study. If I could do this all over again, I would have fought for more time to test with a target user before kicking off the project. It would have created a more efficient development flow, protecting development resources and keeping the development team much happier.


OTHER WORK

Trip Viewer

Mobile backpacking app

Trip Planner

Small business web application

Team Management

Productivity app