Designing Software People Don't Have Time to Learn
There is a comfortable fiction in software design: that the people using your tool will, at some point, sit down and learn it. They will read the tooltip, watch the walkthrough, absorb the mental model you worked so hard on. In a school, that hour never comes. The person opening your software is between a lesson and a parent meeting, with a queue forming at the office door. Whatever they are going to understand about your tool, they will understand in the next ninety seconds, standing up, half-distracted. Design for that, or design for nobody.
This is not an argument against depth. It is an argument about where the depth is allowed to live: never on the path a busy person has to walk every day.
The interface is competing with muscle memory
The staff you are building for already have a system that works: paper, a spreadsheet, a colleague who knows. That system is slow and fragile, but it is instant in their hands — no learning required, because they already learned it years ago. Your software is not competing with a blank slate. It is competing with a habit. And a habit that takes zero seconds to recall beats a feature that takes thirty seconds to find, even if the feature is better.
So the real question for every screen is not "is this powerful?" but "can someone who has never been trained do the most common thing here, correctly, on their first try, while distracted?" If the answer is no, the screen loses to the paper, and it should.
What "learnable in the gaps" actually requires
Building for people with no time to learn has pushed me toward a handful of stubborn principles:
- The common path is the obvious path. The thing 90% of people need 90% of the time should be the largest, plainest thing on the screen — not tucked behind a menu that rewards exploration nobody has time for.
- Names over jargon. Call it what the school calls it. If staff say "register," the button says Register, not "Attendance Record Entry." Every word someone has to translate is a tax on a person who is already late.
- Make the safe action the easy one. If the quickest thing to click is also the correct thing, people will be correct by default. If the quickest click is dangerous, someone will eventually click it in a hurry.
- Forgive, don't interrogate. A person moving fast will make mistakes. Let them undo, not justify. A confirmation dialog they dismiss without reading protects nobody.
Respecting the clock is respecting the person
Underneath all of this is a simple respect. The administrator, the teacher, the bursar — their time is not yours to spend on your onboarding. They did not take the job to learn software; they took it to run a school. The best thing my work can do is disappear into their day so completely that there was never a thing to learn, only a thing that worked the moment they touched it.
Software people don't have time to learn is not a lower standard than the polished demo. It is a harder one. The demo gets to assume an unhurried, curious user who wants to be impressed. Real work assumes the opposite — and has to win anyway.