Whimble

Whimble

Whimble

Testing an accessible mobile app for personalized on-demand care

Testing an accessible mobile app for personalized on-demand care

Testing an accessible mobile app for personalized on-demand care

A mockup of an iPhone in hand, with the whimble app opened

PROJECT SUMMARY

Ensuring they get it right
Ensuring they get it right
Ensuring they get it right

Whimble connects people with disabilities to on-demand caregivers. Not just for convenience, but often, for survival. The current state of their service was running through a mix of phone calls, texts, and Slack messages, and they knew it had to be better. So they built a mid fidelity prototype in Balsamiq, a tool they taught themselves... and brought us in to find out if their concept would actually work as an app. I was a UX Researcher on the team, responsible for: heuristic review, task development, two rounds of moderated testing, and synthesis. This is the story of what we found, and what changed because of it.

Client:

Whimble

Timeline:

7 weeks · 2023

My Role:

UX Researcher

"Really, really cool, user friendly and customizable."
"Really, really cool, user friendly and customizable."
"Really, really cool, user friendly and customizable."

PARTICIPANT - VALIDATION (R2) USABILITY TESTING

PARTICIPANT - VALIDATION (R2) USABILITY TESTING

PARTICIPANT - VALIDATION (R2) USABILITY TESTING

SCALE OF THE PROJECT

27

Moderated sessions across two rounds

15

Core tasks designed and tested per group

2

User groups: Clients with disabilities & Caregivers

7

Weeks from prototype review to final report

METHODOLOGY

Six phases, one tight deadline
Six phases, one tight deadline
Six phases, one tight deadline
Seven weeks isn't a lot of time. We had to be methodical about sequencing... each phase set up the next.

Seven weeks isn't a lot of time. We had to be methodical about sequencing... each phase set up the next.

01. Prototype Review

  • We conducted a thorough expert review of Whimble’s initial wireframes (built on balsamiq) to understand the app’s features, services, and overall vision.

  • This evaluation, based on Nielsen Norman Group’s 10 heuristic principles, helped identify usability gaps and refine the prototype before testing.

02. Task Development

*I led this*

  • A task development workshop was held to design realistic testing scenarios reflecting actual app usage for both clients and caregivers.

  • This process involved collaborating with subject matter experts to define high-priority tasks tailored to the app’s core user groups.

03. Participant Recruitment

We developed inclusive outreach materials and recruited participants from two distinct user groups for usability testing:

  • Demand Side: People with disabilities, including physical, vision, hearing, and speech-language impairments

  • Supply Side: Caregivers and attendants providing services to the demand side

04. Preparing Test Guides & Ensuring Accessibility

*I led this*

  • We developed separate test guides for each user group. The guides were designed to accommodate tools like screen readers and text-to-voice technology.

  • Additionally, we reached out to participants with disabilities to identify and address any specific needs to help facilitate sessions.

05. Baseline Usability Testing

*I led this*

  • 16 remote 1:1 sessions - 11 demand clients, 5 supply caregivers,

  • Assessed the app’s current strengths and weaknesses, understand user needs, and set a benchmark for usability

  • Synthesized what we heard into a prioritized findings & recommendations report.

06. Validation Usability Testing

*I led this*

  • 11 remote 1:1 sessions - 6 demand clients, 5 supply caregivers,

  • Based on our recommendations from round 1, the client updated the prototype.

  • We tested this updated prototype to compare its performance with the original version.

KEY FINDINGS

What we learned from the sessions
What we learned from the sessions
What we learned from the sessions
01
01
01

Registration felt like an obstacle course

The sign-up flow had too much text presented all at once, progress indicators that changed style partway through, and pages that asked for overlapping information. For participants with cognitive or visual challenges, this wasn't just inconvenient, it was exhausting.

02
02
02

Small font sizes and touch targets

Participants struggled to read text and hit the right targets, especially on mobile. For a product built specifically for people with disabilities, this wasn't an edge case... It was the primary audience.

03
03
03

Icons not pulling their weight

The 'star' icon was meant to mean "Feedback." Most participants had no idea. The chat bubble left participants guessing whether it would reach Whimble or their caregiver.

04
04
04

Confusing UX copy language

When an attendant proposed a time change for their reservation, the page said "Counter offer." Multiple participants found this confusing... one said it sounded like someone asking for more money, another described it as "adversarial". It was meant to be a re-scheduling tool.

05
05
05

No recollection of established information

Clients had already entered their care needs during sign-up. When they went to book a session, the app asked again. Several participants expected their details to auto-populate, and the experience of repeating themselves felt like a miss.

06
06
06

Need for more control

Supply-side participants wanted to set a maximum travel radius for requests, and receive reminders for upcoming shifts. Features that seem small but matter a lot for reliability.

WHAT WE REDESIGNED

We carefully analyzed participant feedback and developed targeted recommendations to address key usability challenges. These solutions aimed to simplify the user experience, improve accessibility, and enhance functionality for both user groups.

We carefully analyzed participant feedback and developed targeted recommendations to address key usability challenges. These solutions aimed to simplify the user experience, improve accessibility, and enhance functionality for both user groups.

