Multiple Representations
Professional software shows the same data through multiple lenses at once, echoing Mirel's observation that expert problem solvers hold structural, functional, and organisational representations of their work and need to move between them fluidly.1 A 3D application might present a viewport (spatial), a properties panel (parametric), a timeline (temporal), a node graph (procedural), a scene hierarchy (structural), and a render preview (output) — all facets of one scene. A video editor does something similar with its timeline, source monitor, program monitor, effects panel, and audio mixer. This is the norm, not the exception.
Getting these representations to play nicely together is one of the defining challenges of information architecture in complex software. When it works, users shift fluidly between perspectives, editing wherever feels most natural and seeing the result ripple across every view. When it doesn't, representations drift out of sync, changes vanish between views, and users are left manually reconciling information that should have reconciled itself.
Bidirectional Linking
The gold standard is bidirectional linking: a change in any representation is immediately reflected in all others.2 Select an object in the viewport, the properties panel updates. Change a value in the properties panel, the viewport updates. Drag a keyframe on the timeline, the viewport shows the new pose. (See Direct Manipulation for the theory behind why this matters — closing the gulf of evaluation means the result is visible without translation.)
Obvious in principle; surprisingly hard to maintain as representations multiply. The common failures are predictable:2
- One-way updates: Selecting in the hierarchy highlights in the viewport, but clicking in the viewport doesn't scroll the hierarchy to match
- Delayed updates: Changes in one view only appear in another after a manual refresh or re-render
- Partial updates: Some properties sync across views, but others — particularly metadata, annotations, or secondary notation — quietly don't
Every one of these failures forces a Hard Mental Operation: the user must now track which view is "current" and which might be stale. That's cognitive load you've introduced for free.
The Primary Representation
In most professional software, one representation serves as the primary workspace — the view where users spend the bulk of their time and do the most direct manipulation.2 In 3D tools, it's the viewport. In video editors, the timeline. In code editors, the source file.
The primary representation deserves the most screen real estate, the richest direct manipulation support, and the tightest feedback loops. Secondary representations orbit around it, providing different perspectives: parametric detail, temporal context, structural overview, output preview.
The mistake — and it's a common one — is treating all representations as equally important. They all need to be accessible, yes. But the primary representation is where the core creative or analytical work actually happens, and it deserves proportionally more design attention. Spread your investment evenly and you'll end up with five mediocre views instead of one excellent one supported by four good ones.
Toggling Without Disruption
Users toggle between representations constantly during a single workflow — checking a property value, returning to spatial editing, reviewing the timeline. Each toggle should be:
- Fast: No loading time, no re-rendering, no modal transitions
- State-preserving: The view the user returns to should be exactly as they left it — same scroll position, same selection, same zoom level
- Context-maintaining: If the user was working on a specific object, all views should stay focused on that object
Get any of these wrong and toggling becomes a tax on every workflow rather than a natural part of it.
The Split-View Pattern
Rather than toggling, some professional tools offer split views — two or more representations visible simultaneously. This eliminates toggling overhead entirely but eats screen real estate. The most effective approach is to let users choose: provide default layouts with sensible splits, but allow full customisation of which views are visible and how they're arranged. Don't force a layout philosophy; give people the tools to build their own.
Consistency Across Representations
The same concept should be visually recognisable across all its representations.2 If an object is blue in the viewport, its entry in the hierarchy should also be blue. If a keyframe is selected on the timeline, the corresponding property should be highlighted in the properties panel. Visual consistency across representations reduces the cognitive cost of switching views — users rely on colour and shape rather than re-reading labels every time they shift focus.
Where the same action is available in multiple representations (delete, rename, transform), it should work identically regardless of which view initiated it. Inconsistencies — where the same action has different behaviour or different scope depending on the view — are a significant and entirely avoidable source of errors.