Choosing a mode
This is a spec: descriptive guidance, not a checkable rule. It carries no forbidden and instead pair, and no jig check detector applies to it directly.
The spec
- 1.If the project config declares a mode for this route or surface, use it.
- 2.If not, infer from the signals below and state the inference in one line before building.
- 3.If the signals conflict, ask. Do not guess — the density decision is expensive to reverse.
| Signal | → mode |
|---|---|
| Visitor arrives from search or a link, may never return | editorial |
| User has an account and a task | product |
| User is doing this job all day, knows the system, uses the keyboard | operator |
| Content is primarily prose or media | editorial |
| Content is primarily records, rows, filters | operator |
| Success is measured in comprehension or trust | editorial |
| Success is measured in task completion | product |
| Success is measured in throughput or error rate | operator |
The one-sentence distinction
editorial optimises for first use. operator optimises for the thousandth. product sits between and must serve both.
When a mode decision is genuinely ambiguous, resolve it with that sentence rather than by taste.
Mixed projects
Mode is a property of a surface, not a project. A single site routinely spans all three: marketing pages (editorial), an authenticated app (product), an admin area (operator).
At a seam between modes:
- Brand stays constant. Same palette, typeface, logo, radius personality.
- Density, type scale and motion switch cleanly at the route boundary.
- Never blend two modes inside one view. A dense table inside a spacious marketing page is a mode error; give the table its own surface or redesign it as editorial content.
- Kind
- Spec
- Section
- Interface modes