I once helped a team build a scheduling tool for a working day none of us had ever sat through.
You've met the result of this. The person behind the counter apologising for their own computer, clicking between screens, telling you it'll be quicker if they just write it down and sort it out later.
The Insight: A Spec Is Not a Day
Every job has two halves — the task, what the organisation specifies, and the activity, what the person does. The tradition that named them grew from a question two French work researchers, Ombredane and Faverge, asked in 1955: not just what a job requires, but how it actually gets done. Most software procurement still hasn't caught up.
A requirements document is an account of the task. Someone assembles it in advance, from what they believe the job consists of. The activity is the job as performed on a Tuesday — the interruptions, the exceptions, the three things true this week that weren't last week.
Nobody has to be careless for these to diverge. The person supplying the requirements is usually sincere, often senior, and genuinely believes their account. That's what makes it hard to catch: the defect is subtler — an account standing in for an observation.
Carrying it into software bought for a sales team is my extension, not theirs.
Real-World Lens: Two Rooms
The scheduler that added steps
I worked on a scheduling tool for a company booking meetings with its customers. A vendor promised a customised solution; the team wrote the specification from what they judged the best use cases to be. Nobody checked how any of it landed in an employee's day until after launch, when staff disliked the thing: it had increased the number of steps, and added dashboards to manage and paperwork to keep. They wanted an easy way to set up a meeting and change it later. What arrived was clutter. The evaluation came after go-live — one of the most expensive places for it.
“The tool wasn't built for the job. It was built for the description of the job.”
The people who weren't in the procurement
Who takes part in decisions about buying the technology? A survey of 393 Swedish municipal elder-care staff asked. Among IT staff, 27 of the 29 had been involved. Among the occupational therapists and physiotherapists — the people whose hands are on it all day — 7 of 103 had. Small groups, so hold the ratio loosely. Being outside the buying decision isn't the same as never being watched — just the version you can count.
Before the obvious lesson: involving users is not a reliable lever. The aggregate evidence across decades of studies says it helps on balance and sometimes backfires.
Under the Hood
The trap: assuming staff resistance is just dislike of change. In 2002, before cloud CRM, Speier and Venkatesh followed 454 salespeople across two firms through a new sales tool. Straight after training, people liked it. Six months in, salespeople had widely rejected it — and absenteeism and voluntary turnover had risen. The salespeople with the strongest commitment to their profession turned on it hardest.
So don't ask staff whether they like the tool. Ask what they do instead of using it.
What the spec assumed | What the day adds | What you'd see if you watched |
|---|---|---|
The task happens once | It's set up, then changed, then changed again | A second diary the tool doesn't know about |
One place to look | More dashboards than the job needs | Screenshots pasted into email |
The record is the work | The record is what's left after the work | Paperwork batched to the end of the day |
That third column has a name — a workaround. It's about the cheapest evidence you'll collect, because it already exists — you only have to be in the room. Read it carefully, though: a workaround tells you something is in the way — not always that the spec was wrong. Sometimes the workaround is the hazard — that second diary means the official record is incomplete.
So What?
Fitted to what the job actually consists of, the same class of sales technology does raise relationship-building performance — that much is measured.
The fix isn't more consultation. It's an hour — my rule of thumb — spent watching the work before the choice closes, and the humility to expect a gap you can narrow but never quite close. That last part is my read of the tradition, not a finding I can hand you. When you find a notebook beside the keyboard, the spec starts there.
Reply and tell me: what's the workaround you've built to survive a tool you were given at work?
Next Wednesday: Why is leaving harder than joining? — the retention flow, the buried cancel button, the call you have to make just to stop paying. What a service reveals about how it values you on the way out.
Forwarded this? The Listening Loop pulls apart one invisible piece of service design every Wednesday.
See you next week.
Go deeper: Steven Alter, "A Theory of Workarounds" (2014) — open access, and it turns "people are going around the system" from a complaint into something you can actually catalogue.
Sources: