The Human Should Not Have to Think Like the System
Complexity belongs to the system before it belongs to the human.
Start With the Human — Do not begin with the product. Begin with the person.
Software often exposes its internal model to the user
Fields, statuses, permissions, folders, roles, objects and workflows are often how a system organizes itself, not how people think about their work.
When the internal model is exposed directly, users must learn architecture before reaching intention.
Internal structure should not automatically become human structure.
Users should not need to understand the database to achieve an intention
Someone trying to send a proposal, manage a project, store information or share a profile does not need to understand records, relations, schemas or storage models.
If the system requires internal concepts for simple outcomes, complexity has been exported to the wrong place.
Users should understand their goal, not your architecture.
Internal complexity is not user responsibility
A system can be very complex inside, and sometimes that complexity is necessary.
But backend complexity is not a reason to make the human carry the same complexity at the interface.
Complex systems can still create simple human experiences.
Good defaults are a form of empathy
A good default reduces the number of decisions users must create from scratch.
It does not remove control. It says the system has understood enough context not to make you start from zero.
A good default is a small act of understanding.
Progressive disclosure lets complexity appear at the right time
Not every option must appear immediately. Advanced controls can surface only when context makes them useful.
Good products do not hide capability. They sequence capability around human need.
Show complexity when it becomes useful, not when it merely exists.
System language should stay close to human language
If users think in projects, do not force them to think in objects. If they think in people, do not force them to think in records. If they think in tasks, do not require technical states.
Naming is part of product architecture.
Use the user’s mental model before asking them to learn yours.
Good technology absorbs complexity instead of exporting it
The system should connect data, preserve context, choose defaults, manage state and clarify consequences whenever it reasonably can.
Humans should spend attention on intention, judgment and meaning — the parts machines should not replace.
Good technology absorbs complexity instead of exporting it to the user.
To me when I want to explain the system instead of simplifying it
If I ever write a long tutorial just to make users understand a flow, I want to ask whether the problem is truly the user.
Documentation may be necessary. But the product may also be exposing an internal logic the system should have hidden.
Good explanation helps. Correct simplification helps more.
Do not teach the user your complexity before asking whether they should ever see it.