ShiftRx Provider App | UX Case Study

shiftrx・PROVIDER app

A provider app with no design language was losing pharmacists before they ever saw a shift.

I rebuilt it in two phases, first a visual system from scratch, then a full onboarding overhaul.

Role

Sole Product Designer

Timeline

2 quarters

Responsibilities

End-to-end process

Platform

Web, iOS, Android

Screenshot of the ShiftRx provider app shown on laptop and phone, displaying the redesigned shift dashboard.

01 - Context

Who it’s for, and what’s at stake

Pharmacists and techs open the app to work, not to browse: they scan for fair pay, a manageable location, and hours that fit. They trust ShiftRx because it's built for their profession, and that trust is the platform's most fragile asset. When a provider doesn't show, a pharmacy can be forced to close for the day. The app had to earn that trust immediately, or lose a provider before they ever saw a shift.

Pharmacists and techs open the app to work, not to browse: they scan for fair pay, a manageable location, and hours that fit. They trust ShiftRx because it’s built for their profession, and that trust is the platform’s most fragile asset. When a provider doesn’t show, a pharmacy can be forced to close for the day. The app had to earn that trust immediately, or lose a provider before they ever saw a shift.

327

Deletion events over the first half of last year, clustering into three failure modes: too few local shifts, pay dissatisfaction, and app usability.

Usability was the one failure mode entirely within a designer's control. That's where I started.

product

Already live and in daily use by pharmacists and techs, built feature-by-feature instead of a shared design language.

trust

Trust is the most fragile asset here: licensed professionals handing over credentials. Tone and clarity are load-bearing.

02 - What I Inherited

A product with no design language at all

The app was functional but built feature-by-feature. I spent my first days using them as a provider would, documenting what I hit. It wasn't a product with a few rough edges. It was a product with no language.

Tags that looked disabled

Status tags and buttons followed no shared rules. A confirmed shift could look identical to a disabled control.

Nowhere for the eye to land

Long screens read as one dense block, with nothing to guide the eye toward what mattered.

An assistant with nothing to say

A generic overlay sat on top of the dashboard, 'How can I help today?' and an empty field, with no sense of what it could actually help with.

Three names for one feature

The same section read 'Careers' in the mobile header, 'Jobs' in the mobile tab bar, and split into 'PRN Shifts' and 'Part/Full Time Jobs' on desktop, all pointing at the same thing.

"Professional Info" meant everything

Role, malpractice insurance, a phone number, SMS consent, and a state license all lived under one heading, with no real thread connecting them beyond needing an answer.

03 - What I Rebuilt - PHASE 1

I built the design language from scratch

Without a coherent language, nothing else could be consistent or trustworthy.

Color with meaning

One button style per context, and color that means something: blue for actions, green for confirmed, amber for pending. A shift's status is now readable at a glance.

One button style per context, and color that means something: blue for actions, green for confirmed, amber for pending. A shift’s status is now readable at a glance.

Shifts and Jobs, one tap apart

The ambiguous 'Careers' label became a clear toggle between Shifts and Jobs, with a Browse Shifts button and real numbers, upcoming, completed, earned, right on arrival.

The ambiguous ‘Careers’ label became a clear toggle between Shifts and Jobs, with a Browse Shifts button and real numbers, upcoming, completed, earned, right on arrival.

Clear sections replace a wall of text

The same information now sits in labeled sections, what's included, cost, agreement, so a provider can scan for what matters instead of reading straight through.

The same information now sits in labeled sections, what’s included, cost, agreement, so a provider can scan for what matters instead of reading straight through.

A name and three places to start

The nameless overlay became Rex, with three tappable categories instead of a blank field waiting for the right words.

A score you can actually improve

The provider score used to be a single number with no explanation. Now it breaks into four weighted factors, each with a plain description of what it means and how to improve it.

04 - What I Rebuilt - PHASE 2

The visual fix revealed a structural one

Even after the visual pass, onboarding still asked for too much, in the wrong order, before providers had any reason to stay. Every drop-off was a provider who never entered the marketplace, fewer applicants, shifts going unfilled. A supply problem with direct business consequences.

intent before identity

Role and work preferences come first, before any personal details. Providers state what they want before handing over who they are.

curated, not endless

Skills and languages are tap-to-select from what providers use most, not an endless dropdown. More can always be added later.

a photo made to matter

Profile photos became required, not optional. Providers with one get picked for shifts more often than those without.

An ending that rewards, not a dead end

Finishing onboarding surfaces real shifts when they're available, or nearby hiring facilities when they're not. Never an empty screen.

Finishing onboarding surfaces real shifts when they’re available, or nearby hiring facilities when they’re not. Never an empty screen.

05 - Decisions

What I chose and what I ruled out

Chose

Two deliberate phases

I split the rebuild into two passes on purpose: fix what was visibly broken first, then see what was actually still wrong before touching the architecture. Doing both at once would have meant redesigning the structure on signal I couldn't trust yet.

Intent before identity

I opened the flow with role and work preferences instead of a form. A provider tells us what they want before we ask who they are — relevance before collection was the rule I held myself to.

Consent gets its own screen

Phone, SMS consent, ToS, and Privacy used to be one buried checkbox. I gave them a dedicated screen instead. If we're asking someone to trust us with their data, the least we can do is not bury the ask.

Phone, SMS consent, ToS, and Privacy used to be one buried checkbox. I gave them a dedicated screen instead. If we’re asking someone to trust us with their data, the least we can do is not bury the ask.

Ruled out, and why

Deferring credentials fields, specifically

I use progressive disclosure elsewhere in the flow: resume can be added after signup. Credentials can't wait, though. They feed verification, and that has to clear before a provider's first shift, so deferring them would've just traded one gate for two.

I use progressive disclosure elsewhere in the flow: resume can be added after signup. Credentials can’t wait, though. They feed verification, and that has to clear before a provider’s first shift, so deferring them would’ve just traded one gate for two.

Touching onboarding architecture in Phase 1

I held off. The existing flow was too visually chaotic for any structural read to be reliable, and I'd rather wait for clean signal than guess under noise.

I held off. The existing flow was too visually chaotic for any structural read to be reliable, and I’d rather wait for clean signal than guess under noise.

Leaving the profile photo optional

Optional felt lower-friction, but providers with a photo get picked for shifts more often than those without. I made it required and put that friction in onboarding, where it's a one-time cost, instead of leaving it as a gap that quietly hurt providers later.

Optional felt lower-friction, but providers with a photo get picked for shifts more often than those without. I made it required and put that friction in onboarding, where it’s a one-time cost, instead of leaving it as a gap that quietly hurt providers later.

outcomes

What changed

+20%

New user activation rate

-42%

UX-related support tickets

06 - Learnings

What I learned

One shared system, two sides of a marketplace

I was the only designer on both sides: the Provider app that pharmacists and techs used to find shifts, and the Facility platform that pharmacy managers used to post them. A shared system was the only way to keep both consistent instead of drifting into two different products that happened to share a name.

"Providers" wasn't one user

I learned the umbrella term covered two different anxieties. Technicians needed pay and background-check timing to be clear, fast, that was the difference between trusting the app and calling support. Pharmacists cared more about reputation and whether the work matched their role. Same label, two different sets of priorities.

Unclear copy was a support cost

Providers called customer service asking when their pay or background check would clear, not because the information didn't exist, but because the app never said it. Once that status lived in the product itself, the calls dropped.

Next case study

ShiftRx Facility Portal

The portal behind every shift, where disconnected workflows became one seamless experience.