Will my team actually use the new system?

The short answer

People use a system when it makes their day lighter and stop when it makes it heavier. The old sheet wins whenever the new tool is slower for the task someone does a hundred times a week.

Why operations leaders ask this

You’ve seen this movie. A tool is bought or built, everyone is trained, and six weeks later the real work is back in a spreadsheet and a WhatsApp group. The system is still paid for and still half-empty. What makes it hurt is that the data you wanted from it isn’t there.

What good looks like

1. Start from the work, not the feature list. Watch three real people do their day. Write down the five tasks each role does most often. The screen should serve those five.
2. Show each role only its own tasks. If a front-desk user sees fifty options for five jobs, they’ll hunt, and then they’ll stop. A role-based layout isn’t decoration. It is the main adoption lever.
3. Enter each fact once. The moment someone has to type the same thing into the system and into a sheet, the sheet becomes the real record.
4. Test with the people who’ll use it, on a busy day, not a quiet one. A system that works at a demo can fail at 11 a.m. on a Monday.
5. Name a retirement date for the old record. Run old and new in parallel for a short, fixed period, then stop using the old one. Without a date, two systems run forever.
6. Give one person per role the job of champion during the first weeks. Their job is to collect friction, not to enforce use.
7. Measure one task per role, not logins.

How we designed for it

On the clinic-queue platform we built, each role sees only its own work. Reception has one login and a tab per doctor, and every action applies to the doctor on the tab in front of them. Check-in and emergency walk-ins belong to reception alone. Doctors can start and end their consultation, take a break, and call the next patient in, and that call-in never changes the queue itself. So a doctor’s tap can’t scramble reception’s order. The patient sees only their own position and wait.

When an emergency walk-in arrives, reception inserts them right after the consultation in progress and the rest of the queue renumbers. The aim of that rule is that the front desk doesn’t have to rebuild the order by hand while patients wait.

Alerts go out only when a patient’s position moves meaningfully, so the messages stay worth reading and people don’t mute them.

What we haven’t tested. All of this is design intent. We have no real front-desk usage yet, so we can’t say whether reception stops answering “how many before me?” calls, or whether patients arrive closer to their turn. Those are guesses we want a clinic to measure. Until then we’re saying how we designed for adoption, not that we got it.

Where this doesn’t apply

Questions to ask any vendor, including us

1. What are the five daily tasks per role, and where did you get them from?
2. Will you watch our people work before you design a screen?
3. Which facts will be entered once, and where do they flow?
4. What is the retirement date for the old sheet, and who owns it?
5. What single measure per role tells us in week four that people are using it?

Next: what a tech handover should cover and what should go in version 1. Part of the guide Buying custom software and hiring a tech vendor.