I built something earlier this year that worked exactly as specified. Every part of it did what it was supposed to do. I tested it, it passed, it went live.
And the people who had to use it kept hitting small snags. Not one big blocker, nothing that would show up on a list. A screen that needed two more clicks than it should. A field in a slightly unhelpful order. The kind of friction you’d never write a support ticket about.
So they worked around it, in the perfectly reasonable way people do.
I’m rebuilding it, and not charging for the rebuild, and I’ve been chewing over why that feels obviously correct rather than like a concession.
Delivered and adopted are two different events
There’s a moment where a build is finished. Everything specified exists, it’s been tested, the documentation is written. On paper, done.
Then there’s a completely separate moment, weeks later, where using it becomes the normal way people do the work. Not “we’ve been told to use it.” The version where somebody would be annoyed if you took it away.
I used to treat the first one as the end of the job and the second one as something that either happened or didn’t. That’s the wrong way round. The first one is a milestone in my calendar. The second one is the only one that has any value to you at all.
Because here’s what you actually bought. Not a system. You bought being able to see something you currently can’t. And you can only see it if the data is real, and the data is only real if people put it in, and people only put it in if it’s easier to use the thing than to go round it.
Every bit of friction in the way is a small vote against the entire investment.
Nobody stops doing admin because they’re lazy
They stop because nothing happened when they did it.
Ask someone to log their hours and they’ll do it for three weeks. If nothing ever comes back, no conversation, no decision, no visible consequence, it becomes an act of faith with no payoff. Faith runs out. It should run out. It’s a rational response to a task that appears to feed nothing.
So the friction problem and the “why won’t they use it” problem are the same problem seen from two ends. Make it harder than the workaround and people take the workaround. Make it feel like it disappears into a void and people stop, whatever the instruction says.
Both are design decisions. Neither is a people problem, though both get diagnosed as one.
What I felt and ignored
The part I keep coming back to is that I sensed it while I was building it.
I had a feeling the interface wasn’t good enough. I remember it. And I trusted a confident judgement over my own gut, and carried on, and it cost me a rebuild.
On something like how a screen feels to use, my instinct is where the actual expertise lives. I’ve watched hundreds of people use things they didn’t choose. When something feels heavy to me, that’s not a preference, it’s a read, and I should say so at the time rather than after.
Which is uncomfortable, because saying it at the time means telling someone their thing isn’t quite right while they’re still pleased with it.
What this means for how I work now
Bedding in isn’t support, and it isn’t snagging. Both of those words concede the build wasn’t finished, and they set up an argument nobody wants.
What it actually involves is sessions with your team, on the screens they’ll really use, doing the work they’ll really do, for a fixed number of times over a fixed period, agreed at the start. Not because something went wrong, but because the point of the exercise was never delivery.
The people who have to live with it are the ones who find what a test plan can’t. “It worked but it didn’t show me it worked” is not a line item on any checklist, and it’s the single most common thing I hear in week three.
I’d rather find that out with you in the room than six months later, when the data has been wrong the whole time and nobody wanted to mention it.