Designing software for non-technical clinical staff in 2026
TL;DR
Software for non-technical clinical staff is an adoption problem before it is a feature problem. In a survey of 8638 US nurses, the mean usability score they gave their own electronic health record was 57.6 on the System Usability Scale, which the study graded F. That is the baseline your tool arrives next to in 2026.
- Use the words the floor already uses for every object and status.
- Give each role one screen with a short action list, not the full system behind permissions.
- Put the tool where the work happens, not on a laptop in the back office.
- Count completed tasks per shift. Logins per month hide the ward that stopped.
What no technical background actually means on a clinical floor
It does not mean the person is slow. It means your software is their second job.
The nurse, the aide and the case manager have a first duty that is not your app. Every second your interface costs comes out of the work they are measured on, so they route around it the moment that is faster. Rational response to a bad exchange rate, and it is the whole problem.
They are not starting from zero software either. Adoption across nursing homes, skilled nursing facilities and home health agencies passed 78% by 2018, while the same ASPE review found only 20% to 27% of skilled nursing facilities could find records held elsewhere. The building has a system. It talks to nobody, and staff carry the gap in their heads.
So you are never the first system, and people say so. One clinic software founder on Hacker News: it is so incredibly hard to get established, small businesses to do anything regarding IT or tech. On another thread a commenter told a builder he was proposing to add to their burdens, with yet another system, and called it a brick-wall learning curve.
The staffing floor came out on February 2, 2026
If your rollout plan assumed more hands, the plan changed. CMS published the repeal of minimum staffing standards for long-term care facilities on December 3, 2025, effective February 2, 2026. The registered nurse onsite 24 hours a day is gone, along with the 0.55 and 3.48 hours per resident day floors. The facility assessment requirement stays, so the documentation obligation outlived the staffing obligation.
Turnover compounds it. The 2026 NSI National Health Care Retention and RN Staffing Report puts hospital RN turnover at 17.6% and one staff RN departure at $60,090. The number that should shape your onboarding sits lower down: 22.7% of newly hired RNs left within a year.
How we built these rules
Four constraints, applied to all nine.
- Each rule prevents a failure named in a real discovery document.
- Each rule is testable within two weeks of go-live by someone who is not an engineer.
- Where we state our own numbers, any group with fewer than three data points is not published.
One disclosure. Mercury Development sells healthcare software development, so the examples are our own shipped work and the research section turns the same lens on our request log.
The nine rules at a glance
| # | Rule | What it prevents | How you know it worked |
|---|---|---|---|
| 1 | Use the floor's own vocabulary | Staff translating your labels | New users name screens unaided |
| 2 | One role, one screen | A full admin UI behind permissions | The role's screen fits one view |
| 3 | Pre-fill what is already known | Retyping data the system holds | Fields typed per task falls |
| 4 | Shortest path for the common case | Three taps for the daily action | Taps per completed task |
| 5 | Put the tool where work happens | A system tied to the office PC | Tasks finished at point of care |
| 6 | Delete the second keyboard | Double entry into old and new | The parallel spreadsheet goes stale |
| 7 | Ship configuration in release one | Rule changes becoming your tickets | Client adds a workflow unaided |
| 8 | Onboard the week-one hire | Training built for the pilot group | Time to first completed task |
| 9 | Training in minutes, in product | A classroom day nobody is released for | Ongoing training consumed |
Rules that cut what the user has to know
Start with language. It is free, and almost nobody does it.
Rule one. Write down how the work is already named, then use those names. For Precision Practice Management we documented the existing claims process from interviews with the people doing it, and the software is described as 100% compatible with the pre-existing rejection code process. The published outcome was an 80% increase in claims worked without having to hire new staff.
Rule two. Give a role its own screen rather than a filtered view of everything. That same system limits rejection codes by user class, so a caller sees a caller's codes. A permissions layer over a full interface still makes the user learn the full interface, then discover which half is refused.
Rule three. Pre-fill every field the system can answer itself. In a contest platform we built for restaurant crews at Burger King, submission fields were populated automatically and the rules appeared as tips inside the flow. It took 46272 uploads from staff whose job was assembling food.
Rules that cut what the user has to do
Knowing what to do is half of it. The rest is how many actions it costs.
Rule four. Find the action performed most often and make it the cheapest thing on the screen. Moving the MatchedFlicker imaging application to the web, we reduced comparison of two serial images to drag and drop. We also build to WCAG 2 AA and ADA requirements: on a ward, scalable text and focus indicators are speed rather than compliance.
Rule five. Put the software where the work occurs. The desktop version of that imaging product was not installed where images were captured and left payer submission as manual steps. The web migration took three months and removed the walk.
Rule six. Delete the second keyboard. Before the claims system existed the same information was documented twice, in the billing platform and in a spreadsheet that went stale across the week. Afterwards the daily import took minutes instead of hours. Adding a place to type without removing one raises net burden, however good the screen is.
Rules that make the rollout survive the second week
Rule seven. Ship the configuration screen in release one. The claims system shipped with a management interface for adding rejection codes and changing rules by practice and carrier. Without it every policy change becomes your ticket, and a tool that needs a developer for a rule change gets abandoned the first week you are slow.
Rule eight. Design the first session for someone hired last week, because over any two-year horizon that is the majority case. The 22.7% first-year departure figure above is your onboarding spec.
Rule nine. Budget training in minutes, inside the product. KLAS Research recommends 5 to 8 hours of initial training and 3 to 5 hours of ongoing training per year and reports a 90 point gap in Net EHR Experience Score between clinicians who strongly agree their initial training prepared them and those who strongly disagree. Its 2023 follow-up found 15 to 60 minute sessions work best. A small practice cannot release a nurse for a day. It can afford 15 minutes.
What to instrument, and what the numbers mean
Pick a shift as the denominator. Monthly active users is a vanity number when logging in is mandatory.
- Completed tasks per role per shift. A session ending without a finished record is pure cost.
- Time to first completed task for a new hire, from first login.
- Share of records finished in the tool versus elsewhere. The surviving spreadsheet is the honest signal.
- Corrections per 100 records. Rising corrections usually mean the vocabulary is wrong.
- Abandonment point per flow. One screen normally carries most of it.
- Help requests per 100 tasks by role. Flat after six weeks means the interface teaches nobody.
Collect all six from day one of the pilot. The comparison you need later is against week one.
Which rules matter most for your situation
A small practice replacing a spreadsheet: rules one, six and seven. The spreadsheet already encodes their vocabulary, so copy it, then let them change their own rules.
A facility adding a tool beside a record system that cannot exchange data: rules two, three and five. You compete with a system staff are obliged to use, so yours has to be faster at the bedside.
A product that stalled after a successful pilot: rules eight and nine, then the metrics. The pilot group was self-selected. The second ward is not.
What our own healthcare requests say about this user
These are our own numbers, counted by hand from healthcare and telehealth discovery records.
In around 30% of those requests the problem described was staff-side rather than patient-side: spreadsheets and duplicate entry, protocols that vary with whoever is on shift, structured capture during the visit, status nobody can see in time. Those are the projects where adoption decides the outcome.
Only around 10% said in writing that the end user has no technical background. The gap between the two numbers is the finding. This user is present in most of the work and specified in very little of it, which is how a build reaches acceptance testing with a screen designed for whoever wrote the requirements. The clearest statement we hold describes the target user as a middle-aged nurse without a technical background, for whom the application is not the main duty.
The honest limit of adoption-first design
Opinion, stated plainly. Adoption-first design cannot rescue a workflow that is wrong on paper, and treating it as a visual exercise is how teams burn a redesign budget.
The failure we see most is a pilot that succeeds and a rollout that does not. The pilot runs with the champion: technical by local standards, motivated, given slack to learn. The rollout meets the night shift and the coordinator who started on Tuesday. Pilot satisfaction measures the wrong population.
The second failure is subtler. A tool can be easy and still lose, because it added a step without removing one. Staff then run both systems, the old one quietly stays authoritative, and usage looks fine for two months before it does not.
Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The healthcare discovery records and delivery history behind this article sit in the operations he oversees.
Bring us the workflow, not the wireframe
Tell us who touches the screen, what their first duty is, and what they do today instead. We will come back with the flow we would build and the honest part about what we think will go unused.