Planning a backpacking trip required a lot of research. The best solution at the time was a collection of elaborate spreadsheets created by each individual hiker to organize their specific needs. Most hikers were not dedicated enough to use this methodology and were underprepared for their trips.
The basis of this project was a PDF containing over 60 data points. My job was to take these ideas and develop them into a product that helps backpackers of all skill levels efficiently prepare for fun and safe trips. I was hired to develop the product strategy and interaction design for the application. My 1.0 design would go on to frame backend development and also be the foundation for later UI design guidelines.
There was a range of information that needed to be validated: data that seemed vital to have front and center, data that could be automated and processed without user input behind the scenes, and data that had no apparent benefit for the user. I considered the planning process a target user would go through and mocked up a user flow to kick things off. Due to the large volume of data, I planned out the functional structure of the application in a spreadsheet before the wireframing process began.
The first target user I talked with was a very well known backpacker. His initial reaction to the project was that it was not useful for his trips. As is the case with other advanced-level backpackers, he uses a series of elaborate spreadsheets to plan his trips and was content with this method. He, althought not interested in the product himself, was happy to supply me with both his negative feedback and feedback from the perspective of his client base of less experienced hikers.
My biggest takeaway from this interview session was the insight into the pace in which people planned their trips. Because so much went into planning, it was not something that was done in one sitting. At the request of my client, the first iteration of the trip planner design was a single page. The cognitive load for the user was overwhelming. The feedback I received gave me the leverage I needed to finally convert my client to an updated architecture where each step was split out onto its own page.
I also talked with people who fell into both our target early adopters segment (experienced, ultralight backpackers) as well as the eventual majority user group we were aiming for -- "REI hikers" with less experience. This collective feedback helped me update the trip planning process so that the flow more natural and the priority level for each feature was more balanced.
The flow and nomenclature of the planning process did not match up to what users expected. I wound up reworking the process:
Each step of the trip planner became clearly grouped in a collection of pages. I added a side navigation bar to show the progress of each step and to allow the user to skip around to what they wanted to tackle during a single session.
I brought together the previously siloed gear (tent, boots, etc) and consumables (food, fuel, etc) inventories. I also de-prioritized advanced information for each. The original design was overly complex, difficult to navigate around, and gave priority to edge cases. The update emphasized a more normal use case: not forgetting what to pack for a trip.
Once a user completed the large and exciting task of planning their trip, the trip view page became the cohesive result that included even more valuable information than what they had manually entered. It was important for the value of the planning to be immediately clear to the end user. Additionally, it was downloadable into a simplified PDF format to print and carry in the field.
This was my first development handoff that did not involve a meeting or presentation. The communication culture of this team is written communication only - mainly through Slack and Trello. I learned that everything I did not explicitly record was missed. For things like error messaging, upload interactions, and photo cropping, I had to create detailed documentation. Moving forward, my documentation will be much more extensive and I will share the greater context using storytelling to make new projects more approachable to developers.
Now that I know user research was a scarce resource for my client, I would have done more of it upfront. This would have brought me to the conclusions regarding flow and nomenclature much earlier in the design process.
What I need to focus on next with this project is collaborative trip planning. As it stands, we have an ambiguous relationship between the trip creator and the tripmates invited to access the trip. I would like to create a clearer understanding of the way collaborative editing works. I would also like to expand features such as checklists, packing lists, and food planning to be better equipped for group planning.