Low Cognitive Effort

I've delivered work that looked good and work that could, in principle, run an entire operation. Neither of those facts predicts whether it gets used. What predicts it is whether the person in front of the screen can finish what they came for without having to think hard. If they can't, they go back to the phone call and the paper diary, and everything that was built becomes an expensive screenshot.

So the measure I use is effort: how much reading, deciding, remembering, typing and going back it costs to complete one real task. Not how many features exist. Not how current the layout looks. Effort, counted on the side of the person who built none of it and has no reason to care how it was made.

Effort is invisible in a demo. Nobody abandons a form while you're standing next to them explaining it. That's why a demo that goes well tells you almost nothing, and why I try to put the thing in front of real people, doing a real task, slightly before I feel ready.

The chain is short and it isn't a theory. Less effort means more people reach the end. People who reach the end are usually satisfied — not because anything delighted them, but because it cost them nothing. And people who weren't made to pay in attention come back, because next time the same errand is a known quantity instead of something they put off.

Inside the business it works the same way. Staff abandon internal tools for exactly the reason customers abandon a checkout: the tool asks for more than the task is worth. Once the effort drops below the point where somebody thinks 'faster to just call them', the tool starts being used — and only from then on does anything it can do actually count.

If you want to know what a page is costing you, do the arithmetic yourself, on your own numbers: take the decisions you ask a visitor to make before they can finish, and ask how many of them you could make on their behalf. That subtraction is the whole job. I'm not going to tell you what percentage it moves — I don't know, and neither does anybody who quotes you one.

The rules I work by are boring, and that is the point. One screen at a time: no page that asks three unrelated things at once. One obvious action per screen: if a person has to scan the page to work out what they're supposed to do next, the screen has already failed. No decision requested before it's needed — questions arrive when they become relevant, not stacked into a wall of fields at the start because that was easier to build.

And the rule that removes the most work: whatever the system can decide, the system decides. The current price. The free slot. The format the office needs. The language the visitor is already reading in. Every one of those is a question somebody would otherwise have to answer, and every one of them the machine answers better, because it already holds the answer.

That's where the time comes back. Not from a clever feature — from questions that never get asked.

A process with an exception every third run doesn't become reliable because you automated it; it becomes an unreliable process with a program attached and somebody permanently on hand to patch it. So the first pass is always to sit with what actually happens — who does what, in which order, and where it jams — and to cut the steps that exist only because nobody has questioned them since the year they were introduced. Automating a bad process is the surest way to make it permanent.

The second half of the same discipline is watching rather than asking. The owner describes the process as it's supposed to work; the person at the desk performs it as it really works, and the two accounts never match. I look for hesitation, for the moment somebody scrolls back up, for the field they always fill in wrong, for the shortcut they've built themselves in a private spreadsheet.

Nothing is finished when it goes live. It's finished when I've watched somebody who was never trained on it get to the end on the first attempt, without asking me anything.

Praxis-Link is booking without a conversation: the client picks a free slot from live availability, uploads the documents that are required, and receives confirmation immediately. No call back from the desk, no waiting to hear whether the time works.

For a wholesaler I built an ordering portal for their dealers. Instead of ordering by mail and telephone, the dealer works from the current price list and sends the order from there; the office receives it already in the format it needs, rather than as a message somebody has to read, interpret and retype.

For Dolomit shifts, absences and locations sit in one place, and the rules are written down once instead of being remembered by whoever happens to be handling the schedule that week. For Daniel Socin an enquiry is a few lines that fill themselves in from a phone, and a phone assistant answers while he is behind the camera and can't.

None of that is technically remarkable, and none of it was meant to be. It's the same move four times: take the effort off the person who came to you, and put it on the system, which was built to carry it.