The structural level describes how functions are organized and related, the basis for navigating complex tasks

What it is

The structural level sits one resolution deeper than the functional level: it answers not "what can this system do" but "how are these capabilities organized, related, and dependent on one another" — for instance, "to export a report, you first set up a data source, then configure fields, and only then export," a sequence of dependencies among functions. This is the layer users actually rely on when a task requires combining several functions.

Why it happens

The structural level constitutes its own layer, not a natural extension of the functional level, because knowing a system can do A and can do B doesn't automatically tell you whether A and B relate to each other, or which depends on which. This is knowledge about the topology among functions, and it can't be derived from the description of any single function alone — it can only be built by watching several functions work together, or by being told explicitly. A structural-level model gets called on only when the task itself requires planning a path (what first, what next) rather than simply recognizing isolated capabilities. At that point, even a perfectly accurate functional-level model isn't enough, because it carries no information about order or dependency.

Studying it

• Paradigm: a path-reconstruction task — after users complete a complex task, have them draw or describe the functional dependencies they believe exist, and compare that against the product's actual dependency structure to assess the completeness and accuracy of the structural-level model.
• Methodological caveat: completing a task doesn't prove a correct structural-level model was formed — many tasks can be finished through trial and error or by following guided prompts. Only having users describe the structure independently, away from the interface, distinguishes "remembered the sequence of steps" from "understood the relationships among functions."

Where it stops holding

• A structural-level model is necessary only when the task genuinely requires cross-function planning — for a product with a single function or a task path the system linearly enforces (a wizard-style flow), the user doesn't need to hold a structural-level model at all, since the system has already done the planning for them.
• Once a structural-level model forms, it resists change more than a functional-level one: if a product reorganizes the dependencies among its functions (turning a formerly mandatory prerequisite step into optional), users may keep acting on the old dependency order even after seeing a new prompt, because the old structure has already been internalized as a habitual path.

Applying it

• For tasks requiring several steps combined, make the dependencies between steps explicit in the interface (progress indicators, prerequisite cues) rather than only showing what each step does on its own — so structural information can be read straight off the interface instead of pieced together through trial and error.
• How to check: watch users attempt a multi-step task for the first time without help documentation, and log how often — and at which specific step — they get stuck by getting the dependency order wrong (trying to skip a required prerequisite), to locate exactly where structural information is missing.

Related

• Same group: A7.15.1 The functional level describes what a system can do, mapped directly to user goals · A7.15.3 The implementation level describes concrete underlying mechanisms, which most users don't need and shouldn't be required to understand · A7.15.4 An interface that exposes implementation detail while omitting the structural level leaves users knowing the parts but unable to assemble the whole · A7.15.5 Documentation at different levels should target users of different proficiency
• Nearby: A7.01 A mental model is a user's internal explanation of how a system works
• Search terms: structural model · task path · functional dependency · system model levels