shiftrx・facility portal
An overwhelmed pharmacy owner had to leave one app and enter another just to post a job.
Role
Sole Product Designer
Timeline
2 quarters
Responsibilities
End-to-end process
Platform
Web
01 - Context
Who it’s for, and what’s at stake
Owners open this portal rarely, and almost always under pressure: short-staffed, a shift to fill before tomorrow’s opening. A no-show can legally force a pharmacy to close for the day. The design had to earn trust at every step, not just the happy path.
2 → 1
A shifts portal and a bolted-on Careers app, joined by a “Switch to Careers” button, unified into one contextual product.
Managing both per-diem staffing and hiring felt like using two different products.
product
Built feature-by-feature with no shared system.
users
Users are infrequent, often non-technical, and almost always under time pressure.
02 - What I Inherited
A portal built section by section
The portal was functional but had never been designed as one product. Posting a shift, the single most important job, failed at every level.
Two products, one bolted on
Shifts and Careers were separate interfaces joined by a button. Managing both felt like leaving one app and entering another.
Creation in a cluttered modal
Every field at once, most styled gray so active ones read as disabled, and required fields revealed only at validation.
“Add Facility” lived in the sidebar
A global navigation action, not a destination, buried alongside links instead of belonging to the facilities table where it’s actually used.
One date at a time, from scratch
Every date needed its own pass through the modal, its own calendar tap, its own time range, its own save — with no way to apply one setup across several days.
A job posting with no pipeline behind it
Beyond a yes/no on whether someone applied, there was no way to see where a candidate stood (invited, trial shift, hired) or to stop a facility from hiring outside the system entirely.
03 - What I Rebuilt
Decision by decision
One product instead of two, and a creation flow that respects the moment.
Two modes, not two apps
A five-step guided screen
Destinations, not actions
Multiple dates, one pass
Every hire, tracked end to end
04 - Decisions
What I chose and what I ruled out
Chose
Shifts + Jobs, one product
A dedicated screen, sidebar always visible
A longer onboarding that collects once
Ruled out, and why
A full-screen creation wizard
A short single-form onboarding
outcomes
What changed
~82%
Shift creation completion rate
<1 min
Time to post a single shift
2 → 1
Unified workflow
05 - Learnings
What I learned
One place to work from, not two
Switching apps to do one job cost owners time and confidence they didn't have to spare. Unifying Shifts and Jobs wasn't about elegance, it meant one less thing to think about when they were already stretched thin.
A longer onboarding can be right
The instinct to shorten is usually right, but every field skipped here meant asking the same question again on every future shift or job post. A longer setup once gave owners more control at the moment of posting.
Good UX is good business
Not every decision here was justified by user experience alone, some of the strongest calls also made the product easier to run and easier to grow. The two goals usually point the same direction.
