Hiking Buddies

Redesigning an outdoor experience platform

It’s not often that we get to shape the tools we use, so when I had the chance to contribute to an outdoor experience platform that I myself was also using, I was quick to jump on the opportunity so I reached out to the team behind it with the proposal for a collaboration.

Background

As a hiker and mountain biker, I need a reliable and easy to use tool to plan my next outdoor adventure. That may sound like the definition of a user story, but it’s actually true because I have yet to find a single platform that does it all, so instead I always end up using one or more of these:

Useful as they may be, they each still have their own quirks and neither one gives you the possibility to plan an outdoor event and allow other people to join. That’s actually where Hiking Buddies comes in, because the platform itself was built entirely around the idea of getting people together for hikes and helping them keep track of their hiking history, as mentioned on their website:

We are group of individuals from Munich who are hiking enthusiasts. We started with the idea of having a platform that can be used to organize hiking events and track one’s own progress. The goal is to explore the beautiful mountains, meet new people, and challenge yourself.”

The challenge though was ensuring that these events were organized in a safe and reliable way by responsible people. Those that were organizing the events needed to somehow prove their experience, while participants themselves also had to prove that they were capable of joining others’ events. Hiking Buddies solved this very nicely with a user ranking system that took into account how many hikes a person attended, how difficult those hikes were and most importantly what others had to say about them as a hiking buddy.

Having attended a few of their hikes myself, I got a first-hand experience of how it’s like to use the platform and, functional as it may have been, it did have its share of shortcomings when it came to user experience and design conventions. Having been designing websites and apps myself for awhile I’m used to spotting usability problems in the tools I use, but it’s not often that I also have the opportunity to propose solutions, so in this case I just reached out to the team and offered my support with improving their user experience.

Follow The Data

There were a number of improvements that the platform could have used overall, some of which were easily solvable via visual redesign, while others ran a bit deeper and probably needed more investigative work (e.g. information architecture, findability, deep linking etc.).

Since we had to start somewhere, in my early discussions with the team I asked if they had any kind of usage statistics that might help inform this decision, and luckily they were already using Google Analytics for quite awhile.

The data they had gathered showed me that users spent most of their time on the event and route pages, which was to be expected given the purpose of the platform. In terms of devices, the top 5 screen sizes were dominated by smartphones (38%) whereas desktops came in at roughly half that amount of traffic (19%), though desktop users did have on average 5x longer sessions than mobile users. Considering that mobile devices are more likely to be used on-the-go whereas desktop devices are more used in the planning stages of an event, that data made sense, and it gave me some direction towards a starting point: the event details page for desktop.

The Event Page

Apart from some generic visual design improvements that were required on the top navigation and footer, the page itself already had plenty of useful content that just needed to be reviewed and reorganized in a consistent and easy to find way.

Event page: Original layout and design live on website

I started by doing a breakdown of the current content, regrouping and remapping it to a new structure and filling in the missing pieces like extra information or useful features.

Content breakdown: Listing out all the parts that make up an event

Despite having the most popular of all pages, events were strongly linked to routes because all events were ultimately based on the route that the group would follow. In other words, people could go on the same hiking trail any number of times, and every time they did so it counted as an event.

Route-Event: A route can be used for multiple events in a 1:n relationship

This meant that we could pull some relevant information from the route and already display it on the event page, while still allowing users to open up the standalone route page for full details.

Content Hierarchy

After going through what was already there and what could be added, I ended up with a few sections that could be used as building blocks for the overall page:

  1. Event overview: date, time, meeting spot, weather forecast, organizer, free spots
  2. Route overview: elevation profile, terrain type, map
  3. Event details: description, instructions
  4. Route details: ascent, descent, distance, duration
  5. Participants: organizer, users, waitlist
  6. Gallery: thumbnail previews
  7. Comments: nested conversations

Wireframing

Because form follows function, I used the above content structure as a basis for a first wireframe draft just so that I could have something more palpable on paper (my medium of choice for this stage of the process because it’s fast and easy).

Wireframe: First draft for mapping out the different sections

This already helped put things into perspective and allowed me to step back from my idea for a few days and approach it later with a fresh pair of eyes. As is usually the case, this exercise helped me spot things that I had missed as well as things that could have been restructured:

  • Elevation profile: The narrow width would’ve given a sense of false steepness, while details such as terrain type would’ve been difficult to tell apart.
  • Join button: Should’ve shown how many spots there were left, or change its state for events that were fully booked or have already passed.

