Disclaimer: This is a personal project. I was not commissioned by Indiahikes to design this app!

If you’re really short on time, you can watch the 2-minute video below which shows the major user flows and interactions! 😇

👉🏻 Project background

DIY Trekking is gaining popularity in India. More and more trekkers are taking to trails and mountains on their own, rather than booking experiences through commercial trek organisers. Apart from the cost savings, DIY trekking gives trekkers the flexibility to trek at their own pace, rather than adhering to fixed itineraries and hard stops.

As one of the pioneers in the Indian trekking landscape, Indiahikes (IH) has sensed this irreversible shift at a nascent stage, and realised that it can leverage its brand identity to take a first-mover advantage in this evolving market.

Currently, IH provides some basic services to DIY trekkers via a dedicated webpage on their website, wherein they rent out navigation kits (downloadable maps), camping & food kits to trekkers, charged on a per-day basis.

Project Duration: 3 weeks

Tools Used: Figma, Adobe Photoshop, Adobe Premier Pro, Google Forms

Disclaimer: This is a personal project. I was not commissioned by Indiahikes to design this app!

👉🏻 What’s the problem and the scope?

The existing process and user flow for booking DIY treks via IH is fairly limited in scope, complicated and non-scalable.

• The different sub-processes (exploring available DIY treks from IH website, navigation setup, managing rentals, coordinating with the local IH centre) is spread across multiple emails, web resources and POCs which is difficult to track and manage.

Here’s a sample snapshot of the processes involved:

This presents a huge opportunity for synchronising and simplifying existing piecemeal mechanisms into one integrated end-to-end ecosystem that acts as a reliable single touchpoint to the customer.

In addition, as a proposed one-app-for-all solution, there’s a need to identify the needs of DIY trekkers that aren’t addressed in the existing setup, and solve for them.

👉🏻 Business Goal

Building on its brand identity, IH plans to tap into this nascent (DIY trekking) market more effectively, and help create seamless, self-serve, end-to-end experiences for trekkers.

For this, it plans to launch a mobile app for DIY trekkers in India. In the long term, IH also expects to use the platform to bring in new customers into its traditional ecosystem (regular trekking batches), creating cross-marketing opportunities.

👉🏻 Project Objective

Create an end-to-end mobile experience for a DIY trekker in the Indian Himalayas which takes care of all aspects of the process from exploring treks to managing and completing them successfully.

• The app should consider the varying needs of trekkers while trekking on their own and how best to solve for them, while increasing the brand recall and loyalty of Indiahikes.
• It should integrate the existing (DIY trekking) services offered by IH.

👉🏻 Success Criteria

The following metrics can be used to evaluate the impact of the proposed app

• Satisfaction rating of app (Play Store)
• % of DIY trek bookings through app (as part of overall DIY bookings)
• Completion % of DIY trek bookings (as part of total initiated bookings)
• % change in customer service call requests

👉🏻 Assumptions & Constraints

1. It is technically feasible to integrate Google Maps API and offline GPS-navigation within the app, which includes waypoint alerts being triggered only by the GPS location (even if device is offline).
2. Proposed app has access to sync with user’s smartwatch via Bluetooth for sharing of physical stats (heart rate, SpO2, etc.)
3. Trails are periodically surveyed (by IH guides during non-DIY batches) and any material changes are updated in the backend database.
4. For sake of brevity, I have skipped standard UIs such as login screens, profile page etc.— these are expected to be similar to other apps.

👉🏻 User Research — Key findings & insights

The user journey map for the app would include the following broad steps:

As part of the initial user research, we collected inputs from 11 trekkers who have trekked DIY style or plan to do so in future. The inputs were collected via Google Forms and consolidated. We also conducted virtual interviews with 3 of the participants.

We identified some unique needs of DIY trekkers that the app needs to cater to.

1. DIY trekkers trek without a guide and have limited technical understanding of GPS navigation. They need an easy-to-use, self-serve & reliable map on their phone that requires minimal intervention.
2. The app should have ample offline functionality (such as offline download and navigation using maps) as trekking trails often have poor and unreliable network coverage.
3. Hiking trails are not as well-marked or self-evident as intra-city traffic routes, and even a small wrong turn can easily cause hours of delays. DIY trekkers need timely alerts on any route deviation(s). They also need nudges along the trail for waypoints (water-filling points, landslide zones, notable landmarks en route, etc).
4. Users need to see the day’s trek details (e.g. elevation gain/loss, time and distance remaining, etc.) to track progress. Showing their physical vitals (steps/distance/speed and health stats etc.) is a plus.
5. Nearest emergency support/help resource — availability, contact number and direction. Users also need a way to let their families and friends know their whereabouts, as an assurance of their safety and well-being.
6. Alert on changing weather forecasts in order to prepare better and alter plans, if required.
7. While organized commercial treks group individual trekkers into small batches, most DIY users find it hard to find trekking partners (unless they are travelling with friends). The app should provide a way for them to connect with like-minded souls they can plan their treks with.

The above user needs are broadly summarised in the image below:

👉🏻 User flows and Explorations

For this exercise, we focused on 3 critical user flows during the design ideation phase.

1. Scheduling a trek (including rentals, which is an existing offering)
2. Navigation (during a trek)
3. Using the community feature (aka Trekmate Lounge): Users should be able to post their plans/queries on the forum and respond to other users.

We explored multiple ways of performing the same tasks (along with some inspiration from apps having similar functionality) before coming up with the following proposed flows. Thereafter, we proceeded to evaluate the usability.

👉🏻 Usability testing and Design Changes

We tested the above user flows with 3 participants and identified few edge cases and usability concerns. To accommodate these, some changes were made to the existing designs which include

1. Option to add & sync additional members to existing booking
2. Showing the number of days on the rental UI and addition of a link containing the make and details (including images) of individual items.
3. Integration of notification icon within the navigation UI for direct access
4. Addition of an inactive state for SOS button.

These are represented in detail in the image below

👉🏻 Solution and interactive prototypes

After incorporating the above tweaks to the existing designs, we arrived at the final interactive mockups. Here’s the video of the same

In addition, we developed a complete flowchart of the app’s architecture (see below) to make it easier for stakeholders (primarily the engineering team) to understand and implement the app. It consolidates the primary UIs that establish the said user-flows: homepage and SRP, creating an activity & booking, managing rentals, navigation menu, emergency flow, etc.

The below flowchart is on a Miro board which can be accessed here.

👉🏻 What might a sequel involve?

Not everything is P0. And often we are short on real, operational feedback until the first version of a product is launched. If I had to re-work on a subsequent iteration of this app, here are a few things I would focus my energy on.

1. Expanded features for community, including some level of integration with other popular social media platforms.
2. Ability to record and create your own routes, add custom maps
3. Option to create customisable itinerary (where number of days can be defined by user)
4. Availability of individual/standalone products for rent (add-on)

And that brings us to a wrap of this case study. Thank you for your patience!😊

Enjoyed this post? If yes, please show some appreciation by clicking on the “clap” button. Fun trivia — you can hit it up to 50 times! It helps the content reach out to more like-minded people.

If you love my work and want to support my efforts, you can buy me a coffee with ko-fi. Thank you for your kindness and generosity!

Please share your thoughts and feedback in the comments below. This will help me improve and also inspire me to create more.

I try to publish regularly on Medium. Follow this account to receive similar content in future, and click here to get each post directly in your email. You can find me on Linkedin and Twitter as well.