A creative brief manager that looks like the brand you're working in.

The day of a solo freelance designer.

Tuesday morning, a fintech client — cold navy, sharp serif. By lunch, an indie skincare brand — warm peach, editorial type. Hours inside those brands in Figma. Then the brief manager opens, and it's all the same gray SaaS chrome.

The tools that should help you stay grounded in each client's context strip that context away. The brand work happens in brand-shaped containers; the meta-work (briefs, references, deliverables) happens in a beige room.

"Project tools look the same no matter who you're working for. Brief looks like the brand you're working in." — the premise

The tool can be the context cue.

If the surface itself confirms which client you're working in, the cognitive shift happens at the level of the room you're sitting in — not inside your head.

Theming isn't decoration here. It's load-bearing. It's the product premise. Which means the engineering has to support it from the foundation, not bolt it on as a skin selector.

Three decisions that shaped everything.

Locked before any pixels: who Brief is for, how theming gets created, how big the surface area is. Each pick narrowed the design space.

Drafting Table.

One override mechanism, four layers.

Per-client theming is a single CSS attribute scope, not a skin selector. No per-client React components. No switch statements in JSX. Swap the active client and the entire surface re-themes — the foundation does the work.

/* L3 — concrete client overrides */
[data-client-theme="dandy"] {
  --client-bg:           oklch(0.985 0.005 250);
  --client-accent:       oklch(0.32  0.130 260);
  --client-display-font: 'IBM Plex Serif', serif;
  --client-radius:       3px;
}

[data-client-theme="sundial"] {
  --client-bg:           oklch(0.965 0.025 60);
  --client-accent:       oklch(0.65  0.150 35);
  --client-display-font: 'DM Serif Display', serif;
  --client-radius:       16px;
}

Theme switch in 420 ms.

Hit ⌘K, pick a client. Colors morph through CSS transitions over 420 ms ease-out-quint. Content cross-fades on top of that — old fades out at 140 ms with a 3 px lift, new fades in at 220 ms with a 4 px settle. Colors lead, content follows.

The choreography matters because this is the demo. Every other animation in Brief stays restrained (150–250 ms, ease-out, state changes only). The theme transition earns the longer beat because it's the product's premise made visible.

/* The whole transition hookup */
[data-themed] * {
  transition:
    background-color 420ms var(--ease-out-quint),
    color 420ms var(--ease-out-quint),
    border-color 420ms var(--ease-out-quint),
    fill 420ms var(--ease-out-quint),
    stroke 420ms var(--ease-out-quint);
}

Four clients, four worlds.

Mock client roster spans warm/cool/bold/earthy — chosen so theme swaps are visually dramatic and the token system has to handle real range, not nudges from a single base.

Surface inventory.

Every surface lives in one of two registers: chrome (the Drafting Table dark stage) or themed (the active client's world). The tag below each card calls out which.

Design intent and engineering architecture, written together.

For UX engineering work, three things live or die together: a design premise worth building, a token architecture that supports it, and motion that makes the moment readable.

The "client themes adapt the surface" idea only works if the token system is built to support it from the foundation. The token system only matters if there's a design idea that demands it. The 420 ms theme transition only feels intentional if the rest of the motion stays restrained. None of these can be back-filled.

"Per-client theming is one CSS attribute scope, not a skin selector."