UX Case Study 1
Booking a Visit
Native Mobile Apps (iOS, Android)
UX Design Skills
Information Architecture
Icon Design
UX Copywriting
Feature Prioritisation
User Flows
User Interface Design
End-to-end feature design
Cross-platform customisation
Context
When we started designing the booking flow, we had just launched the MVP of the Homage app where customers could view visits in their app. Back then, visits could only be created by Homage Operators acting as a concierge for our customers.
To launch more quickly, we had deliberately carved out the functionality for customers to book visits by themselves for a subsequent release. Hence, this flow would be a new feature addition into an existing app.
The flow would also be an experiment for us to learn about how customers preferred to book. Due to the nature of the caregiving service (needs-based, not usually a discretionary or recreational purchase), the vast majority of customers needed considerable guidance. The only way we could learn whether customers were comfortable to self-service on booking caregiving visits would be to give them exactly such a flow and iterate on top of it.
Goals
Launch self-service as a new channel of growth for the business
Improve the customer experience by giving users more control and immediacy
Gauge the comfort level of customers to self-service
My Role
I was the sole PM, UI/UX designer and QA tester on this project and I worked closely with a team of 4 engineers (1 iOS, 1 Android, 2 backend).
I reported to the CEO who was still overseeing Product matters at the time. For the UI/UX design, I started with paper sketching, then moved to low-fi wireframing and high-fidelity mockups.
Design Rationale & Thought Process
Placement of the flow
There was already one tab (bottom navigation section) of the app which allowed customers to book a Care Assessment. This is a face-to-face assessment performed by a nurse specialist that was required, before Homage could start visits with the customer. Hence, it was straightforward to put the visit booking flow on the same tab as well since it was a natural continuation of the customer’s journey.
Placing the flow on the Get Care tab would ensure the discoverability of this new feature.
That said, this tab was not the default screen upon launching the app. Top priority was given to the Visits tab (see above) - so that customers would always have an immediate view of the care visits that they had already scheduled. After all, 100% of customers would be interested to see their upcoming visits (or know that they have none). Only a much smaller fraction of customers would be interested to self-service and book more visits through the app, when there were alternative channels e.g. phone/WhatsApp available which they were more accustomed to.
Mental Models
Mental Model #1 - Cart Concept
The typical e-commerce mental model is a cart, where users browse through pre-defined items on offer, view the detail of each item, choose the desired quantity, aggregate various items into a basket or cart, then check out.
Homage’s approach was different mainly because it was a managed marketplace, where the company oversaw the matching process.
Caregivers are assigned by the company, and not chosen by the user directly from a list. Users would not be able to simply browse for caregivers as they did for e-commerce items and then check out.
Mental Model #2 - On-demand ride-sharing apps
I looked at other on-demand service marketplace booking sites like Uber, Grab, Lyft, ViaVan, Helpling. For ride-sharing apps, the call to action was immediate upon opening the app. For Homage, although the same sense of immediacy would be useful, the nature of the service demanded that users provide more information before submitting the booking.
Customer A’s visit requirements could be entirely different from customer B’s visit requirements, since the caregiving services were highly personalised to the care recipient’s needs (and physical environment, etc). Hence it would be counterproductive to show pre-defined visits since each person had such different needs.
Linear Flow versus Independent Sections
Should the flow be a linear flow or should the user be able to define requirements in any order? There were pros and cons to both approaches.
The biggest benefit of a linear flow would be its (theoretical) simplicity for the user to follow each step to completion. The biggest con would be the risk of frustration and drop-off if the user is not ready for the next step and there is no way to proceed or exit. Also, it would be annoying to go back and change information that I had entered on the first step.
I designed the booking request in 4 independent sections, which needed to be completed before the request could be submitted. I knew that users in the market for caregiving support tended to need guidance from Homage (even repeat customers would have questions), and hence wanted the design to be as upfront as possible about the information required. I believed it was still possible to guide the user to input their requirements a sequential manner by the visual layout of elements on the screen, Ultimately, the sequence itself was immaterial compared to the information itself. Moreover, users should have an easy way to edit their requirements (in case of any deliberate changes or unforeseen errors).
Once the basic flow was decided, I then experimented with the UI and copy.
Mandatory Information
How much information should be mandatory at this point? The more information we collected upfront, the easier it would be later on for our Operators to verify the request and also create the visit as a concierge. Conversely, the more information we collected, the more effortful it would be for our customers to input their requirements.
I decided to keep the amount of information collected to the bare minimum since this was an experiment anyway - start with a lightweight approach and build upon it as necessary as we learn more about the customer behaviour.
The most essential basic information that we had to make mandatory were Services, Date & Time and Location. These factors would affect the pricing of the visit as well as the shortlist of available caregivers who would be willing to take up the job.
In contrast, Special Instructions were important, especially from the caregiving delivery point of view, but I considered that a second-level input that we could input on the customer’s behalf during the concierge flow. In the majority of cases, our concierge Operators would expand on the free-text instructions and incorporate other inputs to inform the caregivers as well, so this fit in well with the existing workflow.
Also, I had already decided that the feature would have a number of independent sections instead of having to follow a linear flow. In terms of information hierarchy, the Special Instructions would be the last section (least important). Since mobile device sizes varied greatly, this design would try to keep all the mandatory sections (Services, Date & Time, Location) “above the fold” and visible at first glance on the page. If the customer happened to miss the ‘Special Instructions’ altogether, that was a risk I was willing to take since the information was not critical at the point of submission.
Drafts, Autosave (Information retention)
How should the app handle inputs? There were a couple of options:
Autosave upon any edit
Save only upon user’s action
From the customer’s perspective, it seemed more convenient to have all my inputs saved automatically, which was the original design proposal. However, after some discussion and quick testing, I realised that this would be confusing as the user would not have explicit confirmation of their selections, going ‘Back’ immediately may even seem like reverting to the blank state. In the next iteration, I included a large “Save” call to action at the bottom of the screen so that the user could get the feedback that they have completed the selection, which then took her back to the main screen.
What about retaining inputs after completing the flow?
Conversely, from a technical and design perspective, we wanted to keep the feature as a lightweight MVP, and knew that dealing with drafts and versioning and the associated user flows would bloat the feature when it was not a core part of the self-service visit booking functionality.
There were a number of use cases to consider here, e.g. for totally new user, an existing user mid-flow, a repeat app power user returning to make a second or subsequent booking; but of course we would not be able to optimise for all of these users. Hence, we kept the design simple, to retain and populate the customer’s last inputs for Location (since most visits were at the customer’s home and that wouldn’t change often at all).
Date & Time would necessarily be cleared after each booking as I had studied customers’ booking patterns - they tended not to have multiple visits on the same day (although that was possible).
Here’s a very early working draft of the Services selection menu.
I would substitute the placeholder icons out later and standardise the style! Note how some are fill icons and others are line icons.
Date & Time Selection
In the very first iteration of the design, date and time requirements were input via free text entry. This was a conscious decision for a faster MVP launch. However, free text entry was sub-optimal - since there was no guidance about the information we required, users ran the risk of omitting important information like the end time in addition to the start time.
One of the challenges I faced in the design was the calendar UI. Each visit needed three pieces of information: date, start time and end time. Based on our existing data, I wanted to cater for the following use cases:
single date & time (most common)
combinations of multiple dates but same time (also common)
combinations of multiple dates and times
regularly recurring visits e.g. every Monday
Originally, the simplest design was a bare bones form for date, start time, and end time as three dropdown fields. However, that was effort-intensive as it would force the user to scroll down through many different values for dates and times in the respective pickers. There was no way to combine steps as each date and time was necessarily selected individually, even if some of the timings were the same. I felt that the UX was poor and there were better alternatives.
I decided to show the calendar view upfront so that users could select dates visually, then select their desired start and end times and click the “Add Visit(s)” button to capture their inputs. The selected dates and times would be captured in a list and the viewport (visible area of the screen) would scroll down to the bottom of the screen to show the newly added dates. This process could be repeated as many times as required.
With this design, although it was certainly not foolproof, I was able to support the two main use cases.
From my working file for the iterated design of the calendar input. This was much more structured and robust!
End-to-end Feature Design
This was an app feature but as part of the end-to-end user experience, I also designed an email notification so that users could get feedback that they had successfully completed the flow.
The email notification summarised the inputs submitted by the user in the app flow, and reiterated the next steps. The email was a more permanent artifact that the user could refer to at any time, as opposed to the post-submission confirmation screen in the app which would be refreshed upon the next app session.
Launch
We launched the flow with a suite of product marketing efforts (EDM with video, App Store description and video preview updates). We also built it into our sales workflow, so that our customer service advisors would mention the new app feature over the phone during callbacks to the customers.As both the product manager and the designer on this feature, I know that design is a key component, and so is the last mile of how the feature goes to market. How we sell a feature is everything!
A quick walkthrough on how to request care via the Homage Mobile App.
Launch Video
Here’s the video I created and edited for the launch.
It was created in a day with Screenflow software.
Outcome
Once the feature was launched, we began to receive visit booking requests via the self-service feature! While the uptake was encouraging, it was still a relatively small proportion of the overall bookings - a handful per day at the start. It was within the range that we expected given what we knew about customer booking patterns and tendencies to require one-to-one guidance.
The uptake eventually rose to around 10% of total incoming bookings.
Learnings
Learning #1: Always provide visibility of system status
In the design, once the user submitted their request, they were shown a confirmation screen. This was intended to reassure users and signpost the next steps (i.e. to hold on until Homage calls them back).
Despite the confirmation, we received feedback from customers that they were not sure whether their requests had gone through successfully, because the feedback within the app was limited to the confirmation screen. After users had submitted their requests, there was typically a time lag of anything from a few hours to a day before their self-service request was “converted” into an actual visit in their app. During this time, their request was not self-evident.
The email notification that we sent upon successful submission was insufficient as there was a chance that users would not even check their email.
My learning was that visibility of system status is incredibly important to clearly manage the user’s expectations. Any self-service flow has to provide clear user feedback and be transparent about the next steps, in order to be effective and pleasurable. In a later iteration of this flow, we would indeed provide instant feedback to the customer about their visits.
Learning #2: Prioritisation
In hindsight, I’m really glad that we were able to keep the initial design lightweight, even though it is certainly a design that can be improved in multiple ways.
Reid Hoffman famously said “If you are not embarrassed by the first version of your product, you’ve launched too late.” (This always makes me feel better! Although it is definitely not a justification to launch anything without proper thought beforehand.)
Because of the tradeoffs we made in design and also the scope of the feature, we were able to prioritise much more important aspects of the Homage product, like an end-to-end pricing engine and also an entirely different app to cater to care organisations. In essence we did not over-bet on this experiment, and that enabled my product team to keep moving forward at a good pace.
Learning #3: Platform Differences
To save time and launch more quickly, as the sole designer in a seed-stage startup, I would typically do one set of mobile designs and then adjust as necessary for iOS and Android. I relied on the mobile engineers’ inputs and expertise and we would often decide on an approach together after I came up with the general cross-platform design.
For the visit booking flow, one sticking point in the original design was the use of chevrons or arrows on the right of each section of the mobile app. This was a UI design pattern that belonged to iOS rather than Material Design (Android). Later on, when we were fine-tuning the app design for each platform, we removed the chevrons from the Android app but retained them on the iOS app.
I would go on to consider various platform differences in other features as well, e.g. the placement of the title and “Back” arrows at the top of the screen, the way that side drawer menus would overlap with screen content (Android) or push it offscreen to the right (iOS), and so on. These fine details do evolve and they keep a designer on her toes!