The Startup
Published in

The Startup

Designing a rideshare app that empowers older adults (Act II)

Case study of the UX design process

Read more about this project:

(Act I) The UX research process
(Act III) The UI design process


Project nature

Springboard’s UX Career Track program capstone project (individual effort)

My role

Information architect, user experience designer, user researcher (usability evaluation)


Two months


Sketch, Adobe InDesign+Illustrator, POP by Marvel, Invision, pen and paper

The challenge

For my UX capstone project, I decided to design a rideshare app that helps otherwise-homebound older adults connect with younger, retired individuals who can offer them concierge driving services, to empower them to maintain more active and socially connected lifestyles. The next step is to flesh out the concept and create a working prototype of what that looks like.

The biggest challenge for the project is to figure out how to integrate a sophisticated booking system seamlessly with the communication system, so that users with a wide range of technical proficiencies, mental models, and cognitive capabilities are able to successfully use the service.

The solution

In order to design a product was intuitive enough for caregivers and drivers to understand and navigate, I undertook the following process:

  • Kick-started the design phase by roughly plotting out the information architecture of the MVP of both the drivers’ and the riders’ apps in the form of sitemaps and user flows.
  • Implemented an iterative design process to the development of clickable prototypes from low- to high-fidelity.
  • Performed in-person moderated usability tests regularly to evaluate, refine, and optimize usability for the target users.

The outcome

  • Two high-fidelity prototypes of the drivers’ and riders’ app with fully refined red-route experiences.
  • Raised the user satisfaction rate from 0%–75% between the last two rounds of usability testing.

Read on for the details.

Deciding what to design

User stories

The Minimum Viable Product (MVP) consists of two apps, one for the rider, and one for the driver. (To read more about the three personas, please check out the case study of the user research phase.)

The older adult may use the riders’ app independently; or alternatively, s/he may share a joint account with his or her caregiver, who can provide various levels of assistance when required.

In this case study, persona John would depend on Ann, his daughter-in-law, to help him coordinate rides with Rebecca the driver. He can directly call Rebecca to book his journeys too if he so wishes.


Different interaction dynamics that might arise between the three parties—the older adult rider, the caregiver, and the driver. Therefore, the service should enable different methods of communication between the driver and the rider’s party (older adult and caregiver). The possible scenarios are illustrated below:

The product has to accommodate different interaction dynamics that might arise between the three parties

The initial prototype takes into account the following methods:

  1. By (smart/dumb) phone: the analog method of contacting the driver, which empowers older adults with low technological proficiency to coordinate rides without extra help. (Downside: no guarantee of being able to get hold of the driver immediately.)
  2. By in-app chat: helpful in situations where users are unable to reach the driver through the phone. From my user research, those who are able to operate smartphones often prefer it. (Downside: takes more time to communicate)
  3. By in-app form: the fastest, most efficient means of contact. It would assign an available driver from the system immediately. (Downside: lesser human contact/may be harder to navigate for some users depending on their technological proficiency.)
Each method of communication comes with a set of pros and cons

Design scope

While the entire functional scope of the app would necessarily involve the whole experiential sequence from user onboarding to executing the trip, for this exercise, I only focus on developing the following red routes, as they present the most complex, non-linear, and unique aspects of this product:

Red routes which I focus on for this design investigation

Information Architecture

Design objectives

  • To facilitate, aid, and mimic real-life interactions
  • The rider should receive the most friendly, concierge service.
  • The driver should also find the complex functional navigations to be seamless and frictionless while they help administer the booking.


To start planning the way the screens are functionally categorized, connected, and hierarchically arranged, I drafted two sitemaps for each respective app.

To provide the older adult user with a less-cluttered interface, I considered placing the main functions on the highly visible areas of the landing page, displayed as a sequence of instructional steps, while maintenance functions would be folded into the “more” menu to avoid cluttering the screen.

As for the driver’s app, the user should be able to flick between the map and the calendar any time during any in-app/in-person conversation. This is why that the calendar (which manages time), the map (which handles the locations), the chat function, and the booking sequence are connected by a closed loop (in red) on the driver’s app’s site map.

User flows

Next, I moved on to creating the user flows, looking at how each user persona would complete a critical task.

The first user flow shows how the older adult rider, with or without his/her caregiver, can pre-select three drivers and add them to their drivers’ list.

Once the driver’s list has been set up, the older adult can directly contact the driver by phone. If the numbers are pinned to the fridge, the senior rider may never have to touch the smartphone again.

Like this.

User flow 2: Rider calls driver to make a booking

The in-app, instant messenger operates like any other chat app with integrated features for completing a booking process. The interaction mirrors what might happen in real-life:

The booking sequence

When translated into an interaction sequence that takes place through the app, it looks like this:

User flow 3: Rider makes an appointment with the driver via in-app messenger
User flow 4: Driver responds to rider’s request through in-app messenger

