Case Study — Healthcare Staffing / Mobile App

KARE Hero — The Onboarding Decision

KARE Hero connects healthcare workers — CNAs, nurses, caregivers — with per-shift job postings. This case study is a deep dive into one decision: replacing a document-heavy sign-up form with a guided, step-by-step onboarding wizard.

A single-page form asking for a license, a resume, tax documents, and background-check consent all at once was dropping a high percentage of new users before they ever saw a shift. The question wasn't whether to fix onboarding — it was whether a guided wizard was worth the engineering cost of rebuilding the flow from scratch.
Role
Senior UX/UI Designer
Focus
Onboarding Decision & Flow Redesign
Company
KARE Hero
Team
1 junior designer, 5 developers, 1 product owner, 1 stakeholder
Duration
1 year (2023–2024)
Tools
Figma, LucidChart, Hotjar, Google Analytics
Accessibility
WCAG 2.1 Audit
KARE Hero app welcome screen
15%
Increase in user registrations after the wizard shipped
9
Users in live usability testing on the BETA app
1
Form, replaced by a 5-step guided flow

A guided wizard, or patch the form?

KARE Hero's registration was a single long form: personal details, license number, resume, tax forms, background-check consent, all on one screen, with no sense of progress. Two paths were on the table. Patch the existing form — trim fields, add inline validation, ship it fast. Or rebuild registration entirely as a multi-step wizard — slower to build, but able to collect information progressively and show a hero exactly where they stood.

Patch the form

  • Days of engineering work, not months
  • No new navigation pattern for users to learn
  • Doesn't fix the core problem — still one long wall of fields
  • No visible progress, no reason for a half-finished user to come back

Build the wizard

  • A visible stepper turns "how much is left" into a known quantity
  • Each screen asks for one category of information, with a reason attached
  • A natural place to add "finish later" without losing progress
  • Real engineering cost — five new screens, new state to manage between them

The documents weren't optional

This wasn't a checkout flow where every field is negotiable. US healthcare staffing regulations require a verified license, tax forms, and a background check before anyone can be shown a shift — the wizard couldn't quietly drop steps to make onboarding feel shorter, only make each step feel worth doing.

Regulatory, not optional

License verification, tax forms, and background checks are required by law before a hero can work — none of it could be cut to simplify the flow.

Real people, real stakes

Cynthia, a single mother working CNA shifts, couldn't afford to lose an evening to a broken form. The redesign had to respect that time.

One shot at trust

A confusing first form reads as a red flag on a platform asking for a Social Security number — the design had to earn that trust screen by screen.

Two heroes, one shared complaint

Research centered on two personas built from real interviews with medical staff and platform users: Cynthia Morgan, a CNA caregiver and single mother, and Tom Bennett, a registered nurse working toward becoming a therapist. Both pointed at the same friction point, independently.

KARE Hero user personas: Cynthia Morgan and Tom Bennett

Cynthia's frustration: "too much time being wasted throughout a difficult onboarding process that involves endless phone calls." Tom's: "unorganized shift schedulers, lack of clarification during the process, and overwhelming information."

Customer journey map showing the Wait stage after applying to a shift

The journey map's "Wait" stage: users expected confirmation quickly, but review time varied for anyone new to the platform — with no visibility into which case they were in.

Affinity map cluster: onboarding and apply pain points

Raw findings clustered directly under "Onboarding apply" — easy onboarding, visual queue indicators, clear documentation, a fast way to upload extras.

9
Users tested on the live BETA app and prototype
5
Core app sections covered in task-based testing
3
Major insight categories synthesized from findings
Usability testing results: what worked, what didn't, and recommendations

The usability testing readout that confirmed it: onboarding needed a "visual queue" of progress, and documentation needed to feel less uncategorized.

From one form to five honest steps

The wizard won. Below is the actual before-and-after: the shipped screen a hero saw before this redesign, next to the guided flow that replaced it — sign-up through the moment a brand-new hero is cleared to apply for their first shift.

Before — shipped, in production

Old KARE app shift application screen with dense facility and check-in information

Applying to a shift meant reading through facility ratings, requested attire, and check-in instructions on one dense screen before a single "Apply Now" button.

After — the guided wizard

KARE Hero onboarding completion screen, ready to apply for first shift

Registration now ends with an explicit "you're cleared" moment — the payoff for finishing every step, not just a silent redirect.

The five-step flow — sign-up through cleared-to-work
Sign up screen with photo, name, email, and password fields
Sign up
Personal information step with address and identity fields
Personal information
License verification step, empty, with explanation text
License verification
License verification step, filled, ready to submit
Ready for review
License submitted confirmation screen
License submitted
Interview scheduling step with KARE team
Interview scheduled

Every step carries the same progress bar and a plain-language reason for the request — the two things the old single form never gave a hero.

View interactive prototype in Figma →

Built native, tokens borrowed from the web

As a native iOS and Android app, every wizard screen was checked against each platform's own conventions rather than a single cross-platform mockup — while the underlying design tokens followed a Tailwind-style naming convention for consistency across the design file.

Platform guidelines

  • iOS builds follow Apple's Human Interface Guidelines for navigation, spacing, and native form controls
  • Android builds follow Material 3 — dynamic color, elevation, and component behavior native to the platform
  • Progress steppers, buttons, and form fields were validated on both platforms rather than assumed to look identical

Design tokens

  • Color, spacing, and type scales named and structured the way Tailwind CSS organizes its utility classes
  • A shared naming convention made tokens easy to hand off to developers on both platforms
  • Kept the visual language consistent even where iOS and Android components render differently

What a cleared hero sees next

Once onboarding is complete, a hero lands directly in shift search — the reason they signed up in the first place.

KARE Hero shift search results in list view

Search, filtered by date and rate, with map and list views — the core loop the whole onboarding decision existed to protect.

15% increase in user registrations.

Rebuilding onboarding as a guided wizard was the more expensive path to build — and the one that actually addressed why heroes were dropping off. Progressive disclosure and a visible stepper turned a compliance requirement into a flow people could see themselves finishing.

Clearer
Visible progress at every step, instead of one long form
Honest
Every document request paired with a plain-language reason
Native
iOS and Android builds validated against each platform's own guidelines
The easier path was to patch the old form and call onboarding fixed. The harder path — rebuilding it as a wizard — was the one backed by two personas, a journey map, and usability testing all pointing at the same friction point. That's usually the decision worth making.

Looking back: the wizard solved the front half of the wait — showing heroes exactly how far along they were. It didn't solve the back half. Once a license went into review, the same uncertainty from the old form came back: no visibility into how long that review would actually take. Progress inside the flow was never the whole problem.

Next case study
Hey! Banco