Cognitive Dimensions of Notations (CDs)
Why Cognitive Dimensions Exist
Classical task-based methods (Cognitive Walkthrough, KLM, GOMS) assume a well-defined goal and a predictable action sequence. Many real-world systems — programming languages, APIs, spreadsheets, CAD tools, social platforms — are instead interaction spaces where users select and configure components with no single “correct” task sequence. Attempting to describe every possible task individually causes a combinatorial explosion (“death by detail”).
Cognitive Dimensions of Notations (Blackwell & Green) is the canonical broad-brush analysis technique for this situation: a shared vocabulary for discussing trade-offs in any notation-plus-environment, without needing a fixed task model.
Crucially, CDs assume there is no perfect notation. Every design choice trades one dimension against another. The value of CDs is giving designers a vocabulary to discuss that trade-off explicitly — not to find an optimal design, but to make the trade-offs visible and debatable.
The Fourteen Dimensions
| Dimension | Definition |
|---|---|
| Viscosity | Resistance to change — how much work is needed to make one conceptually simple change (e.g. changing a variable type throughout a large programme). High viscosity: every file must be edited individually. Low viscosity: a single declaration propagates automatically. |
| Premature Commitment | Being forced to make a decision before having all the necessary information (e.g. a wizard that requires you to name and save a file before you have even written anything). |
| Hidden Dependencies | Important relationships between entities that are not visible in the notation (e.g. a spreadsheet formula that references a cell on a different sheet with no visible indication of the link). |
| Secondary Notation | Extra information conveyed by means other than the formal syntax — layout, colour, whitespace, comments, annotations. Programmers use indentation and blank lines to communicate structure even though the compiler ignores them. |
| Visibility and Juxtaposability | How easily various parts can be viewed, found, and compared side by side. A system that only shows one screen at a time has poor juxtaposability. |
| Closeness of Mapping | How closely the notation corresponds to the domain it represents. A circuit diagram that physically resembles the circuit layout has close mapping; an abstract textual netlist has distant mapping. |
| Consistency | Similar semantics are expressed using similar syntactic forms throughout the notation. |
| Diffuseness | The verbosity of the notation — how many symbols or how much space is needed to express an idea. |
| Error-Proneness | The degree to which the notation’s design invites certain kinds of mistake (e.g. a command that deletes everything with no confirmation). |
| Hard Mental Operations | High demand placed on cognitive resources — e.g. needing to mentally combine several pieces of information that cannot be seen simultaneously. |
| Progressive Evaluation | Whether work-in-progress can be checked or tested at any point, even before completion. A REPL (Read-Eval-Print Loop) has high progressive evaluation; a compiler that requires the entire programme to be syntactically complete has low. |
| Provisionality | The degree of commitment demanded — can you sketch tentative, unfinished ideas, or must every entry be complete and valid? |
| Role-Expressiveness | How readily the purpose of a given component can be inferred by a reader. Well-named functions have high role-expressiveness; a variable called x has low. |
| Abstraction | What facilities exist for defining new terms or facilities within the notation, and whether the system forces early abstraction-definition. |
Notational Activities
A CDs evaluation must first identify the primary type of interaction for the system’s users, because different activities are sensitive to different dimensions:
| Activity | Description | Most sensitive dimensions |
|---|---|---|
| Search | Finding information without changing structure | Visibility, Hidden Dependencies |
| Incrementation | Adding content without altering existing structure | Viscosity matters less here |
| Modification | Changing existing structure | Viscosity, Hidden Dependencies |
| Transcription | Copying content from one notation into another | Closeness of Mapping |
| Exploratory Design | Combining incrementation and modification where the end state is not known in advance | Viscosity and Premature Commitment — this is why loosely-typed, low-viscosity languages are preferred for exploratory programming |
| Collaboration | The notation’s primary purpose is to be shared or discussed with others | Role-Expressiveness, Secondary Notation |
The CDs Exam Trap
Do not list all fourteen dimensions for every system. This scores poorly.
The correct approach: (1) identify the dominant notational activity for this system’s users, (2) select the 3–4 dimensions most relevant to that activity, and (3) discuss the specific trade-off involved — e.g. “reducing viscosity here would increase hidden dependencies, because automated propagation would obscure the connection between the declaration site and each use site.” CDs marks come from demonstrating the trade-off structure, not from definitions alone.
Expected Learning
- Explain why CDs exist as a complement to task-based methods (task models cause death by detail for interaction spaces).
- Name at least eight of the fourteen dimensions with definitions.
- List the six notational activities and identify which dimensions are most sensitive for each.
- Apply CDs to a given system by: identifying the dominant activity, selecting 3–4 relevant dimensions, and discussing the trade-offs between them.
- Avoid the “list all fourteen” trap.
Past Paper Questions
CDs appear less frequently than HE/CW/Gestalt but are explicitly part of the syllabus. The 2017 Q5(b) on “interaction spaces beyond the desktop” (Winograd’s classification) is conceptually related. CDs may appear as an analytical evaluation method alongside HE and CW.