Parlance is a platform that keeps design and code in sync. It treats a design system as a contract — colours, spacing, components, terminology, and accessibility rules — and continuously audits four surfaces against it: design files, code, the live product, and native apps. The work spanned a Linear/Vercel-class web app and a family of tools that put the audit engine wherever the team already works.
The challenge
Design systems drift the moment they leave the source of truth. A token gets hard-coded, a contrast ratio slips below 4.5:1, a label says "Click here", a radius is 6px where the token says 10px — and nobody notices until it ships. The problem was not building a system; it was enforcing one, everywhere, without slowing teams down.
- Tokens get hard-coded the moment design leaves Figma
- Accessibility regressions — contrast, targets, labels — ship unnoticed
- Design, code, live product and native apps drift apart
- Standards (WCAG 2.2, ARIA, Section 508, EN 301 549) are checked by hand, late
- Designers and engineers work in different tools with different truths
- One product, but findings look different on every surface
Discovery & research
Parlance began as a systems problem, not a screen problem: design systems drift the moment they leave the source of truth. Discovery mapped where drift actually happens, which accessibility standards have to be enforced rather than hoped for, and how one audit could read identically across five wildly different hosts.
Drift happens at the edges, not the centre
A token gets hard-coded, a contrast ratio slips below 4.5:1, a label says 'Click here', a radius is 6px where the token says 10 — and nobody notices until it ships. The conclusion was that a system has to be enforced everywhere the product lives, not just defined once in Figma.
EvidenceFour surface types scoped for audit: design files, code, the live product, and native apps.
Accessibility regressions ship silently
WCAG 2.2, ARIA, Section 508 and EN 301 549 are normally checked by hand, late, by whoever remembers. Treating them as structural guarantees — audited continuously and surfaced with severity — was a research conclusion that shaped the whole product, not a feature bolted on at the end.
EvidenceStandards audited across every surface, with severity-coded findings.
Colour has to be functional to survive five hosts
For the same finding to read identically in a web app, a 360px Figma panel, a browser popup and a VS Code tree, colour could not be decoration — it had to carry meaning. Severity and status are defined as tokens, in OKLCH, with light and dark values, so a critical finding looks critical everywhere.
Evidence50+ OKLCH tokens (the Lexicon foundation), light + dark, with dedicated severity and status systems.
One contract, or it's just a suggestion
The research reframed the design system as a contract — tokens, components, glossary, accessibility — that every surface is audited against. Consistency you cannot enforce is only a suggestion, so the unit of the product became the contract, not the component library.
EvidenceSix products across four surface types, all bound to one shared Lexicon contract.
How I approached it
Everything started from the token layer — Lexicon — built in OKLCH so colour stays perceptually even, with light and dark as equal modes and a functional system where severity and status get their own accessible treatments. From there the same language extended outward: the web platform for the full audit and system definition, then the surfaces where work actually happens — a Figma plugin, a browser extension, a VS Code extension, and native macOS auditors.
Built the Lexicon token foundation in OKLCH — neutrals, brand, severity, status — light + dark
Designed the web platform: audit detail, project overview, glossary, marketing, sign-in
Made colour functional — severity and status drive every finding, never decoration
Brought the audit engine into Figma, the browser, and VS Code with consistent UI
Designed native macOS tools: a menu-bar auditor and an accessibility-auditing browser
Kept one contract across all six surfaces, so a finding reads the same everywhere
Trade-offs
The challenge was coherence across radically different hosts. A 240px web sidebar, a 360px Figma panel, a browser popup, a VS Code tree view and a native macOS window have nothing in common structurally — but the product had to feel like one thing, and the audit data had to be instantly recognisable on all of them.
- One language across web, plugin, extension and native — wildly different hosts
- Keeping severity and status legible at every size and in every theme
- Designing dense, data-heavy audit views that still scan quickly
- Light and dark as equals on every surface, never an afterthought
- Making the same finding feel native in Figma, Chrome, VS Code and macOS
Final direction
Parlance is one contract on six surfaces. The web platform carries the full audit, glossary and system definition; the Figma plugin, browser extension and VS Code extension bring the audit to the point of work; native macOS tools audit live and native experiences. All of it is bound to the Lexicon token system, so the whole platform flips to dark in a click and every finding is colour-true across hosts.
Outcomes
Parlance demonstrates design-systems leadership at platform scale: a single token contract enforced across four surface types and six distinct products, with accessibility (WCAG 2.2, ARIA 1.2, Section 508, EN 301 549) and light/dark treated as structural guarantees rather than later passes. The contribution is the systems thinking that lets one language survive contact with five different hosts. [Add a live metric once instrumented: drift caught per release / audit coverage.]
One system, every screen
Keep design and code telling the same story.
A design system is only as strong as its weakest surface. Parlance treats the system as a contract and audits everywhere the product lives — because consistency you cannot enforce is just a suggestion.