Software that explains itself
The real cost of a system is not the licence. It is the hours the one person who understands it spends explaining it, and the mistakes made on the days that person is away.
Picture a new starter on their first Monday at the store-room counter. Three people are waiting with kit to hand back. The screen in front of them shows a row of small icons, and nobody wrote down what the fourth one does. The person who set the system up is on leave until Thursday. So the new starter does what everyone does: hovers the mouse over the icon and waits. A little grey label flickers into view, and the moment the mouse drifts to read it, it is gone. They click. Something happens that they did not intend, and now there is a queue and a mess.
None of this is the new starter’s fault. It is a design choice, made a long time ago, that help should be something you catch rather than something you open. Hover help needs a mouse held perfectly still, so it does not exist on a touch screen at the counter or a tablet in the van. It disappears when you move, so it cannot be read slowly. It cannot be brought back on purpose. It has room for about six words, so it can never carry a warning. And because it is written once, as an afterthought, it is written in one language — usually not the one your night shift reads.
The alternative most systems offer is worse: a manual. A PDF from two versions ago, in a shared folder, describing buttons that have since moved. Nobody at a counter with three people waiting is going to open it, and the people who write software know that. The manual exists so that someone can say there is one.
Help you have to catch is help you don’t have.
So what does help look like when it is built for the person at the counter rather than for the person writing the software? A few things, and none of them are complicated.
It is opened on purpose, read at your own pace, and closed when you are done. It sits in the same place every time — beside the title of a section, at the head of a column — so that after a week you stop looking for it and just reach for it. It answers the three questions people actually have: what is this, what can I do here, and what will happen if I do. It says, before you click, when something cannot be undone. It reads the same in every language the team speaks. And it works from a keyboard and a screen reader, because the person at the counter is not always holding a mouse.
The pay-off is not really about help at all. It is about who your system depends on. When help is inside the screen, the first day does not need a chaperone. The administrator stops fielding “what does this one do?” and, more importantly, stops fielding “I thought that meant archive” after something has been written off. The team member who can only view things is told so, plainly, instead of pressing buttons that quietly do nothing. And the system keeps working on the Thursday the expert is off sick, which is the only day that ever mattered.
This is what the small (i) in GearLogs is for. Every one of them opens the same tidy card, in English and in Hebrew: what this is, what you can do, and what will happen — with a red line when an action cannot be undone. It sits in the same spot everywhere: next to a section’s title, in a column header for the colour legends, and as one legend at the top of an actions column that names every icon in one place. It lists only the actions your role has, and a control you cannot use is dimmed and says why when you click it.
The new starter still gets a queue on Monday morning. But they get through it, on their own, without breaking anything — and nobody has to ring the person on leave.
