It happens every Monday. The system goes live, training was done the week before, and the process map is printed and stuck to the wall near the dispatch desk. By Thursday, the old WhatsApp group is active again, someone has reopened the shared spreadsheet, and the operations manager is manually reconciling two versions of the same numbers.
Nobody sabotaged anything. Nobody refused to adopt. The workflow simply did not survive contact with a normal week.
Operational software rarely fails because the code is broken. It fails because the design assumed a version of the work that does not exist. Managers describe a tidy process. Front-line staff perform something messier—under pressure, interruption, and constraints—and the software refuses to model that reality.
The 70% Rule (That Hasn’t Budged)
According to McKinsey’s research on large change programmes, the failure rate sits at roughly 70 percent—a figure that has stayed stubbornly consistent for years.
If the cause were technical, it would have improved as tooling improved. It has not. The cause is behavioural, and behavioural causes do not respond to better frameworks.
1. The Happy Path Fallacy
In software engineering, the happy path is the default scenario—no errors, valid inputs, no interruptions. It is a useful testing concept and a catastrophic design assumption. As TechTarget defines it in happy path testing, the approach is tightly scripted, does not reproduce real-world conditions, and verifies only that the required functionality exists.
Operations is not a series of happy paths with occasional exceptions. Operations is a series of exceptions with occasional happy paths.
Consider a single day in a mid-sized Kenyan distribution business. A customer pays sixty percent by M-Pesa and settles the rest in cash three days later. A delivery arrives with 47 of the 50 crates on the invoice. A long-standing client wants goods released against a purchase order that has not been issued yet. None of these are edge cases. They are Tuesday.
Safety researchers have a precise vocabulary for this. Erik Hollnagel’s distinction between work-as-imagined and work-as-done describes exactly the gap that kills software adoption: the further you sit from the sharp end of the work, the more delayed and less accurate your mental model of that work becomes.
2. Where the Gap Actually Lives
The gap is not abstract. It shows up in three specific, observable places.
Contextual Ignorance
A developer designs at a desk with two monitors, quiet room, and fibre connection. The user works in a warehouse aisle, in gloves, holding a torch, with a supervisor asking a question, on a shared handset with 11 percent battery.
The best evidence for what this gap produces comes from hospitals. A landmark study of barcode medication administration systems, published in the Journal of the American Medical Informatics Association, identified 15 distinct types of workaround and 31 causes for them. Nurses affixed patient identification barcodes to computer carts, doorjambs, and their own belt rings. They carried pre-scanned medications for several patients at once.
A follow-up study in the Journal of Clinical Nursing found that workload was the clearest modifiable factor associated with those workarounds. Not training. Not motivation. Load.
The Illusion of Compliance
The standard reaction to poor data is to make more fields mandatory. This reliably produces more compliance and less truth.
A required field is a tax collected in a currency the user can counterfeit. Faced with a screen that will not advance, people type N/A, TBD, or the first item in the dropdown. They select a close date three months out because the system demanded one and they will fix it later (which they will not).
Management sees a dashboard with 94 percent field completion and concludes adoption is working. What they are looking at is a compliance rate, not an accuracy rate.
According to Salesforce research, only about a third of a sales rep's time goes to actual selling, with the rest absorbed by admin and data entry. Gartner’s 2024 work found that half of sellers feel overwhelmed by the volume of technology they are required to use, and that only about a third fully trust the data in their own CRM.
Gartner estimates the annual cost of poor data quality at around $12.9 million per organization.
Shadow IT as a Survival Tactic
When the sanctioned system adds friction, people do not stop working. They route around it.
Josys estimates that shadow IT accounts for around 42 percent of applications in a typical company.
Auvik reports that 65 percent of unsanctioned SaaS applications are adopted without IT approval.
1Password’s 2025 access report found that 42 percent bypass IT specifically to get work done faster.
NETSCOUT notes that up to 80 percent of employees adopt shadow IT because they believe their preferred tool lets them work better.
Shadow IT is the most honest requirements document in the building. It is free, it updates continuously, and it is written by users voting with their own time.
When dispatch runs on WhatsApp instead of the logistics module, that is not a discipline problem. WhatsApp has read receipts, works on any handset, survives a weak signal, and is already where the drivers are. The logistics module has none of those properties. The users performed a rigorous product comparison and published the result. Someone should read it.
3. Designing for Humans First
Three practices close the gap. None of them are expensive. All of them are inconvenient, which is why they get skipped.
1. Shadow, Don’t Interview
Ask someone how they process a return and you will get the official policy. Watch them process a return and you will discover the exercise book under the counter, the WhatsApp message to the branch manager, and the spreadsheet named final_v7.
Contextual inquiry, as Nielsen Norman Group defines it, is a form of ethnographic field study combining in-depth observation with interviews conducted in the user's own environment—while they do their actual work.
A Practical Protocol:
Sit through two full shifts—including the worst kind (month end, market day, the first week of the rains, the day the internet is down).
Never ask how it works. Ask them to show you the last three they did.
Collect the artefacts. Photograph the notebook, the whiteboard, the printed form with hand-written columns.
Count the interruptions per task and note where each one happens.
Note every point where the same information is written down a second time. Re-entry is the cheapest and most reliable indicator of a broken flow.
Ask the single most productive question in systems design: When was the last time this didn't work, and what did you do? Then follow that answer all the way to the end.
2. Measure Time to Value for the Person Doing the Typing
Here is the structural problem in one sentence: the person entering the data is almost never the person who benefits from it.
The field officer types for forty minutes so the regional manager can read a report. The storekeeper scans so finance can close the month. Every one of these people is doing unpaid labour for another department’s visibility.
Systems that get adopted return something to the person doing the work, in the same session, without being asked.
Two metrics worth adopting:
Time from first login to the user's first personal win. If it is longer than one session, the design has a problem.
Unprompted repeat use in week four. Week one usage measures how well you ran the training. Week four measures whether the system is actually better than the notebook.
3. Build Paved Paths, Not Cages
Netflix calls it the paved road. Spotify calls it the golden path. The principle is the same: rather than forbidding alternatives, make the recommended route so much easier that people choose it.
It is a road, not a fence. Nobody is prevented from leaving. Leaving is just slower and lonelier.
Translated into operational system design:
Make the correct action the default and the fastest. If the compliant path takes six taps and the workaround takes one, you have built a suggestion that people will decline.
Prefill everything you already know.
Let the exception through, but capture it. Instead of blocking a transaction because a field is empty, allow it and record why.
Instrument the escape hatches. Overrides are not a compliance problem. They are your roadmap, ranked by frequency.
Tier the rigidity. Rules that protect money, safety, and regulation are walls. Everything else is guidance.
Design for the worst conditions, not the average. Offline first. Low bandwidth. Sunlight on the screen.
4. What to Measure Instead
| Adoption Theatre |
Real Signal |
| Percentage of fields completed |
Percentage of records that survive an audit against reality |
| Logins in week one |
Unprompted repeat use in week four |
| Training sessions delivered |
Time from login to the user's first personal win |
| Number of workarounds eliminated |
Number of workarounds absorbed into the product |
| Dashboard uptime |
Volume of data still being re-entered somewhere else |
| Zero override rate |
Override rate that is visible, explained, and falling |
An override rate of zero is not a sign of health. It means the overrides moved offline, where you can no longer see them.
5. The Sequence (What Works)
If you are looking at a system that is being quietly ignored, this is the order that works:
Shadow before you write a single requirement. Two shifts, including a bad one.
Inventory the shadow systems. Rank them by how often they are used, not by how much they annoy you.
Pick one task: the most frequent painful thing the front line does daily. Not the thing management most wants reported.
Give that user a win there first, inside one session, with no report attached.
Ship the paved path for that single task, with a working escape hatch.
Instrument overrides and every point of re-entry.
Widen scope only after the first task holds for a month without supervision.
The Point
A workflow diagram is not a description of your business. It is a claim about how people will behave when they are tired, interrupted, under pressure, and slightly behind. Most of those claims are false—and they are false in ways that are entirely discoverable by anyone willing to stand in a warehouse for six hours.
The systems that hold are not the ones with the strictest rules. They are the ones designed by people who watched a Tuesday.
