Examples are the most effective display of capability

What it is

“Can write weekly notes, revise contracts, explain code” is a claim. A short example with input and output is evidence. Example-based capability display means that, at an open language entry, the fastest material for building “what can I say” is having seen one complete say–get cycle — not reading feature names or capability adjectives. The job of the example here is display, not a fill-in scaffold that lowers start cost. That is a template’s job.

People do not first form a capability list and then hunt for examples. They induce the list from examples. Without them, open input has only the affordance “you may type.”

Why it happens

The worked-example effect in instruction holds because an example externalizes both the goal state and a path to it. A generative entry is missing the path: no menu, no command, only language. One example gives the shape of a legal input, the grain of the output, and the mapping between them. Information scent comes from the concrete: “turn this table into three charts” is a better test of whether my quarterly sheet can go in than the label “data analysis.”

Abstract labels also invite optimistic reading. “Writing assistant” can be heard as novel, memo, love letter, dissertation. An example pins the reading to the class it actually showed. Pinning too hard will later shrink use — a different problem. With no pin, discoverability never starts.

Studying it

First use, tasks chosen by the person or picked from a hidden menu. Compare three capability displays: adjective labels, a feature-name list, short examples with input and output. Dependent variables: whether attempted tasks land inside real capability, overlap between the spoken capability list before trying and the real inventory, time from seeing the entry to the first legal request. Further independent variables: whether the example includes an output preview, whether it can be dropped in with one tap.

Do not count “the task went better after they clicked an example” toward this entry — that smuggles in template scaffolding. Count only discovery: did they name or tap something the system can actually do.

Where it stops holding

People who already know which feature they want from elsewhere (a deep link in mail, a sentence a colleague taught them) get little discovery value from examples, only confirmation. Experts facing a daily tool skip examples and type jargon. Examples unrelated to the current document context get read as decoration, not capability evidence. This entry does not argue where examples should sit, nor whether help-center articles can replace in-place display.

Applying it

• Put a few complete short examples in the generate entry’s visible neighborhood: the sentence a user would say, plus what a result looks like. Do not stop at capability adjectives.
• Examples must come from real capability. Do not mix failure cases into a wall of successes. What is shown is “it can land like this,” not “it once looked decent.”
• Examples should be droppable into the field, and after the drop it should still be obvious this is a demonstration, not a decision already made for the user.
• Check: a new user looks at the entry for thirty seconds, then, screen closed, writes “what it can help me do.” Score against the real tool list. If written items match no task family any example demonstrated, the examples did not display. If they write nothing, there were no working examples on the scene.

Related

• Same group: L2.02.2 The empty state is the best place to show capability · L2.02.3 Help documentation cannot carry that job
• Nearby: L2.01 Openness of Natural-Language Commands and Its Cost · L2.03 Examples and Template Guidance · L2.09 Discoverability of What I Can Say
• Search terms: example-based capability display · worked example · information scent