UX Case Study 2
Applying for a Caregiving Job
Native Mobile Apps (iOS, Android)
UX Design Skills
Information Architecture
User Research
UX Copywriting
Usability Testing
User Flows
User Interface Design
End-to-end feature design
Cross-platform customisation
Context
Homage is a 2-sided managed marketplace where customers can get on-demand caregiving support, and caregivers can earn a flexible income.
In the earliest version of the product, caregivers would receive jobs that were offered to them personally by internal Homage Operators. However, since the manual effort was not scalable, we wanted to move to a model where caregivers proactively browse through jobs on the app and apply of their own accord.
In this new model, a caregiver would be able to browse through jobs through the Care Pro app. The list of open jobs would be personalised for the caregiver based on a range of different factors, including location, caregiving skills and competencies, schedule availability and others. The caregiver has constant access to this open and updated directory of opportunities.
If there is a suitable caregiving job that the caregiver is interested in, the onus is on her to apply, and she can apply for as many jobs as she likes. Across the entire marketplace, multiple caregivers might apply for the same job, but eventually only one caregiver among all the applicants would be assigned by Homage.
Goals
The overarching objective was to speed up the fulfilment process of assigning a caregiver to a visit, by removing bottlenecks where Operations would manually offer visits to caregivers.
Furthermore, we wanted to help caregivers get more jobs, and have more choice and control over the kinds of jobs that they took up.
My Role
I was the sole PM, UI/UX designer and QA tester on this feature and I worked closely with a team of 5 engineers (3 backend, 2 mobile). I reported to the CPO for this project.
For the UI/UX design, I started with paper sketching, then moved to low-fi wire framing and high-fidelity mockups. I also built an interactive prototype using Invision for usability testing with caregivers before the launch.
Design Rationale & Thought Process
Information hierarchy & prioritisation
This feature would open up a long list of visits to caregivers, who would then essentially cherry-pick their preferred visits to apply to. How could the design make it enjoyable (or at the very least, easy) for caregivers to browse through visits?
Each caregiver could easily be matched with tens or even hundreds of visits, which would have been impossible to showcase on one screen. Hence, I designed a flow in two steps, where the decision-making process was broken down.
The first step would be essentially the Inbox: a long list at a high-level, prioritising breadth. Even on this first step, key information would be available to help caregivers decide: do I want to find out more from this preview?
The second step would be the visit at a granular level, enabling the user to go deep into individual visits instead. Only from the second step would it be possible for users to decide: do I want to apply for this visit to potentially take up the job?
Mental Model - Grouping visits into “cases”
I had heard various caregivers mentioning “my Aljunied case” or “the Bukit Batok senior”. They conceived of caregiving in units of “cases”, anchored on the individual care recipient or customer.
Organising the visits by individual was thus a reasonable starting point that wouldn’t be difficult for the users to follow in the new app design. Hence, I came up with a design where the long list would be organised by customer, and then by dates in chronological order.
For the visual interface design, I provisioned an entire line for the customer’s name, in case the customer had a lengthy name.
Location - potential red flag
The design would also identify the location of the customer, since location was a key factor in caregivers’ considerations. As freelancers, it was only natural to want to limit their travelling time since time spent travelling could be time spent working instead. A visit location that was deemed too far from a caregiver’s workplace or home would typically be a dealbreaker or big red flag. The design provisioned a line to showcase the street name of the visit location and the approximate zone. This would help caregivers understand the location of the visits without having to leave the app, and look it up in Google Maps instead.
Volume of work available
With the visits organised by customer, it would be easy to see how many cases were open for each customer. This would also help caregivers to estimate their potential level of engagement with this customer given their schedule, and help them decide if they wanted to apply. In my design, visits were listed chronologically so that caregivers would see the earliest visits first. It was evidently in the company’s interest to drive applications to these visits first, since since time was running out to fulfil these visits with a caregiver and there was a risk of losing business. Hence, putting them at the top of the list was the logical design decision.
Granular details of each visit
Caregivers wanted to know the key visit requirements before feeling comfortable about applying. Putting myself in their shoes, I could completely empathise - as a caregiver I would want to know the expectations and requirements as transparently as possible. After all, I wouldn’t waste my time applying to a visit that I wasn’t well-equipped or comfortable to perform. The transparency was also Homage’s way of differentiating the company and helping caregivers feel empowered and in control. We wanted to give caregivers the flexibility and choice.
For each individual visit, the information could be grouped as follows:
Date and time
Location
Payout amount
Services required by the customer
Gender of the customer
Weight and mobility of the customer (directly proportional to the amount of physical effort required from the caregiver)
Instructions in free text (greater detail around the expectations for each visit)
Given the deluge of data, I designed a series of icons as a quick visual signpost of each section. This helped the user to scan through the page and quickly find the information that they want to see.
The tradeoff of having a column of icons was that only about 60% of the screen real estate could be used for text . If the free-text instructions were lengthy, this would make an already long page even longer. However, this was a risk I was willing to take since 100% of visits would have all the sections, but only a small proportion of visits would have really long instructions.
Show me the money 💰 - how much priority should the payout breakdown receive?
While designing, I had a great discussion with my CEO about the placement of the payout on the page. Most of the caregivers I had interacted with had confirmed that payout was an important consideration, if not the most important consideration. If it was so important, my thinking was, why not put it right at the top and save the caregiver some effort in scrolling around looking for it? Or even display some indication of the payout range in the Inbox (top-level) page? Wouldn’t this be a great way to improve efficiency of the caregiver in browsing through jobs?
It turns out, we eventually went with placing the payout at the very bottom of the page because of two reasons.
1) We wanted caregivers to anchor their impression of the visit on the person receiving care, hence the redacted personal information should have pride of place. This person-centrism was fundamental to Homage’s values around care quality (and still resonates strongly with me today!). It’s not that the payout was not important, instead, it’s just that the emphasis on the human being was much more important :)
2) If caregivers were almost certainly going to make a point to see the payout, then we should put it at the bottom of the screen so that they can view all the other details “on the way down”. We might not be able to prevent users from speed-scrolling and overlooking the other details, but this pattern at least gave the other details a fighting chance. Had we placed the payout information at the top, then all the more the caregivers might completely ignore the other details of the visit and bounced from this page immediately.
My takeaway was that there is no guaranteed way to control actual user behaviour, but the design pattern should always optimise the path for the desired behaviour.
This was one instance where as a designer I listened and gladly bought into a logic that I hadn’t initially seen. Indeed, I was happy to find ways to emphasise the payout information that was so key to our caregivers, namely, going into a line-by-line breakdown, using a background colour and larger font size to emphasise the grand total.
Search and filter
Risk of cognitive overload
Given what we knew about our typical demand patterns from customers, and our caregivers’ profiles, we expected each caregiver to easily have up to 40-200 visits each that they could browse through. It would quickly become an onerous experience to look through 200 visits as users would have to click into the visit, scroll down, go back to the inbox, and repeat for each visit.
This classic case of cognitive overload would lead to frustrated caregivers, drop-off, lost business and worst of all: seniors not receiving the care they needed.
Hence, I designed a “Minimum Viable Product” version of search and filter functionality for the caregivers’ inbox. We wanted to design and build just enough functionality on a single filter page, to allow caregivers to narrow down the visits that they went into at a deeper level. The plan was to first launch some rudimentary filters and then learn more about how caregivers took to them, before iterating them with better functionality.
Text search
Since we wanted to keep the filter very lightweight and the main event was to get caregivers applying, the filter design was deliberately simple. The first part was a text search that was intended to find matches among any matching text fields, including:
customer name (the abbreviated version e.g. Mdm S Tan)
address (searching the street name)
zone
service types (e.g. medication administration)
Having a free-text search was not foolproof or the easiest to use; typing could be annoying on a mobile device and there is always the risk of typos. Nevertheless, I went with a free text search in view of the flexibility as several different fields could be searched with a single search. To save space (and keep the date filter ‘above the fold’ as well) I relied on example placeholder text instead of adding a line of helper text. “Type something, e.g. east, medication”.
However, in hindsight, this was a bit vague and confused caregivers whether they could type in just a single search term or multiple. More guidance or structure around what users could type to search might have been more helpful, and also prevented users from typing in unsupported search terms which led to no results.
Other options could have been a list of dropdown values for each field e.g. zone, services, or selector buttons to show all the possible values upfront, combined with expand/collapse accordions.
Date filters
An obvious filter that was really helpful to caregivers was the date filter, across a multitude of use cases:
Caregivers might be looking for visits on specific dates if their shifts freed up;
They might be only available on weekends generally,
specific patterns e.g. Mondays, Wednesdays and Fridays, etc
Direct manipulation
In the design, I thought a calendar would be an intuitive and robust design pattern which would be able to support the various use cases through direct manipulation. Users could simply tap the dates that they are interested in. Past dates would be irrelevant and disabled.
Shortcuts and feedback on non-visible elements
In addition, I added two shortcut buttons to allow caregivers to quickly select the next 2 days and next week’s visits in one tap, saving 1 to 6 taps and also prioritising the visits which are about to happen. The calendar would respond by ‘lighting up’ the selected dates. Since the calendar could only show one month’s worth of dates at a time, I also added a feedback element below the calendar in text, to tell the user which dates she had selected. This would be helpful if the selected dates ran into the next month and were not visible on the current month’s view.
Buttons versus toggles
When I showed my design to the mobile engineers, they were rightly concerned about the micro-interactions of the shortcuts. They wondered if the shortcuts would trigger each other and if they could be reversed. E.g. if I had already tapped “Next 7 days” and those dates were highlighted on the calendar, would “Next 2 days” automatically be selected as well? If so, if I then tapped “Next 2 days”, would the next 2 days be ‘subtracted’ on the calendar in reverse?
In that discussion, I realised that the developers were thinking of the shortcut buttons as toggles which would be enabled. To simplify, I decided that the shortcut buttons would function as one-way inputs only, they were not toggles per se and would not have persistent selected states after being tapped. This allayed their concerns.
And / Or Search Behaviour
One interesting thing to consider as a designer was the behaviour of how multiple search terms would interact. Should the search be an ‘AND’ search which would make the criteria harder to fulfil and narrow down the visits more quickly?
We eventually went with an ‘AND’ search across date and text, but ‘OR’ within dates. For example, if I searched for “east” and Apr 28, 29, 30: any visit happening in the east at any time between Apr 28-30 would be returned.
The ‘and/or’ search question resurfaced when I was designing filters on large amounts of data,, such as in the enterprise web app.
Submitting the filters
After either the text search or the dates were selected, the user could then tap the main “Search” CTA at the bottom of the screen to return to the Inbox. It made sense to combine the submission of both search criteria in the same CTA, since the results would not be visible until returning to the Inbox anyway. (If the search results had been visible immediately, e.g. an autocomplete flow, then it might make more sense to have the search term auto-submitted upon the user entering 4 characters, for example.)
On the Inbox, the list of visits open for application would narrow down according to the search criteria. The design provisioned space to show the user the filters they had selected, so they could adjust their search accordingly.
It would have been nice to be able to remove search terms individually, e.g. clear “Apr 28” date filter but leave the “East” alone, but this was eventually parked for a later iteration. The design thus included an overall ‘Clear’ functionality to remove all search terms and revert to the full Inbox.
Empty state pages
I also designed an empty state page in case the search did not return any matching visits. If this happened, the caregiver might be understandably disappointed, annoyed, or worse, discouraged from continuing. Hence, I drafted very brief copy on this page that was action-oriented (“Try again with different search criteria”).
I had considered other alternatives like “Sorry! Thanks for looking, try again…” etc but decided to keep it very specific and neutral in tone at this time since the user already had a high intention to browse visits and I did not want to risk annoying her any further.
The empty state screens for the other sections were similarly action-oriented with clear copy and CTA button.
Here’s the video I created and edited (in less than a day) to help caregivers understand the new flow.
Usability Testing with caregivers
Launch
I did about 7 iterations of the design and it went into build. Since it was a big behavioural change that we required from the caregiver population, we tried to socialise the changes early on and often. I prepared the visual communications materials for the various efforts, including:
in-person usability testing sessions with caregivers before the launch
feature-specific drip email campaigns before and after the launch, with videos and cheat sheet attachments to guide users
an in-person preview presentation to a select group of caregivers
personal communications between the Operations team and the caregivers via WhatsApp (since their standard workflows brought the Operations team into close contact with caregivers about visits every day)
In addition, the launch of the mobile app features had to synchronise exactly with the launch of new flows on the enterprise web app as well. It was a big effort from the entire team but it went quite smoothly.
Outcome
After launch, adoption took a few weeks to get to the full 100%. This was mostly because in view of the upcoming sea change, all the visits that we could assign to caregivers before the transition were handled on the old flow. However, over time, adoption rose to 100% and today it remains at that level.
Learnings
In the weeks immediately after the launch, I did a series of calls with about 15 caregivers of different profiles and engagement patterns to understand their reception of the feature. Here are some of the learnings from those calls and subsequent interactions with caregivers, as well as internal retrospectives with the engineering and Operations teams.
Learning #1: Pagination for large volumes of data
Loading times on the Inbox were significant as caregivers might be invited for up to hundreds of visits. In order to keep the performance of the Inbox page snappy, we decided to paginate and only load the first 50 visits. After all, performance can make or break the usability of a design.
We subsequently added a ‘scroll down to load more’ action when the viewport hits the bottom of the screen, and a ‘swipe to refresh’ action when the user scrolls up at the top of the page.
Learning #2: Retention of last scroll position
The most significant usability issue that surfaced after the feature was released, was that the user’s scroll position in the Inbox was lost after going into the second-level page containing a specific visit’s details. When they returned from the granular page to the high-level Inbox, they would have to start at the top of the Inbox again.
This was understandably distressing as the list might be long with many similar visits. Although in the Inbox, akin to an email inbox, the design differentiated between visits which were untouched (in bold) versus those which had already been viewed (regular font weight), this was not the same as bringing the user back to exactly where they went deeper into a visit’s details. A user might have stopped at a point, without going into the details.
Ideally, caregivers should be able to resume from where they left off, with clear visibility of their progress through the Inbox. In a subsequent release, we added retention of the scroll progress down the page.
Learning #3: Discoverability
Filters
The Care Pro app did not contain onboarding screens (e.g. with lightbox overlays and arrows to point out elements on screen), that was not the design approach that we went with initially (because even in 2017/2018 it felt a little dated). As a result, certain features which were not immediately visible or evident might be completely overlooked by users.
One example where discoverability was sub-optimal was the filters. The entry point to access them was the magnifying glass icon in the top right hand corner of the screen. Definitely not the most obvious location especially if a user is excited to get into that long list in the Inbox right away.
In a subsequent redesign of the filters, we placed them below the tabs of Inbox, Applied and Archived instead so that they were more visible and could be direct manipulated. This helped to bring up the usage of the filters to over 30% of active users.
Swipe Gesture
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!
Learning #4: Scannability of long lists
The Inbox could be a very long list and I wanted it to be as user-friendly as possible. I thought one way of doing that would be to align the days, dates and times of each visit into separate columns. Although the various elements were aligned in the design, this was not implemented due to technical complexity.
The learning from this is that I could do a better job of scoping the feasibility of this by consulting with the mobile engineers and backend team ahead of time. With better communication we might have been able to structure the API in a way that facilitated showing the various columns with discrete alignment.
Future areas of exploration
Since the original iteration of the Apply feature as detailed above, we worked on a number of exciting enhancements to improve the caregiver experience!
Visual differentiation of customer types on the Inbox
Count of visits per customer on the Inbox
Expand/collapse interactions on the Inbox page (an alternative to swiping to decline)
Colourful “New!” indicators to help caregivers zoom in to the visits which had been added since the last time they checked the app
Additional filter functionality with improved placement of the entry point
Richer information in the Visit Details to help caregivers make the decision about applying: medical conditions, pets, more details around mobility
On the whole, I’m really grateful to have had the chance to work on this fascinating feature. I learned a whole bunch, and hope the team continues to bring a great user experience to Homage caregivers.