N
Nexa Design System
AI-native design language
Previewing
Overview

Design once. Scale with humans and AI.

A shared design language for product teams and AI-assisted design workflows — where visual decisions are defined once, named by meaning, and reused consistently across products and experiences.

One system. Two consumers.

The same design decisions are structured so they can be read and reused by people and by AI. Nothing is described only in pictures: every decision carries a name, an intent and a place in the hierarchy.

{{ c.icon }}

{{ c.title }}

{{ i }}

How the system is structured

Primitives define what values exist. Semantic tokens define what those values mean. Components apply those meanings to real interface patterns.

{{ l.n }}
{{ l.label }} {{ l.body }}
arrow_forward
arrow_downward
Start here

Three pages, read in order, cover the whole system.

{{ s.n }} {{ s.title }} {{ s.body }}

Designed for humans and AI

Design decisions are explicit, named and machine-readable rather than left to visual interpretation. That is what makes the system usable as context, not just as a reference.

{{ p.icon }} {{ p.title }} {{ p.body }}

What's inside

Two token layers and the component library. Every item links to its documentation.

Primitive Tokens Seven categories of raw, context-free values. Each opens as a tab on one page.
hub
Semantic Tokens The layer that turns raw values into interface roles — what a value means, which primitive it resolves to, and what consumes it.
arrow_forward
Components Reusable interface patterns built from semantic decisions, each documented with its anatomy, variants, states and rules.
{{ c.icon }}{{ c.label }}
explore

Design principles

{{ p.title }} {{ p.body }}
route

How to use this system

The system supports both human and AI-assisted product design. It is a source of structured design decisions, not a visual reference library.

{{ h.icon }}
{{ h.title }} {{ h.body }}

Current scope

Current scope focuses on the visual and interaction language required for AI-assisted product design: primitive tokens, semantic tokens and the component library.

Additional system concerns — motion, responsive behaviour, layout grids, stacking order and engineering implementation — can be introduced as the system evolves. They are documented as out of current scope rather than absent decisions.

See what sits outside current scopearrow_forward
Outside current scope

Not yet in scope

These categories describe how an interface behaves or how it is built rather than how it looks at rest. The underlying decisions already exist in the build; they are simply not yet named and published as part of the token architecture, so neither a designer nor an AI agent should treat them as system decisions yet.

schedule {{ t.name }} {{ t.note }}
{{ r.title }} {{ r.body }}
Design language

Primitive Tokens

These are primitive tokens — raw values. Components never reference them directly; they bind to the intent names in Semantic Tokens.

{{ cat.title }}

{{ cat.desc }}

{{ tk.sem }} {{ tk.name }} {{ tk.tag }}
{{ row.role }}
Light {{ row.light }}
Dark {{ row.dark }}
Purpose {{ tk.purpose }}

Typography

Three typefaces, each with a fixed job. Never substitute one for another: a claim number set in the UI face stops being scannable, and a paragraph set in the display face stops being readable.

{{ f.sample }} {{ f.role }} {{ f.family }} {{ f.note }}
{{ t.role }} {{ t.spec }} {{ t.sample }} {{ t.note }}

Spacing

A 4px rhythm. Use these steps for gaps and padding rather than eyeballing distances — consistent spacing is what makes a set of screens feel like one product.

{{ t.px }} {{ t.note }}

Corner Radius

Radius grows with the size of the container. Anything round — avatars, icon buttons, chips, dots — goes fully round rather than taking a large fixed value.

{{ t.px }} {{ t.note }}

Elevation

Four levels, each a wide and very soft teal-tinted shadow — never neutral grey. The level tells a user how far above the page something sits, and therefore how temporary it is.

{{ t.role }} {{ t.note }}

Icons

Material Symbols Outlined, weight 300, unfilled. Four sizes cover every use. Icons take their colour from the text beside them — they never introduce a hue of their own.

inventory_2 {{ t.px }} {{ t.note }}
Usage rules
check {{ r.text }}
Design language

Semantic Tokens

Semantic tokens give raw primitive values a name, purpose and context that components can consume. Every token below names an intent and points at exactly one primitive token — no new colours, sizes or values are introduced here.

Where this layer sits

Primitive tokens hold raw, context-free values. Semantic tokens give those values an explicit design intent. Components consume the semantic names and nothing else — which is why one semantic token can resolve differently per theme while its intent stays the same.

{{ t.icon }} {{ t.n }}
{{ t.label }} {{ t.sub }}
{{ t.body }} arrow_downward
rule The dependency runs one way only. A component may reference a semantic token; a semantic token may reference a primitive token. Nothing skips a layer, and nothing points back up.
{{ w.icon }} {{ w.title }} {{ w.body }}

How to read a semantic token

Every name is Category / Role. The category says what part of a component it dresses; the role says which job it does there. Nothing in the name describes a value.

Action / Primary Hover
Category Which part of a component it applies to — Surface, Text, Action, Border, Status or Icon.
Role The job it performs, including state — Primary, Secondary, Disabled, Hover, Focus.
Resolves to One primitive token, per theme. The mapping lives here — never inside a component.

{{ cat.title }}

{{ cat.desc }}

{{ t.previewText }}
{{ t.name }} {{ t.cssVar }}
Light {{ t.light }}
Dark {{ t.dark }}
Purpose {{ t.purpose }}
Consumed by
{{ c }}

