L2.09.3examples as capability ceilingdesignresearch

People treat seen examples as a ceiling; a narrow set shrinks real use

Aliases: example anchoring · illusory capability cap · example-induced constraint

What it is

A user who sees three chips — “make it shorter / more formal / translate to English” — reads the product as a polisher, even if the model can turn a paragraph into a table, answer questions about an image, or rewrite in a role. They did not miss another door. They read the examples as a capability ceiling. A narrow set actively suppresses real use: the function is on in the backend and, in behaviour, unpublished.

This is not “too few examples, so they don’t know what it can do.” The ceiling appears when the count is adequate and every example stops at the same height. People are not short of samples; they take the tallest sample as the roof.

Why it happens

An example is both a demonstration and an anchor. The demonstration shows how to start talking; the anchor says “do not go above what I showed you.” In an uncertain open field, going out of bounds wastes a generation and makes the person look like they cannot use the tool, so the conservative policy is to stay below the example height. The same constraint shows up in programming instruction: the shape of the solution students have seen locks later attempts into that shape, even when the problem allows others.

The ceiling also feeds itself. Someone who only polishes in week one leaves a history of polishing; week two, that history keeps cueing polish. Narrow examples write themselves into habit through logs. They do not have to stay on the empty state.

Studying it

Manipulate the “maximum height” of examples between groups: one group gets only sentence-level rewrites; the other, at the same count, includes one cross-modal or cross-structure example (“turn this into a table”). The task brief does not restrict range. Dependent variables: whether attempts cross sentence-level rewrite, the highest structural layer used spontaneously, and, on a later questionnaire, “what do you think it cannot do.” The critical contrast is invocation rate for functions that were actually on, just never touched by an example.

Do not use satisfaction as the endpoint. Users whose range was suppressed are often more satisfied — they only did what the examples already succeed at. Need behavioural measures: time-to-discovery of unexemplified functions, and the know–use gap (“I knew it could, I never did”).

Where it stops holding

When the product strategy is to narrow (a dedicated rewriter, a compliance surface that only allows fixed phrasing), the ceiling is a feature, not a defect, and examples should cap honestly. Children and high-stakes domains need an explicit roof so people do not probe for out-of-scope requests. Users who already learned a higher use from colleagues, communities, or plugins will not be held down by on-screen examples; the ceiling mainly acts on isolated newcomers.

Applying it

  • Audit the highest structural layer of current chips. If they all stop at “change tone / change length,” add one example that actually changes structure, even if it is not the most frequent.
  • Split “uses you might not have thought of” from “common uses” into two rows, so the common row does not crowd the high row out of view.
  • For accounts that have only used the lowest layer for several days, swap in a higher-layer hint near the field instead of repeating the line they already know.
  • Check: take functions whose capability switch is on but that never got a chip, and look at 7-day invocation among new users. Near-zero use plus high satisfaction is a ceiling, not a function failure. Ship that function as a visible example and measure again; if use rises, the roof was the cause. If it stays zero, the problem is the capability, not the ceiling.

Related

  • Same group: L2.09.1 Natural-language interfaces have nothing to scan, so discoverability is worse than in graphical ones · L2.09.2 Examples draw the range of what is possible, so diversity matters more than count · L2.09.4 Suggestions that appear only after failure arrive past the point of giving up · L2.09.5 Capability hints must move with the dialogue; a one-shot start-screen hint does not cover later turns
  • Nearby: L2.03 Examples and Template Guidance · L2.02 Discoverability of What Can Be Said · L1.02 Expressing Capability Boundaries
  • Search terms: examples as capability ceiling · example-induced constraint · anchoring on examples

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L2.09.3