Don't assume concepts the user doesn't have yet

What it is

Progressive introduction of product concepts starts from the task and data already at hand, then uses direct language, concrete examples, and in-place definitions when an internal term first becomes necessary for action. It neither assumes that a new user understands internal models such as workspace, sync, or rule nor treats everyone as completely ignorant. Domain knowledge, migration source, and observed use can only suggest possible explanation needs; they do not independently prove mastery. Reduce explanation based on explicit choice or direct evidence of understanding in the current task.

Why it happens

After a team uses internal concepts for long enough, it stops noticing the objects, relationships, and consequences behind the words. A bare term forces guessing, and a wrong guess contaminates the later mental model; a complete glossary dumped at entry exceeds current need. Task language names the user's goal, an example connects an abstraction to the current object, and progressive definition appears when the concept changes the next action. If the system already holds authorized projects, roles, or settings, those can demonstrate the concept more directly than an unrelated invented tutorial.

Studying it

Map concepts required by core tasks and their dependency order. Ask first-time, migrating, practiced, and differently experienced users to explain objects, relations, and consequences in their own words. Compare bare terminology, plain-language reframing, examples, and progressive definitions on first correct action, concept transfer, help seeking, and recovery. Record actual prior knowledge and task experience instead of substituting age, job title, or education. Test practiced users for explanatory noise and slowdown.

Where it stops holding

Common domain terms may appear directly when evidence shows the intended audience knows them; a product-specific concept still needs its meaning established at least once. Plain language must not falsify professional precision, so retain the canonical term with definitions, examples, and details when needed. Material privacy, permission, and security consequences cannot wait until after action. Existing user data may be used only within current permission and presentation purpose, never to infer unrelated traits for personalized teaching.

Applying it

• Maintain a concept dependency map with user task language, product term, definition, positive and negative examples, first necessary location, audience evidence, version, and owner.
• At first use, sequence task expression → term → current example, then abbreviate within local scope. Keep explanations adjacent or programmatically associated for keyboard and screen-reader use rather than relying only on a tooltip.
• Generate examples from authorized project names, roles, or settings. Without data, use clearly marked fictional fixtures and never present a system inference as user fact.
• Let people who explicitly skip or successfully complete the relevant step in the current task collapse basic explanation, while keeping key definitions visible, collapsible, or reopenable at any time. Regress concept order and comprehension after rename, role change, localization, and assistive-technology presentation.

Related

• Same group: T2.09.1 Onboarding copy sells the value, not the steps · T2.09.2 One point per screen
• Adjacent: T1.05.2 Expand on first use or offer an explanation affordance · T1.07.2 The target reader decides acceptable complexity
• Search terms: product concept introduction · task language · progressive definition