NO TRAINING NEEDED · PRODUCT AND PROCESS
The system that needs no training — how to spot it before you pay
Nobody sells a system as complicated. They are all simple, all intuitive, and all look wonderful in the demo. The difference turns up two weeks after the training session, when the colleague who missed it has to do something on her own — and picks up the phone to ask. This article is about that moment, and about how to see it coming before you sign.
Why "easy to use" on a sales page means nothing
Whoever demonstrates a system has pressed the same buttons a thousand times. In their hands every system flows, because they are not searching — they know. The question a demo answers is "can it be done?", and the answer is almost always yes. The question that matters to you is a different one entirely: will the person who does this once a month find it without asking?
So "simple" and "intuitive" on a sales page are not information. They are a promise, and every vendor makes it. Testing it means crossing from the seller's side of the screen to the user's — and not the enthusiastic user who chose the system, but the one who has to live with it.
Training is a symptom, not a service
Vendors present training as part of the package: three sessions, a video library, a PDF manual. It sounds like good service. In practice, long training is usually a sign that the knowledge needed to run the system is not inside the system at all — it is in the heads of whoever sat through the sessions.
And heads leave. The person who was trained goes on holiday, changes role or resigns, and their replacement learns from whoever is left — a shortened version, full of shortcuts and anxieties. Within a year the business is using a fifth of the system, and the rest of what it paid for has quietly been forgotten.
Usability research has a plain name for this: recognition versus recall. A good system lays out what you can do, so you only have to recognise it. A system that needs training expects you to remember — which menu, which code, in which order. Busy people are good at recognising and poor at remembering, and that is not a failing on their part; it is how all of us work.
Five signs you can check in twenty minutes
1. The everyday action is on the first screen. Whatever happens twenty times a day — taking in a customer, recording a payment, closing a task — should be visible straight away, with no menu and no searching. If the daily action is hidden three clicks deep, every day starts with a hunt.
2. The words are yours. "Entity", "record", "sync", "user profile" — those are programmers' words. Your business has customers, files, orders and appointments. A system that speaks your language saves a translation on every click, and people who are not technical feel it was built for them rather than against them.
3. Mistakes can be undone. The great fear of a hesitant user is breaking something. A system that lets you undo, keeps drafts and only asks "are you sure?" when there really is no way back invites people to try. A system where every mistake is final teaches the team not to touch it.
4. The system says what just happened. "Saved", "Sent to the customer", "Payment received". Without a clear confirmation, people click again — and now there are two invoices — or they phone someone to check. One of the longest-standing usability principles is exactly this: users should always know what state the system is in.
5. Few mandatory fields. A form with twenty starred fields is an invitation to invented data: people type "1111" just to get past it. Anything the system can work out for itself — the date, the logged-in employee, the customer from the previous screen — it should fill in on its own.
| What the demo says | What to actually check |
|---|---|
| "It's intuitive" | Someone who has never seen it completes a daily task unaided |
| "We offer full training" | How long a new starter takes to begin working without it |
| "Everything is customisable" | Who customises it, what it costs, and what happens at the next update |
| "There's a mobile app" | Whether the everyday action works on a phone, one-handed |
| "Support is always available" | How many times a week you are likely to need it |
The test to run before you pay
It takes less time than the demo and tells you far more. Choose three real tasks from your business: one daily, one weekly and one that happens once a month, such as the report for your accountant. Ask the vendor for trial access, ideally with data that looks like yours.
Then sit the least technical person on your team in front of the screen, hand them the three tasks in writing — and keep quiet. No hints, no pointing, no "try the top left". Note where they hesitate, where they go back and where they ask. Each of those moments is a future phone call.
You do not need a large study. Well-established research shows that five users uncover most usability problems; in a small business, two or three are enough to see a pattern. And if the vendor will not let you try before you sign, that is an answer too.
Simple is not "basic"
It is easy to assume a simple system is a cheap one, built in a hurry without much thought. It is the other way round. Every button that is not on the screen is a decision somebody made: what matters, what can wait, and what the system will do by itself so the user does not have to. Adding an option is easy. Leaving one out is much harder. We looked at what each addition really costs in more features, more mess.
When we built an expense-tracking app for a 70-year-old father, there was a single test of success: that he would use it without phoning to ask. That dictated one screen, one large button and the words he uses himself. The same principle guides our business systems: the point of simplicity is that people are still using the system a month later, not that it looks modest.
What to ask the vendor
Four questions separate a promise from a system. "How long does a new starter take to get going?" — an answer in hours is a good sign; an answer in days of training is not. "What happens when someone makes a mistake?" — ask to see an action undone. "Show me the monthly task" — not the one from the demo. "Can we change the words on screen?" — because "record" needs to become "customer".
If the answers reveal that the system only fits the way you work after a great deal of adjustment, it is worth reading from Excel to a real system, and the full sum in what it costs to keep a website or app running. Training hours, phone calls and duplicated work are real costs, even when they never appear on the quote.
How we work with this. At appotto a system counts as a success when people are still using it a month later, not on the day it launches. Before handing over, we sit with the person who will actually use it, give them a real task and explain nothing. Wherever they get stuck is treated as a bug on our side, not as "a lack of training". The quote is fixed in advance, so the time spent on simplicity never reaches you as a surprise.
Got a system your team works around, or one you are thinking of buying? Send us two lines on what it is supposed to do and what actually happens. We will tell you honestly whether the problem is the tool, the fit, or something else altogether.
Frequently asked questions
How can I tell whether a system is really simple before I buy it?
Not from the demo. Choose three real tasks — daily, weekly and monthly — and sit the least technical person on your team in front of a trial version, with no explanation and no hints. Every point where they hesitate, go back or ask is a future phone call. If the vendor will not allow a trial before you sign, that tells you something too.
Is a system that needs no training one with fewer options?
Not necessarily. It is one where the common actions are visible and the rare ones stay out of their way. It can do a great deal, as long as whoever comes in to do the daily task does not have to wade through the rest. Simplicity is a decision about priorities, not a sacrifice of capability.
What about a member of staff who struggles with technology?
Use them as the test. Someone who struggles is the best measure of whether a system is truly simple, because they will not paper over problems out of habit. If they manage the daily task on their own, everyone will. If they do not, the problem is the system, not them.
Is a custom-built system simpler than an off-the-shelf one?
Not automatically. A custom system can be very simple because it does only what the business needs, in the business's own words. It can also become complicated if every request is allowed in. Its advantage is that it can be tested with the real team before handover, and whatever trips them up can be fixed.
How long should it take a new starter to begin working in the system?
For the daily tasks, an hour or two — not days. A new starter needs to understand the business, not the software. If the vendor talks about several days of training before anyone can start, the knowledge probably lives in the training rather than on the screens, and it will be lost every time someone leaves.
Sources
- Nielsen Norman Group — 10 usability heuristics — the classic list of principles for an interface people can use without explanation, including showing system status, speaking the user's language and letting them undo mistakes.
- Nielsen Norman Group — recognition versus recall — why an interface that shows the options is easier than one that expects users to remember them.
- Nielsen Norman Group — why you only need to test with five users — the basis for a small, quick test with real people before a decision.
A system your team can manage on its own?
Tell us what your people do on an ordinary day and where they get stuck today. We will tell you whether an existing tool can solve it, and if not, you get a clear direction and a quote fixed in advance. First consultation free.
Email us