The functional level describes what a system can do, mapped directly to user goals

What it is

A mental model can rest at different resolutions. The functional level is the shallowest: it only answers "what can this system do," treating the system as a black box and caring only about the correspondence between its outward capabilities and the user's goals — "this app can turn text into speech" — with no concern for which internal modules make that happen, or how it's implemented underneath.

Why it happens

The functional level stands on its own, and is often the only level needed, because most users' goals are themselves task-oriented: "I want to achieve X." As long as the model correctly predicts whether doing action A will achieve X, the task gets done — there's no need to know how many modules, or which steps within them, sit behind A. A functional-level model has the lowest information density and the highest level of abstraction, and correspondingly the lowest cognitive load — which is exactly why it's the one level shared across the widest range of users, from novices to experts, while deeper levels are typically held by only part of the user base.

Studying it

• Paradigm: a capability checklist task — ask users to list everything they believe the system can do, and compare it against the product's actual feature list; both omissions and invented extras reveal the boundary of the functional-level model.
• Methodological caveat: measuring the functional-level model is vulnerable to whatever a user happens to recall in the moment; a static-survey capability list tends to underestimate what users actually know, and should be cross-checked against natural exploration behavior in a task context rather than relying on unprompted recall alone.

Where it stops holding

• A functional-level model is sufficient only when the task path is single-step or auto-guided by the system — once a task requires the user to combine multiple functions to reach a more complex goal, the functional-level model alone can't support planning a path, and information about how functions are organized becomes necessary.
• For highly customizable systems that allow deep configuration, a functional-level model can badly underestimate the user's real need space: the user is satisfied knowing a feature exists but can't judge whether it can be combined with others to produce the effect they actually want.

Applying it

• Name features and entry points to map directly onto how users describe their goals ("encrypt this document," not "enable the encryption module"), so the functional-level model can be built straight from interface copy without users first having to decode internal terminology and work backward to the corresponding goal.
• How to check: after a new user's first browse of the product, ask them to describe in their own words "what this thing can help me do," and compare it against the product's actual capability list. Low coverage points to entry naming or presentation that hasn't aligned with users' goal language.

Related

• Same group: A7.15.2 The structural level describes how functions are organized and related, the basis for navigating complex tasks · 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: functional model · black-box model · system model levels · task-oriented model