Design Manager
Design System
A clean, durable system for Krown’s local design operations — dense, calm, practical, and fast to scan. This app is the source of truth: the tokens, icons, components and motion you see here are a typed registry, and the stylesheet, this documentation, the audit and the distribution feed for every krownmanager.com app are all generated from it.
Executive recommendation
Build the Design Manager as a calm operational instrument, not a branded design surface. The rep’s job is to scan many locations, trust what the system says it did, and move on. Every decision below favors legibility and confidence over polish.
Borrow Krown’s brand confidence — the orange/black recognition — but spend it sparingly: orange marks the brand and wayfinding (the mark, the active tab, a module’s spine); black gives structure and carries the single primary action on a screen; everything else is warm neutral. Color earns its place by carrying meaning (status, module, platform), never decoration.
Standardize four things immediately — status language, platform indicators, the field row, and the card — because they repeat across every surface. Lock those and the product can grow for months without sprawl. Keep Intake conversational and Translation safety-first; let everything else inherit the same small kit.
one registry · four outputs
Design principles
Six rules that resolve most day-to-day design questions. When in doubt, optimize for the rep mid-task with twenty locations to clear.
Scannable before beautiful
Density is a feature. Tighten lists, align labels, kill decorative chrome. The win is fewer scrolls and faster recognition — not whitespace for its own sake.
Color carries meaning
Orange = brand & wayfinding. Black = structure & the one primary action. Green/amber/red/grey = status. Quiet hues = module. If a color isn’t saying something, it’s noise — remove it.
Trust through plain receipts
Always show what was understood, what will happen, and what happened — in human language with platform links. No developer logs, no silent success.
Safety scales with stakes
Publishing and translation are irreversible-feeling acts. Make them deliberate: clear review, explicit confirm, honest “manual desk task” labels for Apple & Bing.
One small kit, reused
New surfaces should assemble from existing primitives — card, row, chip, button. Resist inventing a component when an existing one bends to fit.
Calm, not corporate
Warm neutrals, hairline borders, restrained motion. The tool should feel quiet and dependable — a workbench, not a dashboard demo.
How the system is organized
Foundations feed elements, elements compose into objects, objects assemble into components, components fill pages. Governance keeps the whole thing honest.
| Section | What lives there |
|---|---|
| Foundations | Colour, typography, spacing, radius, borders & elevation — the token layer. |
| Motion | Easing by job, duration by size, three user-selectable paces. |
| Motion lab | The staging ground — currently all clear. Where every behaviour lives now, and what was decided against. |
| Design lab | Sandbox for forking real components — token, CSS, and motion overrides previewed safely against canonical. |
| Iconography | The Krown K, platform marks, and the thin/filled icon library. |
| Elements | Indivisible atoms — buttons, links, fields, chips, tiles, stars, quotes. |
| Objects | Small molecules — field rows, bylines, facets, metrics, dotlines. |
| Components | Assembled reusables — header, cards, checklist, feed, states. |
| Dialogs & overlays | The glass modal, scrim, entrances and the overlay family. |
| Pages | Full screens assembled from the kit — the Reviews tab. |
| Application | Accessibility, guardrails, what is locked and what stays loose. |
| Audit | Registry-driven coverage — every token, icon and class reconciled against real usage. |
| Distribution | Versioned exports and how consumer apps stay in sync. |
| Publish | Promote a ready Labs experiment into the canonical registry — classifier, blast-radius, shared-vs-scoped decision per change. |
Transparent by construction. There is no styling in this application that
the system does not document: product classes (km-*) and the doc shell’s own
chrome (ds-*) are both registered, and the audit reconciles the registry against the stylesheets and
real usage on every page.
Krown Design Manager · Design System v2.7.0 · Internal operational tool — no live CMS/platform write behavior is implied by this document.