Quasi-cognitive Dimensions of Notations

I first learned — and briefly wrote — about Thomas R. G. Green’s ‘Cognitive Dimensions of Notations’ framework in 2020. At the time I was an engineer at Vanta, in my first year after graduating from college. Like most software startups that strike gold, Vanta ran on huge ambitions. Our goals at any given time by far exceeded our ability to measure usage, generate designs, run usability studies… in short, we needed way more product work, to run farther ahead of our product, than we had capacity to do in a traditional evidence-driven way.

Early human-computer interaction researchers addressed pressures like these, and aimed for structural and general approaches. Green’s ‘Cognitive Dimensions’ (1989) describe intrinsic properties of software products that affect their usability, properties one can identify by reasoning about user tasks even before observing real users. Green applied these to ‘digital notations,’ a broad term for graphical user interfaces as well as textual notations like programming languages or markups.

Now it’s 2026, and everything old is new again! At least for the time being, building a venture-backable software startup means building both for human users, with human cognitive processes, and a new quasi-cognitive class of users: large language models in loops, i.e. ‘agents.’

That change multiplies the challenge we faced at Vanta. Though they convincingly ape the verbal aspects of human cognition, agents aren’t really doing human cognition — when we speak of an agent’s ‘attention’ or ‘memory,’ for instance, we mean something very different from human attention or human memory, sometimes to the agent’s credit. In my work today, we’re regularly building two or more product expressions for the same underlying product model, with these separate classes of users in mind. There are more product decisions to make than before, and information is limited as ever (even as execution gets cheaper).

There’s another reason to revisit the ‘Cognitive Dimensions’ now. Language is the raw stuff of LLMs, and many of the new user-interfaces for agents — APIs, including MCP servers, and command-line interfaces designed with agents in mind — are exclusively textual representations. In 2020 it was a stretch to apply Green’s research to a modern and mostly-visual product; today, mostly-textual product surfaces abound.

The Cognitive Dimensions need some refreshing for reasoning about agents, but I want to argue the refreshing is worthwhile. I’ll introduce the classic Dimensions (from Green and Petre) and consider some later work on what makes a good additional Dimension (Blackwell). Some observations:

• Dimensions like ‘Viscosity’ are less important to agents than to humans (for better and for worse).
• Others, like ‘Secondary notations,’ are apparently more important to an agent than to a human user.
• Dimensions like ‘Hard mental operations’ refer to a very human cognitive empathy between designer and user. Replace these with objective measures.

I’ll sketch out a new dimension I specifically consider for the agent-facing parts of products: edit locality. Finally, I’ll make a case for the continued relevance of product heuristics like this despite the ready availability of agent-users for large-population experiments (‘evals’).

Green’s original sketch of the Cognitive Dimensions model begins with a basic observation: we rarely accomplish goals with complex software by proceeding linearly from start to finish. Instead, users start, stop, start again; they explore; they test out ideas noncommittally. “In general,” Green writes, “any growing structure, whether a program, a technical paper, or a piece of graphically-represented CAD, will need to be modified and rebuilt. In the old cybernetic terms, there has to be a feedback loop for error correction.”¹ Green proposes a vocabulary for comparing the feedback different notations supply to a user, so that designers can anticipate problems before they materialize and describe those problems in a shared language.

Green’s later paper with Marian Petre, ‘Usability Analysis of Visual Programming Environments,’ defines thirteen canonical Cognitive Dimensions. The authors tried to keep these orthogonal — that is, you can vary one without necessarily varying the others (e.g. you can make a program more or less viscous without affecting its diffuseness).

Isn’t this a handy pocket-sized list?

Some of these Dimensions seem like tacit value judgments. Who wants an error-prone notation? Who wants a viscous one? ‘Premature commitment’ is a bad thing by definition, or else it wouldn’t be premature. Nevertheless, Green and Petre conceive of these neutrally. We should at least try to do the same. Alan Blackwell terms this feature ‘polarity:’ “they should have interesting properties in both directions — i.e. both when present and absent.”³

In that paper, Blackwell maps a plan for how the original Cognitive Dimensions of Notations should evolve. Publishing in 2000, he gathers a handful of candidate Dimensions from the secondary literature that collected since Green proposed the originals:

Rather than endorsing or opposing any of the proposed Dimensions Blackwell focuses on the attributes that make a Cognitive Dimension useful to a software designer. He discusses meta-dimensions and meta-vocabulary. Whereas the original Green papers proposed a model for designing software, Blackwell is mired in models for models for designing software.⁴

Never forget Norm Macdonald: “Meta… I hate meta.”

We should revive the Cognitive Dimensions of Notations by returning to the original program: identifying a “small number of clear, powerful ideas, which we can pretend are orthogonal,” describing them anew for contemporary challenges and opportunities in software product design.⁵

As of July 2026, our main challenge and opportunity is that not all users possess human cognitions. Some products aren’t even primarily for humans. We have to consider dimensions of notations without focusing solely on cognition.

Consider what this means for viscosity, one of the original thirteen Dimensions. A viscous system fights the user who tries to edit anything. This makes edits more expensive, but might even make them fail altogether — a human user can get frustrated, burn out, quit without achieving their original task.

