The interface should ideally work without documentation

What it is

Help and documentation is a support layer, not a substitute for the primary flow. An ideal interface lets a first-time user complete the core goal through task language, visible options, status feedback, sensible defaults, and recovery paths; documentation exists for complex rules, exceptions, administration, and later lookup. The test is concrete: put an untrained user in front of the interface, give them no instructions, and see whether they can complete the core task on their own — every point of failure should first be treated as an interface defect to fix, not something to wave away with "we'll explain that in the docs."

Why it happens

The real order of events is that users probe the interface first and only look for help once they get stuck — not the reverse. Requiring a manual to be read before acting front-loads the learning cost before the task even starts. That barely affects a committed core user willing to invest the time, but it filters out a large population who were only trying the product once, and they give up at the very first step without ever giving the interface a second chance. Documentation also has a blind spot it cannot escape: it can only describe common paths, and it cannot enumerate every permutation of permission, data state, and version difference a user might land in — the interface itself must carry enough cues (what is the current state, what can be done next, why is this button disabled) or even the most complete document will not match the specific situation a user actually hits. Being self-explanatory pays off in more than saving one search: it simultaneously lowers training cost, support ticket volume, and first-use error rate — three measurable outcomes of the same underlying mechanism.

Studying it

The standard method recruits untrained users who match the target profile, gives them no instructional material, and observes whether they can independently complete core tasks such as registering, creating, submitting, or recovering. What gets recorded is not just success or failure but the exact location of every help-seeking moment, the last action taken before abandonment, and a post-task probe asking "what did you think this step was for" — that probe often exposes the gap between what the interface intended to communicate and what the user actually understood. A more diagnostic design runs three conditions in parallel — no documentation, inline hints only, and a full manual — comparing first-use success rate and completion time across them to judge whether a given difficulty should be fixed in the interface itself or legitimately belongs to documentation. If the inline-hint group and the full-manual group show no meaningful difference in success rate, the problem lies in the interface's structure, not in insufficient explanation.

Where it stops holding

Complex professional systems cannot make every function intuitive: regulatory text, command-line syntax, and internal approval workflows genuinely require dedicated learning, and no interface design substitutes for that — it reflects real system complexity, not a design failure. Being self-explanatory also does not mean cramming all information into the interface at once; that typically produces information overload, trading a learnability problem for a visual-crowding problem, neither of which is better. This principle has scenes it explicitly does not cover: accessibility users relying on assistive technology already pay an extra cost just to read the interface, crisis contexts (an emergency medical interface) cannot tolerate trial-and-error learning, and low-connectivity or offline environments may fail to load the interface fully — these cases still need documentation or human support as a backstop, and no "ideal interface" alone will solve them.

Applying it

• Pick three to five genuinely core tasks and run unguided tests on them; log the first failure point in each as an interface defect, not something to resolve by writing a help article.
• Convey system capability through real object names, concrete examples, sensible defaults, and informative empty states, reducing reliance on the manual.
• Keep documentation as a backstop, but track first-use success rate for each core path as an ongoing interface quality metric, not something measured once before launch.

Related

• Same group: B3.10.2 Documentation should be searchable and task-oriented · B3.10.3 Help entry points should sit near where the problem occurs
• Nearby: B3.06 Recognition over Recall · Q3 Help and Documentation
• Search terms: self-explanatory interface · learnability · first-use test · walk-up usability