Abstract
An experienced writer opens a long document and needs to turn visually styled section labels into a real structural hierarchy before the file goes to production. The writer knows that an advanced operation must exist. The difficulty is not simply that the operation is absent. It may be hidden behind an unfamiliar label, available only through a gesture, surrounded by unrelated settings, hard to predict, or too risky to try. The question “is this tool simple or professional?” does not describe the problem.
This paper introduces capability reveal: the path through which a user can recognize, understand, try, assess, and later accelerate an advanced function. A good interface need not show every option at once. It must, however, make a relevant function discoverable at an appropriate moment, explain its likely effect, allow correction or escape, and provide optional faster routes for repeated expert work. This is a teaching standard, not a product ranking or a claim that all complexity should be concealed.
The paper develops the Capability Reveal Test, a five-part review instrument covering timing, discoverability, explanation, reversibility, and expert acceleration. Research and design guidance distinguish discoverability from successful use and warn that feature exposure requires task analysis rather than aesthetic instinct.[1] [2] A recent 32-participant study in an AI-transparency context also complicates the usual cognitive-load story: detailed information was preferred and improved perceived understanding even though it increased cognitive load, while progressive disclosure did not itself reduce cognitive load in that study.[3] The practical implication is not “hide less” or “hide more.” It is to test whether a particular function can be found, understood, safely exercised, and efficiently revisited by the people who need it.
1. The function that is “somewhere”
A writer receives a manuscript assembled from many documents. The section labels look like headings, but they are only bold, enlarged text. A production process now needs the document to have an actual hierarchy: something a reader, screen reader, editor, or conversion process can recognize as structure rather than decoration.
The writer has worked in word processors for years. They know an operation exists that can assign, promote, apply, or repair a heading structure. But where is it? The visible ribbon may show styling choices without making the structural action clear. A menu may contain a term that sounds technical or ambiguous. A palette may offer a one-click conversion but fail to say whether it will change only selected text, every similar-looking label, surrounding spacing, numbering, or an entire document’s navigation. A shortcut may be fast for someone who already knows it, but invisible to someone who does not. The writer may try an option, see a disorienting change, and decide that the safest course is to leave the document as it is.
This is a constructed authoring scenario. It does not test a named application or claim that all programs organize structural tools the same way. Its value is diagnostic. It reveals a difference between a function’s existence and a user’s practical route to it.
A capability is not fully present for a user merely because the software contains it. It becomes usable when the path to it can be recognized, understood, attempted, assessed, and, when necessary, reversed.
The common contrast between a “simple” tool and a “professional” one obscures that difference. A sparse interface may make basic tasks calm and clear while concealing consequential operations from users who need them. A dense interface may expose every option while forcing users to scan, memorize, or risk actions they cannot interpret. Neither visible feature count nor technical feature count tells us whether professional capability has been made available well.
This paper names the missing question: How does an advanced function reveal itself?
2. Beyond the simple-versus-powerful binary
Progressive disclosure is often described as a way to defer specialized or rarely used options until users request them. Nielsen Norman Group frames it as an attempt to reconcile two real requirements: users need enough power to handle particular cases, yet do not have time to study a profusion of features before doing ordinary work.[1] The essential design decision is not whether to remove complexity. It is how to divide initial and secondary functions, how to make movement between those levels obvious, and how to communicate what the next level contains.
That formulation already rejects a false binary. Complexity is not only a quantity of visible controls. It is also a property of the path a task requires. A user may face a dense panel and still succeed quickly if the controls are grouped around a meaningful task, labels set expectations, a preview explains likely results, and an unwanted change can be corrected. A user may face a minimalist screen and still fail because the operation they need has no visible signifier, only appears after an unrelated action, or cannot be safely explored.
The HCI distinction between discoverability and learnability sharpens the point. Mackamul’s 2022 CHI extended abstract describes discoverability as the ability to perceive and comprehend a system, feature, or input method when encountering it without prior awareness or knowledge.[2] It distinguishes the discoverability of a system, an interaction, and a feature. A user can understand that an application exists without finding a feature within it; a user can see a feature without comprehending how to activate it; and a user can discover an operation without using it successfully.
Discoverability is therefore not mastery. Mackamul explicitly notes that discovery does not guarantee success, while learnability extends into the ability to use a system and develop proficiency.[2] This matters for an advanced authoring function. A menu label may make an operation technically visible but leave a user unable to predict its scope. A tooltip may explain the concept but not make the action recoverable. A keyboard command may be efficient for an expert but never enter a new user’s field of awareness.
The appropriate response is not a universal interface style. It is a more demanding standard: each advanced function should be assessed as a capability-reveal path.
3. The capability-reveal model
A capability reveal has five elements. The elements are related but not interchangeable.
| Element | Question | What it protects against | What it does not promise |
|---|---|---|---|
| Timing | Does the function become visible when the user has a task-relevant reason to consider it? | Premature instruction and post-failure discovery. | One universal moment when all users are ready. |
| Discoverability | Can the user recognize that the function exists and locate a plausible route? | Reliance on hidden gestures, folklore, or undocumented shortcuts. | That the user can immediately use the function well. |
| Explanation | Can the user predict what the action will do, affect, or require? | Trial without comprehension and misleading labels. | Exhaustive documentation in every moment. |
| Reversibility | Can the user inspect, correct, cancel, or escape an unwanted outcome? | Fearful exploration, accidental damage, and traps. | That every action is costless or perfectly undoable. |
| Expert acceleration | Can a repeated user reach the same outcome more quickly without forcing the accelerated route on a novice? | Repeated menu hunting for routine work and novice overload. | That every function needs a shortcut. |
Timing
Timing is not the same as delay. A feature should not be hidden simply because it is advanced. It should become available in relation to a task state in which it is meaningful. The writer in the constructed scenario does not need a lesson about structural conversion upon opening every document. They need a recognizable route when the mismatch between visual labels and actual structure becomes relevant.
Nielsen Norman Group’s progressive-disclosure guidance recommends deciding the split between initial and secondary features through task analysis, field study, usage patterns, and observational usability testing rather than visual preference alone.[1] That advice is especially important when operations interact. A function that seems rare in isolation may be essential during a specific editorial task; a control that seems advanced may need to be visible because it changes the interpretation of a common action.
Discoverability
Discoverability requires more than a function’s technical presence. It concerns whether a person can become aware of a possible operation and understand enough to take the next step. Mackamul identifies visibility, signifiers, feedback, feedforward, consistency, constraints, and environmental context as relevant factors in initial interaction.[2] The terminology is less important here than the practical implication: a hidden possibility can remain unusable even for motivated, skilled users.
A capability reveal can offer several proportionate forms of evidence: a clear menu label, a task-linked suggestion, an inline example, a structural preview, a command search, or a reference route that does not demand mouse hovering or personal lore. The paper does not prescribe every one of these patterns. It asks whether a user can find the intended function without having to know its exact hidden name in advance.
Explanation
Explanation asks whether a user can make a reasonable prediction before acting. In the structural scenario, the relevant questions include: Does this change selected labels or all labels? Will it alter visual styling? Does it create a heading level, a navigation entry, or both? Can the change be scoped? If a design gives only a cryptic command, it may technically reveal a function while concealing its consequence.
Explanation need not be an intrusive tutorial. It can be a good label, a preview, an example, a clear scope statement, feedback after action, or a task-linked hint. The standard is predictive understanding, not maximal text.
Reversibility
People do not explore consequential operations freely when a mistaken action may create damage they cannot understand or undo. The HCI literature has commonly treated user freedom through undo as a pillar of usable computer systems; Rossmy and colleagues make this convention explicit even while investigating the special design possibilities of irreversibility.[4] The point is not that every action must be reversible. Some actions may be final because of legal, technical, social, or material conditions. The point is that irreversible or difficult-to-reverse operations require a different standard of explanation, confirmation, and recovery.
For an authoring function, reversibility can include preview, cancellation, undo/redo, a visible record of what changed, scope inspection, clear error feedback, and a route out of a focused interaction. A feature that is discoverable but frightening to try has not completed its capability reveal.
Expert acceleration
A recurrent editorial action has a different timing problem. An expert who uses it several times each day should not have to re-enter a buried sequence designed for a first encounter. Nielsen Norman Group calls shortcuts and similar alternate routes accelerators: optional paths that enable faster completion of a known action.[5] The important qualifier is optional. An accelerator should not be the only route through a task, and its existence should not force novices to study every shortcut before they can begin.
Good acceleration makes professional capability more available rather than more exclusive. A keyboard command shown alongside a menu action, a task-linked hint after repeated use, or a searchable command path can allow experts to move quickly while leaving the standard route intelligible. The acceleration belongs at the far end of a capability-reveal path, not outside it.
4. One advanced operation, two possible paths
Consider again the constructed task: transform visually styled section labels into a true hierarchy while preserving enough control to inspect and correct the result. The table compares two deliberately simplified paths. It is not a usability study and does not represent named software.
| Path | What the writer encounters | Likely design strength | Capability-reveal risk |
|---|---|---|---|
| A. The crowded direct path | A large formatting panel shows many controls at once: font, spacing, numbering, templates, levels, margins, metadata, and structural operations. | The structural action may be continuously visible to an experienced user. | The user cannot identify which control affects hierarchy, cannot predict scope, or feels unable to act amid unrelated options. |
| B. The concealed indirect path | The main surface shows only basic visual styling. A structural operation appears in a secondary area, a command search, or a task-linked route. | Initial activity may be calm; advanced control can be grouped with related options. | The user does not know the capability exists, cannot find it when needed, or reaches it only through a mouse-only/obscure path. |
Neither path is automatically correct. Path A can be professionally capable yet cognitively noisy. Path B can be inviting yet professionally withholding. The stronger path would make the structural function available at a relevant moment, communicate its likely scope, let the writer inspect a preview or result, provide a repair route, and offer a faster route once the operation becomes routine.
The unit of evaluation is not whether the secondary area exists. It is whether the writer can traverse this sequence:
- I have a problem that structure could solve.
- I can recognize that a structural operation is available.
- I can locate a route without knowing proprietary terminology.
- I can predict enough about the effect to try it responsibly.
- I can see what changed and correct it if necessary.
- If I repeat the task, I can become faster without forcing that expertise on everyone else.
The sequence makes progressive disclosure accountable. It cannot be judged only by the visual calm of the initial screen.
5. The Capability Reveal Test
The Capability Reveal Test is this paper’s original teaching instrument. It can be used by a writing-tool team, an editor responsible for a workflow, an educator designing an assignment, or an advanced user documenting a problem. It is not a validated usability scale and should not replace research with actual users. It is a structured prompt for deciding what to observe and what to ask.
| Test | Review question | Evidence to gather | Failure signal | Possible response |
|---|---|---|---|---|
| 1. Timing | Does the possibility surface when the task makes it relevant? | Name the task state and first reasonable need. Observe whether a hint or route appears before abandonment. | The feature appears too early to matter or only after the user has failed. | Use task-linked disclosure and test its trigger. |
| 2. Discoverability | Can a first-time user recognize that the function exists and locate it? | Ask users what actions they think are possible and where they would look. | The path relies on an unmarked gesture, obscure label, or external folklore. | Improve signifiers, information scent, search, or complementary routes. |
| 3. Explanation | Can a user predict what will change, where, and with what consequence? | Before activation, ask for a plain-language prediction of scope and effect. | The action is selected by blind trial or semantic guesswork. | Clarify labels, show examples, preview effect, and state scope. |
| 4. Reversibility | Can an unwanted result be inspected, corrected, or exited? | Identify cancellation, undo/redo, preview, feedback, focus escape, and recovery pathways. | Opaque result, accidental commitment, keyboard trap, or no recovery route. | Add preview, feedback, reversible steps, and accessible exit. |
| 5. Expert acceleration | Can a repeat user work faster without novice overload? | Locate shortcut, automation, or efficient repeat route; verify standard route remains intact. | Expert must repeatedly hunt through menus, or the novice screen is crowded with every accelerator. | Add optional accelerators and context-sensitive hints. |
The test should be applied to a single consequential operation, not a whole application in the abstract. “Is the product discoverable?” is too broad. “Can an editor find, understand, apply, inspect, undo, and later accelerate the operation that repairs heading structure?” is an observable question.
The test also assigns a useful burden of proof. A team that says an advanced function is “there if you need it” should be able to show how a user learns that it is there, what they expect it to do, how they recover if it goes wrong, and how recurrent users avoid needless repetition. If the answers exist only in support documentation or institutional memory, the feature is less revealed than it appears.
6. Two countercases: detail and expertise
A simple cognitive-load story would say that an interface should continually show less information. The available evidence does not support that as a universal rule. In a 2026 study of AI training-dataset explanations, Anik and Bunt report that detailed explanations were preferred and improved participants’ perceived trust, fairness, and understanding despite increased cognitive load.[3] In that 32-participant study, progressive disclosure did not effectively mitigate cognitive load, though it improved participants’ perception of learning.[3]
The study is not about authoring software, and its full methods and results were not inspected beyond the abstract. It cannot tell us which disclosure pattern is best for structural editing. It is valuable precisely because it blocks an easy inference. More detail can be meaningful; progressive disclosure does not guarantee a cognitive-load reduction; and interface design should not use “avoid overload” to excuse withholding information a user needs to make a consequential decision.
The expert-user countercase is equally important. Accelerators should remain alternate routes, not secret prerequisites, but repeated work has a legitimate need for speed. NN/G’s accelerator guidance argues that users who perform routine tasks repeatedly benefit from additional, faster methods and recommends that such methods be available but easy to ignore.[5] A design that protects a novice from every advanced control can still impose a tax on experienced editors, designers, or writers who must re-find the same command each time.
A capability-reveal standard therefore has two failure modes:
- Overexposure: all functions, shortcuts, modes, and settings compete on the initial surface, making relevant action difficult to identify.
- Overconcealment: essential functions exist only as hidden gestures, unexplained labels, deep routes, or support-document knowledge.
The right question is not which failure is aesthetically nicer. It is which path a particular task and user group can actually complete with confidence.
7. Accessibility and recovery are reveal conditions
A disclosure strategy that depends on hover, fine pointing, or unannounced focus changes can turn visual simplicity into an access barrier. WebAIM’s keyboard-accessibility guidance states that content should be operable by keyboard alone and explains that keyboard users need visible focus, logical navigation, predictable interaction, and a way to move away from focused components.[6] Its immediate scope is web interfaces. The broader teaching relevance is restrained: an advanced route should not be considered adequately revealed if it is only exposed through mouse-specific or visually implicit behavior.
The constructed authoring operation makes this tangible. If a writer reaches a hidden structural panel through a pointer-only hover state, a keyboard user may never encounter it. If a dialog captures keyboard focus without an evident escape method, a feature can become harder to leave than to enter. If focus order travels through many irrelevant controls before reaching an advanced action, a function can exist in theory while remaining costly in practice.
This does not mean every complex control must sit on the first screen. It means that a responsible disclosure design must account for how different people reach, perceive, operate, and exit the route. Keyboard pathways, focus visibility, standard interactions, feedback, and recovery are not final accessibility checks added after the interface is simplified. They are part of whether the capability has been revealed at all.
8. A practical review protocol
The Capability Reveal Test becomes most useful when it is used before a team argues about taste. A small review protocol can be run around one advanced operation:
| Step | Action | Record |
|---|---|---|
| 1 | Name the operation and the real task state that makes it consequential. | A one-sentence task definition and the potential consequence of failure. |
| 2 | Map the first-time path from task recognition to function location. | Screens, menus, labels, shortcuts, help, hints, and alternate routes. |
| 3 | Ask what a user can predict before activation. | Expected scope, effect, risk, and whether a preview is available. |
| 4 | Map recovery and exit routes. | Undo/redo, cancellation, feedback, error correction, keyboard escape, and record of change. |
| 5 | Map the repeat-user route. | Accelerator, customization, repeated action, automation, and standard-path continuity. |
| 6 | Test the route with relevant users and accessibility conditions. | Observations, task outcomes, failure points, and revisions—not an assumption that the design is self-evident. |
The protocol has a modest but important implication for professional capability. A tool need not show all of its power all of the time. It must not make power depend on insider knowledge. It should preserve a clear standard route for basic use, a discoverable path to advanced action, an explanation of consequences, a safe way to learn, and an optional faster route for routine expert work.
The goal is not less interface. The goal is a legible path from a real task to a capable action.
Limitations
This is a conceptual teaching manuscript, not a comparative usability evaluation, product review, or validated measurement scale. Its authoring scenario is constructed and makes no claim about a named application or observed user population. The Capability Reveal Test is a paper-defined review instrument; it organizes questions for investigation but does not replace empirical usability or accessibility research. Two Nielsen Norman Group sources are professional usability guidance rather than systematic evidence reviews. Mackamul’s 2022 source is a CHI extended abstract presenting a conceptual research program, not a completed validation of every proposed factor. The Rossmy et al. source was inspected at abstract level and concerns critical/physical-computing design; it is used only for the limited convention that undo/user freedom is central to ordinary interface usability. Anik and Bunt’s 2026 study was inspected through its abstract only and concerns AI training-dataset explanations, not authoring interfaces; its 32-participant result is used as a bounded counterpoint. WebAIM’s guidance is web-focused and therefore supplies keyboard/focus principles rather than a basis for claims about desktop software. Finally, a single interface cannot be presumed to serve all tasks, expertise levels, or access requirements; the paper’s method is to test a concrete function in context.
References
[1] Nielsen Norman Group, “Progressive Disclosure,” 2006.
[2] Eva Mackamul, “Improving the Discoverability of Interactions in Interactive Systems,” CHI ’22 Extended Abstracts, 2022.
[3] A. I. Anik and A. Bunt, “Designing Effective Training Dataset Explanations: The Impact of Information Depth and Progressive Disclosure,” 2026.
[4] Benjamin Rossmy et al., “Point of no Undo: Irreversible Interactions as a Design Material,” 2023.
[5] Nielsen Norman Group, “Accelerators Maximize Efficiency in User Interfaces,” 2024.
[6] WebAIM, “Keyboard Accessibility,” 2026 update.