An AI agent, on the other hand, doesn’t get frustrated.⁶ An edit in a viscous interface will still cost more (in terms of tokens billed, context-window consumption, and time), but agent harnesses are overwhelmingly written to be stubborn little shits who try and try until they achieve their goal. Viscosity won’t thwart an unthinking user; we can say it’s less important to an agent, relative to the other dimensions.

If that sounds like a pure win, consider one of the candidate dimensions from Blackwell’s 2000 paper: Useful awkwardness, which forces the user to second-guess a mistaken idea. Being selectively viscous is one way to be awkward — the Dimensions are neutral, remember? A stubborn agent might go to extreme lengths to achieve a fundamentally wrong-headed goal, ignoring all the warnings implicit in the sheer effort it takes to do so. Useful awkwardness is one of the fundamental mechanisms for Safety Through Incompatibility. Applying our Dimensions predicts — correctly! — that incompatibility won’t always suffice.

Helpfully, the other Cognitive Dimensions suggest ways designers can compensate for these overeager failures. Agents won’t heed useful awkwardness, but we can compensate by making notations for agents stricter (error-proneness). We can treat destructive agent edits as premature commitments — compensate with sandboxed draft environments for incremental changes, then offer state-diff plans to human reviewers.

In some cases, we can extrapolate what a Cognitive Dimension means for an agent. Secondary notations like inline comments in code transport indispensable context between isolated agent-sessions that have no natural idea of provenance (and may not go looking for it). On the other hand, secondary notations invite clutter — a paragraph of unnecessary provenance with each minor change. Good products, operated by good agents, should strike a balance.

Other dimensions defy extrapolation. What is a hard mental operation for a computer program without a mind? I can speculate —

1. Predefined, totally-deterministic tool calls are the easiest operations.
2. Operations the agent can define once as a deterministic subroutine (e.g. an agent with terminal-use that writes a Python script) are slightly harder.
3. Operations executed through non-deterministic verbal inference are the hardest. Maybe these can be ordered by how easy they are to express in words.

We should also propose new dimensions of particular importance to agents. Recently I’ve thought about a dimension I call edit locality.

Consider a typical task someone has to complete in your product (or the distribution of typical tasks). Edit locality is the extent to which all the changes required to achieve that task in your product domain are colocated in the notation. In a notation with high edit locality, a user can inspect a complete unit of behavior in one place, and add or modify a unit of behavior in a single change. If the entities involved in a task are split between distant structures or independent collections linked by references, or if completing a task requires coordinated edits and intermediate IDs, that may be evidence of low edit locality.

Imagine a product configuration format with resources defined in one top-level list and rules defined in another, connected by ID references (typical of normalized relational database schemas or collection-oriented REST APIs). Adding one usable resource might require you add entries in both lists, observe their assigned IDs, and finally wire them together to make the resource-with-rules you needed in the first place. There’s more edit locality in a nested format, where rules live within the resource they govern — then the same change can be expressed, reviewed, and applied as a single hunk. For an agent, that might mean the difference between making three tool calls and making one. Prioritizing edit locality requires thinking carefully about the textual representations in the configuration-as-code features commonly used to make primarily human-facing products legible and mutable for agents: translating your backend API or database tables into an MCP surface by rote might yield a clumsy product with poor edit locality, even if those APIs and tables serve your internal codebase perfectly.

This is related to the Common Closure Principle in programming: things that change together should be grouped together. Of course, different tasks might need different things locally: a nested representation makes it easy to create a resource together with its rules, but making a bulk change to a rule shared across many resources puts an opposite pressure on what’s ‘local.’ In really complicated products, maybe you need multiple task-specific notations. Sometimes it’s hard to predict the distribution of typical tasks in a product before you build it; in that case, maybe agents should specify the notations they want via query interfaces.⁷ ‘Locality’ is a spatial metaphor, but agents may not interact with data the way it’s spatially laid out at rest or visually for a human user. For example, Shelley regularly edits code by writing disposable Python scripts. Co-edits that sed easily should be considered highly local in some contexts.

If you apply the Cognitive Dimensions to your product analysis, keep in mind one major difference between the kind of analysis Green started in 1989 and the analysis we’re doing for ‘agentic’ — or partially agentic — interfaces today. The Cognitive Dimensions are applied as a sort of static analysis for software designs. They’re applied to designs that haven’t been implemented, or that don’t have users, or where only a few users can be observed and questionnaire-ed in a study like Green & Petre’s 1996 study of visual programming languages. This resembles analysis of an unimplemented feature your tiny startup might or might not build. Like Green, software designers working before product-market fit need to make projections, best-guesses, about the usability of a notation, or compare the usability of several possible notations, without the luxury of observing human users directly.

Agent ‘users,’ on the other hand, are readily available to anyone with a budget. Given a candidate notation and a set of tasks, you can actually measure the agent-usability of that notation experimentally — each experiment on an ideal tablua rasa test subject! — long before you can measure human-usability. One of Green’s main motivations for developing the Cognitive Dimensions just doesn’t apply.

Nevertheless, heuristic ideas like the Cognitive Dimensions support judgment-calls upstream of those experiments: in deciding what tasks are hard enough to represent, which candidate designs to compare, and how to categorize different kinds of failures. These aspects of evals — along with predicting the model/harness population that will actually use your product — remain tricky. Good thing we can share a vocabulary instead of always inventing new ones.