Explain what filling it in will get you

What it is

A genuinely empty first-use experience should explain what tasks become possible after someone adds data or completes setup, what that setup costs, and which permissions or prerequisites constrain the outcome. It may show a sample of capabilities that actually ship for the current role, plan, and product version, but the sample must be labeled and kept distinct from real user data. The preview is neither a promise based on an ideal outcome nor a decorative illustration standing in for an explanation.

This treatment is specific to a first-use state in which content has not yet been established. User-cleared collections, no-match results, failed requests, and forbidden states have different causes and recovery paths; they should not all receive the same “get started” pitch.

Why it happens

A blank surface gives a newcomer little evidence about the product's structure, outputs, or value. A concrete and truthful preview turns delayed payoff into an evaluable exchange: people can see which inputs and steps are required, how long processing may take, and what they will then be able to inspect, compare, share, or accomplish. Importing data, inviting collaborators, connecting another service, and granting access all add setup cost that may determine whether starting is worthwhile.

If the preview depicts unavailable functionality, unrealistically polished data, or an immediate result the system cannot guarantee, it replaces uncertainty with a false expectation. Decorative art can change the mood without clarifying inputs, outputs, or limitations. Preview fixtures therefore need to be governed with the released capability, entitlement rules, and feature flags.

Studying it

Show the empty state to participants who meet first-use eligibility, then ask what will appear after setup, what the first action is, how many steps or how much time it may require, which permissions will be requested, and when useful output becomes available. Compare text-only explanations, annotated sample previews, and staged setup. Measure comprehension, setup start and completion, time to first value, abandonment points, permission refusal, and later task use rather than click-through alone.

Hold the setup flow, role, plan, and data source constant so a shorter import is not mistaken for better preview copy. Interview people who stop to distinguish unclear value, undisclosed cost, permission concern, untrustworthy samples, and a poor feature fit. In screen-reader and magnification testing, verify that sample labels, capability descriptions, and setup costs remain available without relying on visual detail.

Where it stops holding

A returning user's cleared state, no match, error, or access denial does not need the first-use value proposition again. If a capability requires a minimum amount of data, collaborator participation, a paid tier, a particular integration, or processing time, present that requirement instead of implying an inevitable outcome. When optional permission is declined, explain the lower-capability path that remains; if no safe alternative exists, do not invent one.

A sample demonstrates a type of output the product can produce; it cannot promise identical insight, speed, or personalization for everyone, and it must never contain real customer or personal data. The focus here is capability and cost preview in first-use emptiness. Broader onboarding must still make its value proposition clear, while permission requests separately need to explain their specific purpose and the consequence of refusal.

Applying it

Maintain a first-use capability contract containing required inputs, setup steps, permissions, likely delay, resulting outputs, minimum conditions, and known limits. Generate samples from approved fictional fixtures, mark them prominently as “Sample” or “Preview,” and distinguish them from actual content both visually and in accessibility semantics. When showing setup time or effort, state its basis and range rather than turning a variable estimate into a guarantee.

Select the preview and setup path by role, plan, regional availability, and feature flag; disclose import, connection, or permission requests before commitment. Version sample assets with the capability and entitlement configuration so a product change triggers review or removal of stale previews. Cover first-use eligibility, permission refusal, import failure, processing delay, tier mismatch, and successful population in end-to-end tests. Monitor comprehension, setup completion, time to first value, and reports that the preview did not match reality.

Related

• Within this group: [[T2.05.1 Distinguish no-data, no-match, and error states]] · [[T2.05.2 Empty states need an explicit next action]]
• Related entries: [[T2.09.1 Onboarding copy sells the value, not the steps]] · [[T2.07.1 State the specific purpose, not a generic reason]]
• Search terms: first-use empty state, capability preview, setup cost, time to first value, sample data