Practice / How people actually use software
Eleven principles
The gap between how software gets built and how it gets met.
1. The window for change is very small#
Habit, time pressure, fear of breaking something, and a queue of competing work mean any change runs against the instinct to keep doing what worked yesterday. A new capability has to feel like it was always there. The old path has to keep working. If the first thing someone sees after an update is an instruction to configure something, the update has already lost.
2. Cognitive load is the constraint#
The person configuring the system is the same person handling everything else that day. They have minutes, not hours. If the system can determine the right answer, it shouldn’t ask. Controls that aren’t relevant right now shouldn’t be visible.
3. Defaults are the experience#
Most people never change one. For the majority the default is the product. Spend the time there rather than on the customization nobody opens.
4. Recognition over recall#
People recognize their own data instantly and have to work to recall system concepts. Show real names, real dates, real values. A picker of existing values beats a text box. Never show an internal identifier where a human name exists.
5. Prevent the error rather than handling it#
Ask how someone never reaches that state, rather than what the error message should say. If a screen can be empty, populate it. If a prerequisite can be missing, create it silently.
6. Consistency trains intuition#
A pattern learned once is expected everywhere. Every inconsistency costs learning time twice: once to notice, once to remember which context you’re in. If something looks different, people assume it works differently.
7. Administrators think in scaffolding#
People provision structure before populating it. Create the roles, then configure the rules, then assign people when they’re hired. Creating something nobody can see yet is preparation. The system shouldn’t warn about it.
8. The response is the data#
In systems built around forms, the identifiers and dates are metadata. The content is in the answers: what was inspected, who was checked, what failed. That’s usually the one thing the interface won’t show you.
9. Immutability protects trust#
A completed record is historical truth. If it can be quietly overwritten by an automated process, nobody can rely on any of them. When something is complete, it’s complete.
10. Or for access, and for restriction#
Human intuition is inclusive about audiences and restrictive about filters. Show this to teachers or to the kitchen team. Show records that are open and overdue. Swapping those two produces confusion that’s very hard to debug from the outside.
11. Outcome thinking versus implementation thinking#
One mode asks what value goes in this column, what happens in edge case X, which page types are supported. The other asks what a person needs to see, how to prevent X, and which pages hold data worth filtering. The gap between those two modes is where specifications fail, and a prototype with real data is the cheapest bridge across it.