Particle

Fully Synced & Tokenised

Creative Technologist
Eqonex
2021 - 2022
In-house Design Team
Singapore
Roles
Design system · Token structure · UI · Branding · dev POC · Sync Pipeline · Naming convention · Documentation
Fully Synced & Tokenised

Particle was built alongside the UI overhaul of EQONEX’s crypto trading platform, with the goal of creating a shared foundation between design and engineering.

I designed the system around a fully tokenized architecture, with design decisions separated from component implementation. This allowed the system to evolve without requiring changes to the underlying component code, making iterations faster and reducing inconsistencies between design and production.

A key part of the work was establishing an automated synchronization pipeline between design and code, supported by shared naming conventions, documentation and platform-specific token outputs. The result was a single source of truth that made the design system easier to maintain and gave engineering a more predictable way to work with it.

A system with a name

Particle was built alongside the exchange's UI overhaul, as the shared foundation design and engineering would both work from. Naming it was part of getting it adopted.

The Particle design system logo on a dark ground beside a sphere of connected particles
The component library in Figma, page after page of inputs, actions, status and asset components

The library, in production order

Components carry their own status, ready for design, ready for production, in progress. The library doubles as the plan.

One pipeline, four stages

Tokens are defined once, stored as JSON, translated automatically and distributed by npm. Everything downstream is generated, which is what keeps design and code in step.

Diagram of the token pipeline, from defining and storing to processing and consuming
The three token tiers, core option tokens, semantic decision tokens and component decision tokens

Three tiers, one rule

Raw values stay internal, decisions are public. A component never reaches for a hex code, which is why a change of palette is not a change of code.

The name is the contract

Five parts, always in the same order. Shared naming is what lets a designer and an IDE autocomplete the same token.

The naming scheme for a token, built from namespace, tier, category, scale or variant and state
Token attributes, the platform-specific outputs and the update flags the build can raise

Every platform, one source

The same token arrives as CSS, styled components, Tailwind, Figma styles and Swift or XML. Deprecations travel with it as build warnings.

Documentation that cannot drift

Stories are generated from the components themselves, and a Figma variant is the same thing as a prop. Nothing is described twice in two places.

Live documentation in Storybook beside the component API, where Figma variants map onto component props
A button with each of its properties annotated with the component token that sets it

Every value traceable

Each property of a component points at the token behind it. This view is how a design review stopped being an argument about pixels.

Two Figma plugins built for the system, one toggling spec annotations and one creating page templates

Tools for the people using it

Plugins to toggle specs and to lay out a documentation page. A system is adopted when using it correctly is the easiest option available.

Where next

See also

Web3 Crypto Exchange ← Back to overview
← Back