Semantic Mapping Matrix

This matrix is the canonical reference for tracing how primitive values flow into semantic intent and ultimately into components. Every semantic token, the primitive token behind it, and the components that consume it. Read a row left to right to trace a value into the product; read it right to left to find what a foundation change will move.

Primitive Token Semantic Token Used By
{{ g.group }}
{{ r.foundation }} {{ r.semantic }} {{ r.usedBy }}
info Light and dark resolve through the same primitive token in every row — each primitive token already carries a value per theme, so the semantic layer never needs a second mapping. Where a primitive entry is published as a locked pair, the semantic token inherits both halves together.

How the two tiers are wired

Both tiers live in one shared token file that every screen and component loads. The semantic tier is not prose — each name below is a real variable that resolves to a primitive token at runtime, which is what makes propagation automatic rather than a manual sweep.

Tier 1 — Primitive, one value per theme
[data-theme="light"]  --accent: #008E8E;
[data-theme="dark"]   --accent: #00BEB7;
Tier 2 — Semantic, one alias, both themes
--sem-action-primary: var(--accent);
--sem-text-link:     var(--accent-on-soft);
Declared once on the themed element, so a single alias covers light and dark — the primitive value it finds depends on the theme it is resolved in.
Tier 3 — Component, semantic only
background: var(--sem-action-primary);
color:      var(--sem-text-on-accent);
A component never names a Tier 1 token. The only place a primitive token appears outside the token file is the Foundations page itself, where it is the subject rather than the styling.

What happens when a primitive token changes

A real change, traced through the system — this is the Accent edit made during the token dependency validation, not a hypothetical.

{{ p.icon }} {{ p.step }} {{ p.body }}

Rules for component authors

Every component page added to the library is written against these rules. They are what keeps the dependency hierarchy true over time.

{{ r.icon }} {{ r.text }}
Library

Components

Reusable UI building blocks identified by auditing My Inventory v2. Nothing here is aspirational — every component was observed in the existing interface. Each row opens its own page.

Name Where it appears Variants & states observed Reusable
{{ r.title }} {{ r.where }} {{ r.observed }} {{ r.reusable }}
Found, but deliberately not componentised
Logo lockup — the mark and wordmark in the header. Brand, not a component; it never varies. Profile identity block — the name and email at the top of the profile menu. One-off content inside one menu. Queue context label — "Medical Record Review" above the list. Plain type from the scale, echoing the active tab. Page title — "My Inventory". A type-scale role, documented in Foundations.
Library

Patterns

Reusable compositions and interaction structures identified by auditing My Inventory v2. Nothing here is aspirational — every pattern was observed in the existing interface. Each row opens its own page.

Name Where it appears Components used Reusable
{{ r.title }} {{ r.where }} {{ r.parts }} {{ r.reusable }}
{{ doc.kind }}

{{ doc.title }}

{{ doc.purpose }}

place{{ doc.where }} recyclingReusable: {{ doc.reusable }}

Examples from My Inventory v2

{{ ex.icon }} {{ ex.text }}
{{ ex.caption }}

When to use

{{ w }}

Components involved

{{ p }}

Anatomy

{{ doc.subAnatomy }}
{{ a.name }} {{ a.note }}

Variants

{{ doc.subVariants }}

{{ g.title }} {{ g.note }}
{{ b.lead }} {{ b.label }} {{ b.trail }}
{{ b.caption }}
{{ doc.futureTitle }} {{ f }}

{{ doc.intentHeading }}

{{ doc.subIntent }}

{{ g.title }} {{ g.note }}
{{ b.lead }} {{ b.label }}
{{ b.caption }}
{{ doc.intentFutureTitle }} {{ f }}

States

{{ doc.subStates }}

{{ b.lead }} {{ b.label }}
{{ b.name }} {{ b.caption }}

Decision logic

How to decide whether this is the right component, and which form it should take. Every rule states the reason behind it, so the same reasoning transfers to situations this page does not list.

{{ doc.dlWhenTitle }}
{{ w.name }} {{ w.note }}
{{ doc.dlNotTitle }}
Situation Choose instead Reason
{{ r.situation }} {{ r.instead }} {{ r.reason }}
Choosing the {{ g.title }} variant
Option Choose when Why
{{ r.option }} {{ r.when }} {{ r.why }}
Decision sequence
{{ s.n }} {{ s.q }} {{ s.a }}
Edge case Principle that resolves it
{{ e.name }} {{ e.note }}
Reasoning rules
rule {{ r }}

{{ doc.variantHeading }}

{{ v.name }} {{ v.note }}

States

{{ v.name }} {{ v.note }}

Usage

{{ doc.subUsage }}
{{ u }}
check_circleDo
{{ d }}
cancelDon't
{{ d }}

Semantic tokens used

{{ doc.subTokens }}
Semantic token Applied to
{{ t.sem }} {{ t.role }}
Semantic names only. To see which foundation each of these resolves to, and everything else that consumes it, open the Semantic Tokens page.

Accessibility

{{ doc.subA11y }}

{{ a.name }} {{ a.note }}

Component contract

{{ doc.subContract }}

{{ c.name }} {{ c.note }}

Coming Soon

Work is in progress. This section will be available as the design system evolves.
content_copy{{ toastText }}