While the booking process in the rider’s experience is straightforward and linear, the driver’s app is doing most of the heavy-lifting. 90% of the design challenge, evident in the next few rounds of constant reiteration and usability testing, is to make the process learnable and easy to use for the driver.

Design and Test [round 1]: Low-fidelity sketches

Initial drafts

After gaining a basic idea about the structure of the app and defining the essential interactions that are involved, I moved on to produce a rough sketch of how the app might look like. Admittedly, at this point, I had not yet realized all the minute details and complexities that the whole app would involve, but putting pen on paper helped me discover them through an on-going process of problem-discovery and brainstorming solutions.

Feel free to try out this clickable prototype of the rider’s app

Usability testing methodology

To design an app that is friendly, streamlined, and frictionless, I understood that it was necessary to test it with real users from the early stage. Having roughed up a simple paper prototype, I approached friends and family members with caregiving experience to participate in the test the testing of the red routes to try out both of the apps.

Design and testing

Below is a consolidation of the two prototypes’ wireflows with feedback from users.


  1. Most users validated my hypothesis that the in-app messenger would be useful to them as caregivers, and acknowledged that their elderly would probably prefer contacting the driver through the phone.
  2. The most challenging task for users, when using the drivers’ app, is to figure out how to start an in-person booking. While users did not find it difficult to manage after a little bit of exploration, having an explicit CTA somewhere would make it more intuitive and reassuring to them.
  3. Words matter a lot. Most of the participants provided thoughtful feedback addressed issues of clear labeling and choice of words, especially for CTA UI components.
  4. It is crucial to not just observe what paths the participants did take but also what buttons or tooltips all had unanimously ignored, which means that those design decisions were ineffective.
  5. Icons should always be labeled. Always, even in a sketch prototype!

Design and Test [round 2]: Clickable wireframes v.1.0

Testing ‘experimental’ interaction design decisions

Based on the first round of feedback, I began to develop the wireframes for the drivers and rider’s app.

After producing a rudimentary sketch prototype, I realized that the driver needs the ability to check route information and their availability at any point during a conversation with the rider. This is key to facilitating an organic interaction with a rider, and mimicking real-life interactions.

Once that was taken into consideration, the drivers’ app quickly spiralled into a formidable beast. I tried various design solutions to simplify the complex navigation demands, however, it was hard to tell whether they worked or not without testing them on the target users.

Recruiting test participants

So, after finishing the next round of clickable wireframes, I went to the senior center and intercepted retirees might be kind enough to test both the drivers’ and riders’ app design. I looked out for retirees who were around 60–70 years old and seemed reasonably comfortable with using mobile apps— ideally with some caregiving experience.

I was fortunate enough to get hold of two retirees — Dorothy and Susan (age: 60–70) to undertake the moderated test.

Below is an illustration of that experience.

Summary of findings

“I would never use this product. It’s not user friendly at all.”

Critical failures:

  1. The app had too many features, so the MVP needed a vast readjustment.
  2. The accordion menu for the riders’ app’s landing page was not user-friendly. Once expanded, the page turns into a long scroll, and what is out of vision is out of mind.
  3. Users often felt overwhelmed by the amount of information presented to them on a single screen.
  4. The bottom tabbed menu either confused users or was entirely neglected.
  5. It was wrong to rely on swipe gestures to control the navigation between basic functionalities when designing for older users.

Small success:

  1. The screens that were most comfortable and reassuring to the user were not only linearly arranged but also contained bite-sized amounts of information. Like these.

Design and Test [round 3]: Clickable wireframes v. 2.0

The app needed a considerable amount of makeover. Guided by the important takeaways from my last usability testing, I made the following alterations to the entire design.

Amended MVP and user stories

  1. Reduced to two modes of communication

Since I am undergoing a major restructuring, I decided, for the time being, to forgo the form booking function, in spite of its ease of use and efficiency. This product’s goal is to build rapport between the rider and the driver, hence advocating a more human experience of booking through conversation reinforces the product’s value proposition.

2. Instead of 1 rider to 3 drivers, pair 1 rider with 1 driver

“Instead of going through the process of choosing three drivers, why not just have the system automatically assign one driver that best matches the needs of the rider? That way, the rider could get on the first ride, rate her level of satisfaction, and then, if she thinks the driver is a good match she could stick with her, or if not be reassigned someone else.” — Dorothy, usability test participant (Round 2)

Dorathy’s idea inspired me to simplify the app: Instead of having one rider choose three drivers, have one rider matched with one driver. I eliminated the drivers’ list altogether.

These changes not only paved the way for greater efficiency, cleaner navigation, and overall a more user-friendly, concierge experience — it also sharpened the value proposition and made the overarching scheme tighter and much more communicable.

Screen iterations:

I. Rider’s app — Choose 1 instead of 3 drivers

Firstly, for choosing drivers on the riders’ app, I designed a one-question-per-screen questionnaire asking for the riders’ preferences before searching for the one best match. After completing the driver selection, all interactions throughout the app would be with that one driver, which radically simplified the information architecture.

