US Health Care Nurses Case Study

US Health Care Nurses is a two-sided platform for home care. Agencies post work and staff it; nurses find jobs, bid on them, and get paid. Around that sits everything an agency has to run anyway: scheduling, clinical documentation, credentialing, billing and reporting.

I designed it end to end: information architecture across both sides, the flows, the component system, and the final UI.

Agencies were running a marketplace, a scheduling board, a clinical record and a payout ledger as four separate problems, in four separate places.

The cost showed up as a question nobody could answer quickly: who is covering this client on Thursday, are they licensed for it, and have they been paid for the last visit.

I looked at how a shift actually gets filled. The bottleneck is rarely finding a nurse. It is finding one licensed in the right state, free at the right hour, and willing to work at the rate on offer.

That reframed the core screen. Search is a constraint problem, not a directory, and price is one of the constraints. It is also why the platform needed bidding rather than a fixed rate card.

Sessions with the agency to settle the shape of the product before any screens were drawn.

Three decisions came out of it. Two full sides rather than one admin with a guest view, each with its own onboarding, navigation and dashboard. The service request as the spine everything else hangs off. And bidding as a first-class mechanic, which meant jobs, bids and payouts all needed to exist from day one.

I spoke to coordinators about their day and watched where it stalled.

Three things surfaced. They think in weeks, not days, so a day view was useless for spotting a hole in coverage. Licence state is the first filter, not a detail on a profile, because a good match in the wrong state is not a match. And an unfilled visit is the number they check first thing and last thing.

One spine, followed all the way: a client requests a service, the agency posts it, nurses bid, one is assigned, the visit is scheduled, it happens, it is documented, and it settles into a payout.

The exceptions took the longest, because that is where coordinators lose their day: a missed visit, a cancelled request, a bid that loses, a shift nobody accepts, a signature that never arrives.

Four hundred screens across two sides needed one vocabulary. One status scale covers pending, scheduled, active, completed, cancelled and missed. Each state carries the same colour in a calendar chip, a table cell and a board tile, so it is read without a legend.

The data-dense screens share one table, one filter panel, one stat tile and one pagination pattern. That is what lets a nurse's job board and an agency's request queue feel like the same product rather than two apps with a shared logo.

Nurse search changed the most. It began as a list with a search box and kept failing the same way in review: coordinators could find people, but not the right people.

It ended as a constraint panel: profession, speciality, licence state, employment type, rate, shift timing, language. The qualifying facts are lifted onto the card, so a decision can be made without opening a profile. The heat map came out of the same problem seen geographically, and bidding came out of realising that rate belonged in the negotiation, not the filter.

The marketplace is the two sides meeting: agencies filter nurses against hard constraints, nurses see open jobs with the rate and the total on the card, and bids are tracked against the winning bid so nobody is guessing.

Scheduling is the week seen sideways: clients down, days across, every visit a coloured tile, with billable, payable and scheduled hours totalled per day. Care records hold what the rest of the product refers back to: the client file, and the assessments, care plans and discharge summaries attached to it. Money closes the loop with a wallet balance and a payout history tied to the service request that earned it.

Four hundred and one screens across both sides of the marketplace: the nurse's job board and bid tracking, the agency's request queue and scheduling board, clinical records, credentialing, billing and payouts. All of it runs on one status vocabulary and one shared table, filter panel, stat tile and pagination pattern.

The status scale is the part that held. Six states, one colour each, reading identically in a calendar chip, a table cell and a board tile, which is most of what keeps a product this size coherent. No usage data came back to me from the agencies running it. The number worth watching is how many visits a single coordinator can hold before the scheduling board stops helping, because that is the scale it was bought for and the case I did not test.

Agreeing the status vocabulary early was the highest-leverage decision in the project. Every screen after it had a ready answer for how to show state, which is most of what keeps a product this size coherent.

What I would do differently: I designed the scheduling board for a coordinator holding one week in their head. I should have tested how it degrades for an agency running several hundred visits a week, because that is the scale it was bought for.