Craft, patterns & research that scale
We build interfaces that feel like a sharp colleague who knows your data inside out — not another generic admin tool. Work Sans. Tight tracking. Tokenized accents (default Minimal Neutral) with optional Spectrum / n2 Red / Dark modes. Frequency Field is brand atmosphere, not a control.
Two contexts share tokens but not always the same chrome: Playbook shell (this docs site) and Product UI demos (app patterns + client skins below). Don’t mix them when writing specs.
Load-bearing recipes already live across the site. Use these when adding pages so the playbook stays one system.
.site-nav in theme.css. Active section uses its accent token. Palette control (Spectrum · n2 Red · Minimal Neutral · Dark) via theme.js; default is Minimal Neutral.
.page-header — back link, display-size h1 in section accent, subline. Same language as homepage section titles (see Process, Marketing, Glossary).
Canonical shell component in theme.css:
.playbook-card + .playbook-card__bar (aria-hidden="true") + .playbook-card__bodystyle="--playbook-card-accent: var(--spectrum-…)".playbook-card--compact · .playbook-card--feature (homepage full-radius)Subcards stay border-only tiles (no bar). Product UI demos under demo-skin root stay separate — do not convert demos to playbook-card.
Uppercase tracking badge (EXISTING / COMING SOON / IA / RESEARCH) above section titles. Long pages use sticky “On this page” nav (this sidebar is the live example).
We use a small, consistent set of input primitives across flows, record editing, lists, and filters. Goal: speed and familiarity — not "yet another control". Prefer the real shared components (EditableParameter for attributes, the exact filter bar pattern) when possible.
When to use: Free-form data → text / multiline. Constrained choices → Select. Multiple flags → Checkbox group. Temporal → date. Discovery → icon-prefixed search InputBase + chips. Attributes in drawers → inline EditableParameter (click/pencil to edit, Enter/Esc to commit).
Screenshot from source + full live examples available in original N2 UX (using our tokens + patterns). See "FILTER / SEARCH", "TEXT", "SELECT" demos in source.
LIVE EXAMPLES — matching studio / flow / drawer implementations
Uses exact filter treatment from Tables.tsx / DatasetDetails — search cluster + status chips.
Matches Select + MenuItem usage in FlowDetail step forms and batch drawers.
Directly mirrors form step controls in FlowDetail.tsx and batch edit forms.
EditableParameter pattern (RecordDetailsDrawer / TabularDataPreview). Hover affordance on soft bg.
The form builder is the core of N2 Flow: define reusable forms by selecting fields from a table schema. Supports sections, role-based access, custom field types (range, tabular), and one-time use for schema fields.
When to use: For data collection flows where structure comes from existing tables. Use "click to add" from palette, drag to sections, set required/readOnly. Preview mode for validation. Publish to use in flows.
Permissions / Access matrix: /settings/users provides a dashboard with role assignment + domain/table access matrix (compact grid overview + per-user expandable inline selects for Owner/Editor/Read/None).
Combobox multi-select; matches form step roles.
Added in demo: —
Matches /admin/forms/* : palette left, sections right, one-time use for schema fields (FormBuilder.tsx).
n2flow uses a consistent list + focused detail pattern for data tasks (runs). Emphasis on current step ownership, progress visibility, and review actions. The admin blueprint is a flow template — do not say “flow” in nav or page titles.
When to use: For any multi-step data collection. List for overview + actions; detail for step execution with data review + comments.
| RUN | CURRENT STEP | STEP OWNER | PROGRESS | STATUS | ACTION |
|---|
Filter + sort + status chips + progress + action. Matches /flows (All data tasks). Stalled is the exception, not the default.
Start data task dialog: title “Start data task”; steps Choose template → Choose table → Upload file → Review & start; deep-link ?newFlow=true&template=<id>.
Select a run above to load step detail…
Chips and small tags are used heavily in All data tasks and My data tasks for status, filters, "Stalled" indicators, and lightweight metadata. They must be scannable at a glance, use consistent sizing, and avoid error-like colors for non-error states (e.g. stalled).
When to use: Status filter bar (interactive), row-level status, temporary "Stalled" / "Reminder sent" callouts, domain/duration badges.
Stalled uses soft red tint (never harsh error red). Click a chip to select the filter state.
The org overview surface. Four phase cards (Ingest/Organize/Discover/Share) with live counts, contributor counts, plus the recent activity feed that surfaces cross-domain actions.
When to use: Landing view for most users. Cards link to the primary list for that phase. Activity is read-only scannable history.
We deliberately avoid heavy generic DataGrids. Our tables + filter bars + drawers keep the experience feeling like a material data tool.
When to use: Click row → rich record drawer. Checkboxes/Cmd+click → selection state + Secondary Action Bar. Search/filter cluster always shown for discovery.
| ID | Name | Status |
|---|
Selection → secondary bar. Click name to inline-edit. Primary actions stay in page header.
The deliberate hierarchy: Left nav → In-page tabs → Breadcrumbs → Drawers. Each has a live example below.
Clear next action, no dead ends.
Skeletons that match final layout.
Actionable recovery — never only “something went wrong”.
--n2-bg, --n2-surface, text/secondary/muted, --n2-border (theme.css)--spectrum-teal, --spectrum-violet-blue, --spectrum-violet, --spectrum-orange-warm--n2-red (#D70321) — e.g. “All” status chip; not the same as section spectrum unless palette is n2 Redhtml.theme-dark.Type & motion: Work Sans, tight tracking. Theme transitions respect prefers-reduced-motion. Frequency Field is atmospheric brand texture (hero/overlays), not a form control. Progressive disclosure for complexity — summary first; depth on demand.
The structure and organization of content, data, and navigation across the platform. Defines how Schemas, Domains, Tables, Views, and Projects relate — and how users discover and navigate information.
Core n2 hierarchy with cross-cutting collections and discovery patterns. Click any node to open its glossary definition.
IA principle: clear hierarchy for findability + polyhierarchy for real user collections + facets/wayfinding for discovery and orientation.
Use research to reduce risk, not to decorate decks. Match the method to the decision: what people do vs what they say, and how many / how often vs why / how. (Framed with NN/g qualitative–quantitative practice.)
Answers: why, how, what mental models, where friction lives.
Answers: how many, how often, how large the effect, is A better than B.
Real tasks, realistic users, observe failure points. Prefer 5–8 per round, iterate (NN/g: small iterative tests beat one big study).
Open/closed sort for grouping; tree test for “can they find it?” Validates IA before we ship nav and domain labels.
Mental models, workflow, language of materials experts. Ask about last time they did the job — not abstract preferences.
Expert review against Nielsen’s heuristics + our tenets. Fast, cheap; not a substitute for users on novel flows.
Define success metrics first. Instrument funnels; A/B when traffic and risk warrant. Don’t ship based on vanity metrics.
Good for attitudes and satisfaction at scale; weak for inventing UI. Avoid leading questions; combine with behavior data.
Further depth (scripts, sample plans, templates) can land here later. Live UI demos sit under Components & Patterns.
Interactive demos already cover the core product patterns. Next: variants, contribution rules, and engineering handoff (props, states, a11y notes) so demos graduate into a shared system—not a second visual language.
See Components & Patterns →