II. Simplifying navigation patterns

The process of working out a visual and interactive navigation pattern for a highly complex system that is intuitive to older adult users was heavily reliant on testing with target users. Many potential solutions I conjured as a designer did not work, and it was incredibly painful watching senior usability test participants suffer through many earlier prototype versions that were not well thought-out.

The eventual breakthrough came about after I watched, and was inspired by, the Black Mirror episode — Bandersnatch.

Inspired by Black Mirror episode “Bandersnatch,” which allows the audience to make decisions of the protagonist.

The interactive viewing experience allows viewers to determine their ending to the story by imitating the experience of reading “choose-your-own-adventure” novels. I thought — hey, even though it’s a complicated story, I as a viewer never really get lost!

There is something to learn from this.

So, instead of relying on obscured navigation elements such as gestures and gridded tabbed menus with tiny icons, I incorporated eye-catching slide-out panel options and large buttons, with call-to-action prompt always written from the first person’s point of view. Since the screens only present the user with limited options in any given moment, she can easily walk through the entire booking process without having to understand how the whole system works. This simple solution raised the level of intuitiveness and user-friendliness drastically.

III. Drivers’ app — Automating the time estimation of the appointment duration

Finally, I also realized that there is a need to add a step in the booking process which calculates the duration of the entire appointment time to correctly manage the driver’s working schedule and avoid schedule clashes. In this version, the system automatically generates an itinerary at the end of the booking process based on the location and time data entered by the driver.

User impressions

Since I was making rather drastic changes, I tried the new wireframe drafts with friends and family around me. Fortunately enough, this quick round of testing did affirm that the changes were effective, so I moved on to develop the UI design and resulted in high-fidelity prototypes for a formal usability test.

I approached three new usability test participants—Mary Ellen, Sheryl, and Robin, all between 60–70 years old—to perform the next round of formal, moderated usability test.

Overall, this round of test went much smoother than the last version. Two out of the three users smoothly completed the activities, with only some minor issues to be dealt with regarding font sizes and visibility and positioning of CTA elements. I documented these and reflected them in the last round of adjustments.

Design and Test [round 4]: High-fidelity prototype

Walaa. After three rounds of testing and reiteration, the prototype seemed to have improved a great deal.

But just to be sure, I asked my aunt, Marianne—whom the persona (Ann) was modeled on—to try the final design once last time. Having helped me test various prototype versions formally and informally throughout, this time she was finally able to sail through the navigation in a breeze.

Video of riders’ app final design
Video of drivers’ app final design

“That was painless!” — Marianne, on the final round of informal testing.


When I conjured of this project space to tackle, I intended to undertake a creative endeavor that my grandmother would understand. I must admit that in hindsight the decision was driven by baseless audacity. This project demanded more attentiveness, more profound empathy, and greater technical understanding of accessibility best practices than an average beginner’s project. I also underestimated the difficulty in securing the necessary number of fresh eyes, who fit the personas I defined, to test the design on multiple occasions.

The validation of my last test participants, however, was hugely encouraging — I’ve managed to upgrade a product from “not user-friendly at all” to “not painful at all.”

Some lessons learned:

  • It takes a great deal of effort to design seamless experiences. Focus on perfecting a small portion rather than working too broad a scope at once is worth it.
  • Usability testing is definitely the fastest way to learn.
  • The timing of performing usability testing is just as important as the frequency.
  • Try not to move on to the next stage or overdo the prototype until the essential design decisions are validated by the testing.

I want to thank Leland, Marianne, Dorothy, Nancy, Susan, Mary Ellen, Robin, Sheryl, Laura and James for participating in my various usability tests; my mentor John Maier for his thoughtful guidance and encouragement; and my two grandmothers Lola and Amy for inspiring the project.




Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +756K followers.

Recommended from Medium

Hamburger Menus — A Challenge to Accessibility and UX Design Principles?

The best type of user you want for your app

Laptop with a grid of user’s avatars on it and beyond

Conducting moderated usability testing remotely

Article banner “Conducting moderated usability testing remotely”

Intro to Generative Design for Graphic Designers

0–3 years: Content Design/ UX Writing @ Telstra

Why would we care about user onboarding?

Craft your user onboarding experience to help users achieve their desired outcomes. Retention resonates from nailing this!

How To Make CX/UX Agile In 5 Steps

My First UX Hackathon Experience

There is a flipchart with orange and pink sticky notes on laid out in a journey map a person is leaning over writing on a sticky note.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Lai-Jing Chu

Lai-Jing Chu

Product Designer + PM →

More from Medium

UX Lab Teams — Experimental Collaboration

The Ultimate Guide to Lean UX Design

Product too complex to explain? Wrap it up in a story

A two-dimensional illustration of a blue bird with dashes of code symbols emulating its feathers and a speech bubble with a heart symbol. The bird sits on a wire against a pink background.

Fitt’s Law in User Interface