Workforce Operations
Platform
A production-grade platform replacing four disconnected tools used by healthcare field workers and their agencies. Mileage tracking, scheduling, shift marketplace, expense management, and patient visit coordination, deployed live in eighteen weeks.
Role
Lead Product Designer
Collaborator
US-based agency
Timeline
Aug 2024 — May 2026
Status
Live in Production
Cross-functional Team
Solo designer · 3 engineers
Tools
Product Walkthrough
A guided walkthrough of the platform. Desktop dashboard and mobile experience.
Want a live walkthrough of the full product? Get in touch and I will walk you through every module in a 30-minute session.
Understanding the problem before designing anything.
The first conversation was not a brief. It was a working session. The client had multiple tools open simultaneously and was switching between them mid-sentence to describe what their coordinators and field workers were doing every day.
I was the sole designer on this project, working directly with the client team and three engineers. All research, design decisions, and implementation oversight were mine end to end.
We started with structured discovery calls across both user types. With coordinators, we mapped how they thought about scheduling, compliance, and billing as interconnected problems. With field workers, we focused on the moments of highest friction: logging a trip while in a car park, clocking in under time pressure, submitting an expense without access to a desktop.
Every session was documented as a job-to-be-done, not a usability complaint. That distinction mattered. Usability complaints describe what is broken. Jobs-to-be-done describe what the person is actually trying to accomplish. The entire architecture came from that distinction.
By the time we moved into wireframes, every screen had a direct line back to something a real user said in a real session.
KICKOFF
Initial briefing and goal alignment
Understanding business constraints and go-to-market priorities
DISCOVERY
Structured calls with both user types
Mapping jobs-to-be-done across coordinator and field worker roles
SYNTHESIS
Translating research into architecture
Every screen mapped to a documented user need
DESIGN AND BUILD
Iterative design with weekly client reviews
From first wireframe to production handoff
18 weeks. Two users. One system.
The project ran across three phases: discovery and research (weeks 1 to 4), iterative design and validation (weeks 5 to 14), and build handoff alongside design system completion (weeks 15 to 18).
The hardest constraint was designing for two users whose needs are structurally opposed. A scheduling coordinator needs information density, pattern recognition, and a 48-hour operational view. A field worker needs the opposite: one visible action, zero decisions, and a screen that makes sense in ten seconds while holding something with the other hand.
The product should do the thinking so the worker does not have to.
That principle governed every decision from information architecture to interaction timing to tap count for any critical action. It ruled out multi-step manual flows, user-configured settings for things the system could detect, and any screen requiring a worker to understand the system logic in order to use it.
Project phases
Discovery and Research
Field interviews across two user types. Problem framing. Workflow mapping. The key finding: the invoice delay was never caused by the billing system. It was caused by missing paper vouchers.
Design and Validation
Information architecture, interaction patterns, two rounds of usability testing. Twelve screens revised after round one based on real user behaviour and three critical compliance failures surfaced in testing.
Handoff and Build
47-component design system, 19 semantic color tokens. Engineering handoff. Live deployment. Zero placeholder screens in the final product.
The paper chain that broke everything
A healthcare staffing nurse working a 12-hour shift had no single tool to manage her documentation. Her actual workflow, reconstructed from interviews, looked like this:
None of these tools communicated with each other. Every connection was a human manually moving information from one place to another. If the supervisor had already left, the nurse either waited or returned the next day.
Time cost
23 minutes lost per shift
Each worker spent an average of 23 minutes per shift on documentation that should have taken under 2 minutes.
Financial cost
4.2 day average invoice delay
The billing system was always ready and waiting. The delay was entirely caused by missing or incomplete paper vouchers.
Three findings that inverted the original assumptions
The problem was not too few tools. It was too many.
Workers were not asking for a new app. They had already built personal workarounds: WhatsApp self-messages as archives, screenshot folders by date, handwritten notebooks in scrubs pockets. The product had to replace the entire stack or workers would add it to their workarounds and ignore it.
The invoice delay was never the billing software.
Every admin participant independently said the same thing. The delay was caused by missing or incomplete shift vouchers. The billing system was idle and waiting. This reframed the entire product priority from faster billing to eliminating the documentation gap.
Admins were not managing their workforce. They were reacting to it.
Neither admin participant had a live view of which workers were on shift. They found out about problems when workers called, or when facilities complained. The dashboard had to surface problems before they became crises, not just report on what had already happened.
The assumption that turned out to be wrong: workers needed a simpler version of what operations software already looked like. The actual finding: they needed something that required almost no interaction at all. Every additional screen, field, or decision was a failure point.
The workflow we replaced
Paper mileage log filled by driver
Log submitted to coordinator
Coordinator enters data into spreadsheet
Supervisor reviews weekly
Discrepancies flagged via email
Driver re-submits corrected log
Finance exports to billing system
Invoice generated
5 to 7 days
old time from trip to invoice
Same day
with the new platform
Two users. Same data. Completely different mental models.
The most important design insight on this project was not about a feature. It was about information hierarchy. A coordinator and a field worker look at the same underlying data and need entirely different things from it.
Same data. Completely different information hierarchy. This is why both surfaces share a design system but feel like entirely different products.
One-handed use in a physically demanding environment
The constraint that shaped every mobile decision: nurses carry things, drivers have a hand on the wheel, field workers hold tools. Two free hands and a quiet environment, the standard assumption for SaaS design, was wrong for every user type here.
Why a calendar view, and why color by credential
The weekly calendar was chosen over a list view for one reason: coverage gaps are spatial. A list tells you what exists. A calendar tells you what is missing. A coordinator can see Tuesday morning is understaffed at a glance without reading a single number.
Color coding by credential rather than by person was a deliberate density decision. The coordinator needs to know if the right credential types are covering the right shifts. Color by credential lets her assess qualification coverage before reading a single name.
Alert placement
Understaffed badge is always visible, never a modal
A modal stops everything. A notification disappears. The persistent strip means a coordinator can be approving expenses and still see a staffing gap at the periphery without switching context.
Emergency fill
Sick call 30 minutes before shift, zero coordinator calls
When a shift is vacated inside the coverage window, the system pushes it to the Shift Marketplace and sends push notifications to all qualified available workers simultaneously.
The decisions that were actually hard
Complex features are hard to build. Genuinely hard design decisions are the ones where two valid approaches exist and the tradeoffs are not obvious until real users interact with both.
Three buttons or one
Workers log three types of trips: starting now, already happened, scheduled for the future. The question was how to structure the entry point.
Record a new trip, schedule a future trip, log a past trip. Clear labels, explicit control, immediately understandable to a first-time user exploring the interface.
One button. The date the worker selects determines which flow the system routes them into automatically. Past date triggers manual log. Today triggers active recording. Future date triggers scheduling.
Option B was chosen because workers in round one of testing consistently felt uncertain which of three buttons to press even after multiple sessions. Every decision is a failure point under time pressure. The tradeoff was discoverability, solved with a small contextual label below the button that changes based on the selected date: “Starting now”, “Logging a past trip”, “Scheduling ahead.”
The design that was wrong in round one
The original clock-in was a single button. Open app, tap Clock In, shift starts. It felt minimal and fast.
In round one of testing, three out of three frontline worker participants clocked in at the wrong location at least once. One clocked in from home. One clocked in in the hospital car park. One clocked in at the wrong facility entirely.
EVV compliance requires location verification at clock-in. A non-compliant clock-in cannot be billed to Medicaid. The product was doing the work and simultaneously creating unbillable shifts.
The redesign added a mandatory location confirmation step. Worker taps Clock In, app checks GPS, shows detected facility name and address, worker confirms with a second tap. One extra tap. Compliance failure eliminated.
What this taught
In a compliance-regulated product, speed cannot be the primary design value for critical actions.
The confirmation step added 3 seconds. The cost of skipping it was an unbillable shift. Speed and compliance are not always compatible. When they conflict in a regulated context, compliance wins.
The detail no one noticed
The floating action button on the mobile home screen changes its available actions based on the worker's current state. Off duty: record a trip, log an expense, add a manual entry. Clocked in: log a break, record a trip, capture an expense. Active trip: end trip only.
Not one participant commented on this in testing. But the effect was measurable. Workers were never presented with irrelevant actions. The decision fatigue from seeing options that do not apply simply did not exist.
This is the difference between a product that feels like it understands you and one that feels like software.
Context-aware FAB
Start Trip
No active route detected
Clock In
Shift start within 15 minutes
Log Trip
Trip completed, mileage not filed
Verify Visit
EVV check required at this location
The FAB reads session state on every screen load and surfaces only the one action that applies right now. Workers never see options that do not apply to their current context.
One system. Two surfaces. Zero paper.
The platform deployed across two surfaces sharing a single data layer and design system, but behaving as entirely separate products for their respective users.
Desktop, for coordinators
Dense, pattern-oriented, always 48 hours ahead
Real-time roster view, weekly shift calendar with credential color coding, shift marketplace, patient visit scheduling, and scheduling analytics. The understaffed alert is always visible at the periphery without interrupting workflow.
Mobile, for field workers
Single action, current moment, works offline
Dynamic home screen states, EVV-compliant clock-in with GPS confirmation, auto-logging trip recording, one-tap expense capture, offline sync for all critical actions. Zero training required to complete the full shift cycle.
Why parallel beats sequential every time
Manual shift coordination is sequential. The coordinator calls one worker, waits, calls another if the first declines. The marketplace is parallel. Every qualified worker sees the opening simultaneously. Fill time drops from hours to minutes because the constraint is no longer the coordinator's calling speed but the response time of the first available worker.
Workers cannot claim conflicting shifts. They cannot exceed weekly hour limits if set by the agency. The coordinator retains override authority. Every trade is logged. The system enforces the rules so the coordinator does not have to.
Full workflow replacement
What changed after it shipped
What participants said in testing
Admin participants described the dashboard as the first time they had a real-time view of their workforce rather than a reactive one. That shift from reactive to anticipatory was the core product promise, and it was confirmed before the product shipped.
The first time I opened the dashboard I could see where everyone was. I have never been able to do that before.
Worker participants in round two completed the clock-in and expense flows without any instruction or prompting. The zero-training benchmark, completing a full shift cycle without documentation or help, was met in round two and held through the final design.
Coordinator experience
From reactive to anticipatory
Problems surfaced before phone calls arrived. Coverage gaps appeared before shifts started. Coordinators described it as the first time they felt ahead of their workforce rather than behind it.
Field worker experience
Zero training in round two
If a worker picks up the app mid-shift and cannot complete clock-in without help, the product has failed its primary user. Round two confirmed that benchmark was met.
What this project taught
Constraints are more useful than principles.
EVV compliance was not a feature. It was the reason the product existed. The one-handed use constraint changed where every primary action lives on screen. Tight real-world constraints produced better decisions faster than designing freely and retrofitting later.
Client collaboration is a research method.
The first brief was too broad. The second was closer. The final requirement was precise because the client was treated as a co-researcher from the start, not a brief-giver. Every call refined the problem statement.
Documentation is not overhead. It is a design practice.
Several decisions had to be reverse-engineered from the final design rather than pulled from notes. Real-time decision logging is a design practice, not an administrative task.
What comes next
Native iOS and Android apps to replace the mobile web experience and enable background GPS trip detection. Real-time location tracking with automatic trip start and end. AI-powered shift recommendations based on historical coverage patterns. HIPAA compliance mode for healthcare deployments under stricter data handling requirements.
The system was designed from day one to support this. Every data layer, component, and interaction pattern was built with the assumption that it would need to scale beyond what the first version required.