Design Considerations

A drafting sheet of design grammar — rows of small circles open and solid, ruled hairlines, a color swatch strip, and fine margin marks, composed like a beautifully set specimen page

Two layers of thinking guide the build: the principles already baked into the plan and validated by the research, and the ideas carried forward from the original Iris OS vision document (May 2026) that haven't yet found their phase. Both are collected here so nothing load-bearing lives only in someone's head.

Standing Principles

Coordinates never live in the data. Spatial arrangement belongs to view models, which reference entities by ID. A task carries no x/y/z; the same dataset renders as list, timeline, board, or field without duplication. This is the architectural spine of the whole system — one substrate, many lenses.

Color is a language with a small vocabulary. Color means status and time — and now, quietly, invested effort. Nothing else is allowed to look like status: type is a glyph, ownership is an avatar, priority is a flag, hierarchy is position. The full grammar is prototyped in The Action.

Human judgment over computed truth. The research's strongest cross-tool finding: the best systems put a human-written sentence and a hand-picked health signal above machine-computed progress. Percentages hide risk; a person saying "content is the pacing item this week" doesn't. The OS treats the human pulse as a first-class data type.

Two products, one database. The client view is not the team view with toggles — it's a deliberately reduced product sharing the same substrate. Private by default, published explicitly, legible without explanation. Silence during trouble costs more than the trouble: the client view tells the truth calmly.

Calm means ordered, not sparse. The 2026 correction to minimalism: density and serenity coexist when hierarchy does the work. The OS aims for the dense-but-rhythmic register — everything visible, nothing shouting, one red dot where attention should go.

ClickUp stays the system of record. The OS doesn't compete with the task tool; it gives the tasks a life the task tool can't. This keeps the studio compatible with client habits and keeps the OS free to be opinionated about what it surfaces rather than what it stores.

Legibility is an acceptance criterion. The bus-factor gate — a second person must be able to author a view model — is a design principle disguised as a test. If only one person can extend the system, the old bottleneck has been rebuilt in nicer technology.

The artifact is a pipeline head, not a terminus. A meeting produces decisions, actions, moments, and relationships that flow onward — to the task system, to the field, to the client. The document is one view of the meeting, not its container.

Carried Forward from Iris OS v0.1

The May 2026 vision document held ideas the current build hasn't yet absorbed. Reviewed against what exists today, seven are worth carrying forward:

The Meeting Continuum. Past and future meetings on one line, mapped at kickoff, with assets connected to the meetings where they're discussed. Planned meetings now exist in the system, so the data is ready — the continuum is a view model waiting to be authored. Likely the highest-leverage near-term surface.

Client copy collection. The vision doc's sharpest observation: waiting for client words is the most expensive bottleneck in web projects. Pages carry a copy state; clients get one dedicated view — here are the pages we need words for, here's the brief, here's where to write. The concrete, highest-value instance of the "what we need from you" block. Belongs early.

The memory layer — global features. Project features link to global features maintained across all projects, so the system can trace "we're building a community map" back to every prior build, the meetings where it was discussed, and what it took. The compounding asset that makes the OS more valuable in year three than year one. Waits, correctly, for real project pressure to shape the schema.

The access table. Explicit tracking of credentials and access grants — "Figma shared with @sean," "Stripe dev access via email" — linkable to actions. Small, unglamorous, prevents the silent blockers that cost days across time zones.

Scales — monthly effort, not per-task estimates. "Per-task time estimation is where PM systems die." Effort tracked in a monthly rhythm per engagement gives forecasting and capacity without the estimation theater. Pairs naturally with the lavender invested-time channel in the design language — the same color at engagement-month resolution.

Goals with criteria of satisfaction. Articulated at kickoff, each with status and explicit satisfaction criteria, alongside a client-editable mission and vision. Gives the human status pulse something honest to be measured against.

The horizon shelf. The Trellis (a non-linear space for inspiration and play), the project intelligence (a Claude with full project context that team and clients can ask), person profiles, and group chat. All still good, none urgent — and the vision doc's own sequencing wisdom applies: build the spine into daily habit first, or the cultural layer stays empty.

A Tension Worth Holding

The vision doc argued for restraint — track only the tasks worth not forgetting — while the current build mirrors everything ClickUp holds. Both are right: the mirror keeps the OS honest, and the restraint lives in what gets surfaced. The design system's five sizes are the resolution — most actions live as points in the field; only the ones worth not forgetting earn a line, a card, or a room.