NOTE: Design was NOT part of the project scope. The mockups below (and in the cover image) are my own interpretations, built specifically for this case study. I've added these here because I think good research should be able to answer "what would this actually look like?"... and I wanted to demonstrate that.

NOTE: Design was NOT part of the project scope. The mockups below (and in the cover image) are my own interpretations, built specifically for this case study. I've added these here because I think good research should be able to answer "what would this actually look like?"... and I wanted to demonstrate that.

Breaking registration into a journey, not a wall

Breaking registration into a journey, not a wall

Before:
Dense blocks of text, progress indicators that changed style mid-flow, and no indication of which fields were optional. Participants felt lost and overwhelmed before they'd even finished signing up.


After:

A consistent progress bar, clearly labeled optional fields, and content broken into digestible steps made the same information feel manageable.

Giving every icon a voice

Giving every icon a voice

Before:
Navigation relied entirely on unlabeled icons… the star meant "Feedback," the chat bubble could mean contact Whimble or a caregiver. Participants had to click to find out.


After:

Every icon in the nav bar got a text label, removing the guesswork entirely and making the app readable at a glance.

Making (re)scheduling feel more cooperative

Making (re)scheduling feel more cooperative

Before:
When a caregiver proposed a time change, the button said "Counter Offer"… participants described it as confusing, transactional, even adversarial.

After:
Renamed to "Propose Change" with a clear before/after time comparison on screen, the interaction felt cooperative rather than confrontational.

Ensuring the app remembers what was already told

Ensuring the app remembers what was already told

Before:
Every new booking required clients to manually re-select their care needs… even though they'd already provided all of this during sign-up.

After:
Services pre-populate from the user's profile, with the flexibility to add, remove, or adjust for that specific session.

Making it easier to ask for help

Making it easier to ask for help

Before:
"Having trouble? Call us" sat small and easy to overlook on the landing page… several participants scrolled past it, and there was no chat alternative for those who couldn't or preferred not to use voice calls.

After:
The contact option is more prominent, relabelled for clarity, and a chat alternative sits alongside it. A meaningful change for participants who relied on non-verbal communication.

THE RESULTS

Before vs. after, in numbers
Before vs. after, in numbers
Before vs. after, in numbers
Task success stayed stable or improved in some cases. Participants were notably quicker, especially on tasks that had updated designs based on our recommendations. The bigger shift was qualitative. The tone of sessions was fundamentally different.

Task success stayed stable or improved in some cases. Participants were notably quicker, especially on tasks that had updated designs based on our recommendations. The bigger shift was qualitative. The tone of sessions was fundamentally different.

Create an account (registration)

Create an account (registration)

Create an account (registration)

Round 1 baseline - Very Well (86–100%)

Round 1 baseline - Very Well (86–100%)

Round 2 validation - Very Well (86–100%)

Round 2 validation - Very Well (86–100%)

Consistent
Consistent
Consistent

held strong across rounds

held strong across rounds

Schedule care in advance

Schedule care in advance

Schedule care in advance

Round 1 baseline - Well (71 - 85%)

Round 1 baseline - Well (71 - 85%)

Round 2 validation - Well (71 - 85%)

Round 2 validation - Well (71 - 85%)

Faster
Faster
Faster

less hesitation, more confidence

less hesitation, more confidence

Contact Whimble about payment

Contact Whimble about payment

Contact Whimble about payment

Round 1 baseline - Somewhat Well (51 - 70%) · Avg 161s

Round 1 baseline - Somewhat Well (51 - 70%) · Avg 161s

Round 2 validation - Well (71 - 85%) · Avg 22s

Round 2 validation - Well (71 - 85%) · Avg 22s

7× faster
7× faster
7× faster

biggest single improvement

biggest single improvement

"It was really easy to use [...] everything is clearer."
"It was really easy to use [...] everything is clearer."
"It was really easy to use [...] everything is clearer."
"Overall everything looks very good. Pretty self explanatory."
"Overall everything looks very good. Pretty self explanatory."
"Overall everything looks very good. Pretty self explanatory."
"Now that's a great improvement [...] this is very straightforward."
"Now that's a great improvement [...] this is very straightforward."
"Now that's a great improvement [...] this is very straightforward."
We still flagged remaining gaps... icon labeling wasn't complete everywhere, and the registration flow still had moments that felt heavy. Those went into the final report. But the shift in tone from round one to round two was real and measurable.

We still flagged remaining gaps... icon labeling wasn't complete everywhere, and the registration flow still had moments that felt heavy. Those went into the final report. But the shift in tone from round one to round two was real and measurable.

PERSONAL REFLECTIONS

I studied accessibility in architecture before I moved into Product… barrier-free design, universal access, the idea that a building should work for everyone who needs to use it. This project let me apply that thinking in a completely different medium.

What I didn't fully anticipate was how much this project would ask me to hold. Sitting with participants who rely on services like Whimble… who've had to navigate fragmented, unreliable care systems for years, reminded me that UX research isn't just problem-solving. It's being a witness… and that requires care, beyond the session notes.