I then iterated with a more high fidelity wireframe, still on paper but including the above changes as well as some missing content like the participant list and comments.

Wireframe: Going into more detail for the content

By going into more detail with this second wireframe I could already get a better idea of what the final page would look like, and this was something I could bring to the table with the rest of the team before moving forward with a high-fidelity mockup.

Visual Design

Having received the green light from the team, I moved forward with a high-fidelity mockup of this page that would incorporate some of their feedback as well as some of my own notes from the last wireframe:

  • Calendar icon: The organizer’s avatar wasn’t as important as the event date, so that was swapped for a stylized calendar to make the date more prominent.
  • Meeting spot map: The Google Maps integration with the exact location was removed because it clashed with the route map underneath and would’ve slowed down page load.
  • Add to calendar: Much like with Google Maps, we could have also avoided a slow calendar API call if instead we just dynamically built a special link for this button.
  • Weather forecast: One of the most important aspects of any outdoor activity, this was bumped up and added to the header, along with the very important UV index.
  • Participant experience: Initially proposed as a worded level (e.g. Beginner, Avanced etc.) it was easier to keep the existing point-based ranking in the participant list.

Event page: Visual design concept for desktop

Since this was the first page to be redesigned in the entire platform, it was a good opportunity to also establish some conventions that could be included in a design system and later adopted by other pages to achieve platform consistency and a seamless user experience:

  • Typography: An easy to read slab serif like Aleo by Alessio Laiso, supporting a variety of styles and distributed via Google Fonts under an an Open Font License.
  • Color: Black copy on a white surface for good readability, with a turquoise primary color as a tie-in to the color of glacier lakes that are found deep in the Alps.
  • Icons: They had to support the content without distracting from it, so thin lines seemed like the appropriate style to use across all icons.

Event Life Cycle

With each event having its own life-cycle, there were different interactions that users and non-users alike could perform at different stages. Normally personas and user story mapping would have been helpful to understand this user journey, but since I could only spend at most a few hours per week on this project I took a shortcut in the form of a simple interaction timeline:

Event life cycle: Stages of an event after it's been published

Handling the sections of this page at different stages of an event was the next challenge on my list, with the “Join event” button being first in line. This button had to change its content and style depending on where in the timeline the event was in:

  • Upcoming (Open): Show number of free spots, and allow people to join.
  • Upcoming (Full): Show that there are no more spots left, but allow people to join the waitlist.
  • Ongoing: Show that this is happening right now, but disable any interactions.
  • Past: Show that the event is over, but allow people to schedule a new one.

Event button: Changes label depending on state of event

Workflow & Outcome

As both a designer and an outdoor enthusiast myself, this was an exciting project to work on but unfortunately it was also excitement that got the better of me. Holding down a full-time job as a Product Designer, while already having other personal projects in parallel meant that I didn’t have enough bandwidth to also fit Hiking Buddies into my schedule to the extent that was expected of me, and ultimately that led to us parting ways.

Future Improvements

Had our collaboration continued I would have likely focused on some of the following improvements to the event page, before shifting my focus to other areas of the platform:

  • Difficulty level: The commonly used easy/medium/difficult levels were helpful, but a more precise levelling would have been to display the SAC scale of the route.
  • Similar events: Much like related posts on a blog or similar products in an online shop, other events could have been deep linked at the end based on some criteria.
  • Terrain legend: The elevation profile already showed the differnt terrain types but it didn’t have a legend to show what each color meant (e.g. gravel, trail, asphalt).
  • Huts: Usually mentioned in the event description, it would have been more user friendly were they listed in a dedicated section or maybe even in the elevation profile.
  • Export options: Phone signal is unreliable in the outdoors, so the route should have been exportable as GPX for offline use, while the event and participants could have been printed as a PDF booklet.
  • Best season: Would’ve been useful to highlight the months of the year when a route is crossable, so that participants knew what to expect.
  • Navigation bar: Clicking on the search icon would have expanded it into a search box that gained keyboard focus and covered the rest of the menu to its left. The user icon would have been replaced by an actual avatar and clicking on it would have opened a dropdown menu with a larger avatar, full name, rank and then two links to their profile and to sign out.

Conclusion

It’s been a project with plenty of learnings for me, and despite the brief time that I spent on it, I’m still confident that the Hiking Buddies platform has what it takes to become an excellent and reliable tool for bringing outdoor enthusiasts together, and I wish the team all the best in bringing it there.