Home About Contact Book a meeting
KovaAnalytics intelligence ArborData platform PlioAI invoice pipeline FinningDealer portal OnBuyMarketplace UX Design systemSIERA · components & tokens

SIERA Design System

The design system behind Evora Global's B2B ESG intelligence platform: shared tokens, components and patterns across the product.

Read time
~5 min read
Company
Evora Global
Product
SIERA
Role
Design system owner
Stack
Figma · Figma Make · Storybook · Supernova

Consistency as a trust mechanism

SIERA is an ESG intelligence platform where people make high-stakes decisions on sustainability data they didn't collect themselves. Consistency here isn't aesthetic, it's a trust mechanism. A component that behaves unpredictably on a dashboard where a fund manager is reviewing performance figures doesn't just look wrong, it creates doubt about the number itself.

I joined Evora as its second designer. I didn't inherit a mature system. I built it, then rebuilt it as V3 when the platform's growth exposed what V1 and V2 couldn't hold.

V3
The version that rebuilt the system for scale
3
Tooling layers: Figma, Storybook, Supernova
30+
Components in the shared library
Problem

V3 was a structural rebuild, not a visual refresh

Platform areas had evolved independently, so the same component behaved differently across modules because each area had built its own version. Engineering shipped inconsistent implementations because there was no single source of truth between design and code. New features were slowing down because component decisions were being relitigated on every project.

Governance

The principles we governed against

The system was built inside the team's Experience Design Manifesto. These four product-confidence principles, written collectively as a team, were the criteria every component had to meet. They are the team's framework; making them enforceable in the library was mine.

Transparency

Every state must be visible

No silent loading, no hidden errors, no ambiguous empty states.

Applied to: every data tile, every async operation, every form field in the library.
Informative design

Context at the decision point

Information surfaces where the decision is made, not before it.

Applied to: progressive disclosure in every form-based flow, drill-down hierarchies, filter panels.
Clear communication

Errors explain what to do

Not "something went wrong". The library has a required error pattern: description plus action, always.

Applied to: form validation, API failure states, empty vs not-yet-loaded states.
Inclusion

WCAG AA is the gate, not a retrofit

Every component passes before it ships, rather than being patched afterwards.

Applied to: colour contrast on all tokens, focus states on every interactive element, aria labels on all non-text UI.

The principles defined the criteria. The system made them enforceable rather than aspirational. A navigation pattern that needed training to understand failed Transparency. A form that only surfaced errors after submission failed Clear Communication. Every component decision ran through that filter before it entered the library.

Trust is earned over time through repeated positive experiences. Confidence is given immediately, through clear communication of what a product can and can't do. For an ESG platform where users read numbers they didn't collect themselves, the system's job is to give them confidence in what they're seeing while the product earns their trust over time. Most teams conflate the two and end up designing for neither.

Consistency where it matters, flexibility where it creates value

A junior take on a design system standardises everything and calls it done. A senior take understands where standardisation kills the product, and draws the line deliberately.

What the system standardised
Non-negotiable, every squad.
  • Navigation patterns
  • Layout grid
  • Forms and input components
  • Tables and data display
  • Buttons and interactive controls
  • Interaction and motion patterns
  • Accessibility patterns (focus, aria, contrast)
  • Error, empty and loading states
Where the system allowed flexibility
By product area, where a template would make the product worse.
  • Complex ESG data workflows
  • Analytics visualisations and chart types
  • Data-heavy investigative tools
  • Emerging AI-assisted experiences
The system

The tokens every component is built from

Tokens are the layer everything else inherits from. A structured colour ramp and semantic roles sit on top, a measured type and space scale underneath, and a small set of radius and elevation steps. Change a value here and it updates everywhere the token is used, which is what keeps the surface consistent without anyone policing it by hand.

A button, exploded into its tokens

This is what tokenised thinking looks like up close. Fill, radius, inset padding, gap, label type and stroke each reference a token rather than a raw value. It is the difference between a component that looks right once and a component that stays right as the system grows.

Every state a component has to hold

A component is only as good as its worst state. Each one is specified in the library: a visible focus ring that does not depend on colour alone, labels that clear AA contrast, a disabled state that still reads as a button, and an error state that is unmistakable. Accessibility is part of the definition, not a pass added at the end.

The templates underneath the components

Components solve the small decisions; patterns solve the repeated ones. The form, the table and the navigation shell are defined as templates, so a new screen starts from a known-good structure instead of a blank canvas. It is how consistency survives contact with a deadline.

The component library at a glance

This is the breadth the system carries. Each component ships with its variants and states already decided, so a designer or engineer reaches for the right one instead of rebuilding it. It reads as a real working library, not a handful of sample chips.

The path from a token to production

The system only holds if design and engineering pull from the same place. Tokens and the component library live in Figma, documentation and governance run through Supernova, components and pages ship from Storybook, and the product consumes all of it. A button defined once travels the whole way through unchanged, which is the part that makes it a system rather than a style guide.

In production

One source of truth, wired from design through to production

Four artifacts, working as one system. The Storybook and the hosted documentation are the proof it was real and used in production.

Impact

Outcome-based, no vanity metrics.

Less duplication. Areas that had evolved independently now share components, so the same one behaves consistently in every module.

Faster delivery. Component decisions stopped being relitigated on every project because the system already provided the answer.

Consistent UX. Users carry their mental model from one module to the next instead of relearning each area.

Design-dev alignment. A shared language meant implementation quality matched design intent rather than degrading at handoff.

Easier onboarding. A documented, accessible, reasoned system lets a new engineer understand why a component exists and how to use it without asking.