In this case study, I have described my process of designing the ‘How to Reach’ flow for the ingo-MMT host app. The ‘How to Reach’ flow was designed to enable hosts to add property direction information easily and accurately. This information is reflected in the funnel products which in turn helps the visitors to find the way to their booked homestays. This is one of the projects that I worked on during my internship at MakeMyTrip.
Designing the ‘How to Reach Information’ Flow for the ingo-MMT host app
ingo-MMT (abbreviation for Inventory for GoIbibio & MakeMyTrip) host app is a new app built for homestay partners so that they can easily manage the rates, inventories, finances, etc. of their listed properties.
Homestays, most often do not have a grand appearance and are not popular like hotels. Moreover, a good percentage of homestays are located in remote locations. As a result of this, it becomes challenging to find the location of the homestays. In order to make it easier for visitors to find the location, it is required for the hosts to add the necessary information. The problem that was being focused on here was - how might we make it easier for hosts to add location direction information accurately and smoothly.
1. Hosts
→ Hosts are the users who own or maintain the homestays
→ Targeted users were people residing in India and mostly 30+ years of age
→ Do not have formal education in guest management
→ Familiar with using mobile applications
2. Visitors
→ Users who pay and stay in the homestays for a brief period of time
→ Not the primary target group. This user group is taken into consideration as the final outcome affects this group of users too
ingo-MMT (abbreviation for Inventory for GoIbibio & MakeMyTrip) team builds B2B products for hotel line of business. Some of the products are Hotels Extranet, Hotels Partner App, Host App, Contactless Check-in, etc. These products are used to maintain rates and inventories for both Goibibo and MakeMyTrip funnels.
With the increase in demand for homestays, there are many new users entering this space. Earlier, the hotel partner app was also used by hosts to manage their homestays. The problem lied with the fact that the hotel partner app has many advanced features necessary for their business that are not required for homestays.
Hence, the idea for the host app was developed. Host app would have features catered only for homestay partners.
I started out with some brainstorming to explore the problem we were trying to solve and gathered my initial thoughts around the problem. While the team was set on the idea to design ‘How to Reach Flow’, I wanted to explore some things we wanted to achieve from this system. The team and I discussed the goals we wanted to achieve from the system. Based on some of our design considerations and principles, we wanted a system that addresses:
Accuracy:
Enables hosts to add information quickly and accurately without adding to their cognitive load
Motivation:
Gives incentives to hosts for more qualitative and quantitative information
Confidence:
Gives hosts a sense of confidence about the information that they have entered
1. Accuracy
→ Easy Entry Point: Leveraging data, the popular destinations are shown by default along with CTA to add information instead of providing different destinations to choose from by default
→ Auto-suggestions: Many inputs in this flow require cognitive load such as the distance between places, commute time, etc. Based on pre-existing data sets, auto-suggesting these values leads to a smooth experience
2. Motivation
→ Improved Property Rating: Hosts enter this flow much later after onboarding their property. To motivate hosts to spend time and energy in adding all the information, they are incentivized by improving their property score. Having a good property score leads to more search appearance on the funnel.
→ Other incentives: Apart from improved property ratings, hosts are also given other incentives such as free or discounted price for promotions, star host programs, etc. The incentives are a means to motivate users to enter more detailed direction information for their properties.
3. Confidence
→ Quick Preview: To make users feel confident about the information they have entered, a preview is shown to them before they save the details. Also, on the L1 page, quick previews of all the entered information are visible. If hosts are not confident about particular route information, they can quickly modify it.
→Addressing edge cases: This flow has some unique edge cases. Many homestays are in remote locations due to which the location might not be available directly on the search engine and one has to place the pointer manually on the map. Moreover, there are sought-after destinations that cannot be categorized into stations or bus stops. Addressing such unique edge cases lessens the confusion and makes the hosts feel more confident about the information they are entering.
The information architecture was designed in a manner keeping in mind both - the first-time users and the returning users to this flow. Users enter this flow much later after onboarding their property. This was also taken into consideration while building the IA.
Following a couple of paper iterations, I had a general idea ready, so I switched to Figma, where it was easier to move things around. From the design team’s feedback on my wireframes, I was successfully able to create high-fidelity mocks using Figma.
a. Point of Entry
This feature has multiple entry points based on the use case. The primary point of entry is through the Listing Info in the property details section. Users can enter the flow from here anytime after listing their property on the platform.
b. Nearest Destinations
By default there is only one suggested destination for each of the cases in the how to reach flow to enable the users to enter the route information of at least one primary route. However, catering to the use case where multiple destinations can be present in the near vicinity, users can add more destinations from here.
c. Nearest Destinations - Filled State
Once the route informations are added, hosts can preview the route summary in the L1 and L2 page. They also get an option to add new route from the same location, and edit or delete route information.
d. Adding Direction Information
Hosts can enter this page either by clicking 'Add Directions' in the L1 page or in L2 page. Once here, they have the fields to enter route related information such as commute time, cost, medium, etc.
e. Adding Intermediary Steps
In the direction addition step, hosts can also add intermediary steps. This caters to the use case where visitors have to make multiple stops or change their medium of commute in order to reach the property location.
f. Manual Location Entry
Many listed properties are located in remote locations. To cater to the use case where locations are not available on search engine, hosts have the option to add the location manually in the flow.
g. Route Description
Once the route information has been added, hosts get a preview of the description. They also have the option to edit the description as per their requirement. Once published, these changes reflect in the funnel products after 1-2 hours of waiting period.
h. Other Destinations
Often there are popular destinations nearby the property which cannot be categorized into airport or railway station or bus stop, but are helpful for visitors to reach their booked property. The 'Others' section caters to that use case. To smoothen the flow, first time users directly get the location search engine to list the popular destination. Whereas, users from second time onwards get a preview of the already saved popular locations before getting the location search engine.
With the designs being made, the handoff was smooth. But not everything goes as planned always. Due to tech limitations, the idea for a timeline view of the route chart was discarded for the current build of the app. As a result, this particular section of the flow was redesigned to work in sync with the funnel products.
Having designed the entire flow for this feature, it was important to identify the metrics to track the performance of this feature. Some of the metrics that were identified to track the performance of this feature were:
→ Number of filled entries / Number of active properties
→ Number of detailed entries (multiple-step) / Number of active properties
→ Bounce Rate
→ Session Duration
→ Completion Rate
This project was a real-life project where I worked on designing and shipping a feature. I had a unique learning experience working on this project. Some major takeaways for me were:
→ If a good amount of data is present, it can be used to leverage the user experience of the product
→ A design system is never complete, it keeps growing along with the product
→ A feature that might look small and insignificant can also have great impact on the user experience