In healthcare we lavish attention on the moment of care and far less on the machinery that makes it possible. Yet the intake coordinator squinting at a cluttered scheduling screen, the billing specialist re-keying the same data into a third system, and the quality analyst stitching together exports at midnight are all doing clinical work. Their tools just happen to live in the back office.
Human-centered design is often filed away as a discipline for consumer apps and patient portals. The thinking goes that the people inside the organization will adapt, because they are trained, paid and accountable. They do adapt: they build workarounds, keep parallel spreadsheets, and memorize the eleven clicks it takes to do a routine task. Every one of those adaptations is a small tax on accuracy, morale and time. Multiplied across a workforce and a year, the tax is enormous.
The back office is clinical work
Program evaluation gives you an unusual vantage point. You get to trace an outcome backward to its origins, and again and again the trail leads not to a clinical decision but to an operational one. A measure looks like it is failing on the floor when the real failure is a field that was ambiguous, a default that was wrong, or a report that nobody could run without help.
Consider what happens between a referral and a completed visit. Someone receives the referral, verifies coverage, confirms eligibility, schedules, documents, codes and reconciles. Each handoff passes through software that was usually selected for its feature list rather than for how it feels to use forty times a day. The result is a chain of systems that are individually defensible and collectively exhausting.
The eleven-click problem
On one engagement, a team was missing its timely-follow-up target. Leadership assumed a staffing gap. Observation told a different story: the action staff needed most was buried three menus deep, behind a default that had to be cleared every single time. The fix was not more people. It was moving one button and changing one default. Performance recovered within a month.
Why back-office systems get neglected
The users are captive. They cannot churn the way a frustrated customer can, so their friction never shows up as lost revenue in an obvious way; it hides inside overtime and rework. Procurement optimizes for features, not flow: a demo shows what a system can do, not what it is like to live in. Workarounds mask the problem, because competent staff make broken processes function and quietly remove the pressure to fix the design. And ownership is split, so the people who configure the system rarely do the work it supports, which breaks the feedback loop between use and design.
What human-centered design actually asks
Human-centered design is not a coat of visual polish applied at the end. It is a stance: the people who use a system are the primary source of truth about whether it works. In practice that means a few concrete habits.
Watch the work before you redesign it. Self-reported process maps describe the official path; sitting beside the person reveals the real one, including the sticky notes, the second monitor and the spreadsheet quietly holding everything together.
Design for the worst day, not the demo. Systems are usually shown in calm conditions, but real operations run during outages, surges and short staffing. A tool earns its keep when things are hard.
Reduce the cost of doing the right thing. If the compliant path is the slow path, people will route around it. Make the correct action the easy action and quality stops depending on heroics.
Most operational failures are not failures of will. They are failures of friction.