The Genio Design System

Building the shared design foundation behind Genio's product family, and the practices that keep it consistent, accessible and scalable.

Type: Project
Project: Genio Design System
Role: Senior UX Designer, design-side founding member and steward
Area: Design systems, multi-brand theming, accessibility and governance
Status: Live across multiple Genio products
Timeline: 2023-2026

Snapshot

Problem: Genio was growing into a family of products and brands, but teams were rebuilding similar UI patterns in slightly different ways. A full rebrand exposed how fragile hard-coded styling and scattered guidance had become.
Users: Product designers and engineers building experiences across the Genio platform.
Goal: Create a documented, accessible, multi-brand foundation that every product could build on without losing flexibility.
Outcome: Helped establish a governed design-side foundation with shared tokens, documentation, contribution practices and accessibility standards across Genio products.

Short on time? Skip to the ending

Questions driving the project

What I needed to understand

Where were product teams solving the same UI problems differently?
Which patterns were repeated enough to deserve a shared component?
Where were brand, theme and accessibility decisions being hard-coded?
What documentation would help design and engineering work from the same source of truth?
How could the system support multiple product brands without fracturing?

What I needed to validate

Could semantic tokens make brand and theme changes happen globally rather than screen by screen?
Would zeroHeight, Storybook and Figma to code sync give the team a usable documentation workflow?
Could a contribution process help the system grow without becoming a dumping ground?
Would focusing on fewer high-impact components create a stronger foundation than trying to cover everything?

Genio Design System cover showing Genio Present and Genio Notes interfaces using the same shared design foundation.

One system, multiple brands. The same foundations support Genio Present, Genio Notes and other product surfaces.

Challenge

01 / Product family

Genio had multiple products and brands, but no single foundation holding common patterns together.

Genio was no longer a single product.

Notes, Present, Admin and other surfaces all needed to feel coherent, while still supporting different product contexts and brand themes.

Before the system matured, squads were rebuilding the same buttons, inputs, dialogs and layout patterns in slightly different ways.

Styling drifted, accessibility decisions were re-solved repeatedly, and the Glean to Genio rebrand showed how painful hard-coded colour and type decisions could become.

The opportunity was not to create the biggest component library.

It was to create a shared foundation, and a way of working, that could survive product growth, dark mode, brand change and continued contribution from multiple teams.

Research

Methods

Surveying UX and engineering teams about design-system pain points
Auditing components across Figma, Storybook and zeroHeight
Reviewing repeated product patterns across Notes, Present and Admin
Running tooling spikes for documentation and Figma to code sync
Working with engineering on token, theme and implementation constraints

Key insights

Many inconsistencies came from missing shared guidance rather than missing UI ideas.
Teams needed a source of truth that connected design intent, coded implementation and usage guidance.
A multi-brand product suite needed semantic tokens, not components tied to raw hex values.
Accessibility needed to be designed into tokens and components so teams inherited better defaults.
The system would only stay useful if contribution and quality standards were part of the workflow.

Hypotheses

If components reference semantic intent rather than raw values, brand and theme changes will be easier to manage globally.
If documentation embeds live implementation examples, designers and engineers will share a more reliable source of truth.
If contribution decisions are governed by evidence from product work, the system will stay focused and maintainable.
If accessibility is handled at the token and component level, quality will improve across products instead of relying on final review.

Product direction

Treat the design system as an operating model, not only a component library.
Use product work to reveal reusable patterns before formalising them.
Use semantic tokens so components reference intent rather than raw brand values.
Make accessibility part of the foundation through contrast, states and interaction standards.
Connect Figma, Storybook and zeroHeight so documentation reflects both design and implementation.
Introduce contribution guidance so the system can mature without becoming one person's side project.

Core flows

Strategy and tooling

The team needed a clear system strategy and a practical way for designers and engineers to document, find and reuse shared patterns.

Wrote the early design-system strategy and helped define how we would identify high-impact components.
Surveyed UX and engineering teams to understand where the system was causing friction.
Led the adoption and setup of zeroHeight, Storybook and storybook.to.design for documentation and reuse.
Helped stand up the documentation space so the system had a clear home beyond Figma.

Semantic token architecture

Genio needed one system that could serve multiple products, brand themes, dark mode and a full company rebrand.

Pushed a primitives, semantic and brand-theme token model on the design side.
Moved components towards referencing intent, such as heading colour or link colour, instead of raw hex values.
Worked with engineering as the coded token and theme layer was implemented.
Used the semantic layer to support the Glean to Genio rebrand as a controlled global change.

Component quality and audit

The system needed to grow from real product demand rather than speculative components.

Built and maintained a component audit across Figma, Storybook and zeroHeight.
Focused roadmap decisions on the highest-impact components and repeated product patterns.
Used buttons and other common patterns to establish the expected quality bar for states, hierarchy, behaviour and documentation.
Kept the system selective so shared components solved proven product problems.

Accessibility by default

Accessibility needed to be inherited through the system, not repeatedly rediscovered by each team.

Helped define accessible colour values across light and dark themes at the token level.
Worked through contrast, states, keyboard behaviour and interaction details with designers and engineers.
Used shared standards so accessibility became part of component quality rather than a final check.
Supported accessibility-related documentation and review work as the system matured.

Governance and contribution

A design system only stays coherent if teams know how to add to it, challenge it and maintain it.

Authored a contribution process with a review gate and quality checklist.
Included checks for duplication, states, accessibility, testing and documentation.
Proposed a Design System Guild model so ownership could become more shared and durable.
Positioned documentation as part of the component, not an afterthought.

Iteration

What did not work

Treating the system as a loose collection of components did not create enough consistency.
Hard-coded brand values made theme changes and rebrand work more expensive than it needed to be.
Documentation that lived away from implementation was harder for teams to trust and maintain.
Adding components without contribution rules risked turning the system into a dumping ground.

What changed

Moved the foundation towards semantic tokens that could resolve across brands and themes.
Connected Figma, Storybook and zeroHeight so documentation, design assets and implementation could stay closer together.
Used a component audit to track status and focus the roadmap on highest-impact work.
Introduced a contribution process so new shared patterns had clearer quality gates.
Shifted the system from an ad-hoc library towards a governed product-like foundation.

Impact

Established the design-side foundation for a system used across multiple Genio products.
Helped the Glean to Genio rebrand become a token and theme-layer change rather than a screen-by-screen rebuild.
Created clearer shared documentation through zeroHeight, Storybook and the component audit.
Raised the accessibility baseline through shared tokens, interaction standards and review practices.
Moved the system from ad-hoc contribution towards a governed model with clearer standards.

Outcome

Created a shared design foundation serving multiple Genio products and brand themes
Supported the Glean to Genio rebrand through semantic tokens and theme-level decisions
Established a documentation workflow connecting Figma, Storybook and zeroHeight
Introduced contribution governance so the system could grow with clearer standards
Helped product teams build from shared components, tokens, accessibility guidance and interaction patterns

The strongest outcome was not simply more components.
It was a more durable operating model for how Genio designs and builds shared product foundations across multiple teams, products and brands.

Reflection

This work reinforced that a design system is an operating model, not only a component library.
The semantic token layer was the highest-leverage decision because it made rebrand, dark mode and multi-brand theming easier to reason about.
Documentation is part of the product. It gives shared components context, makes decisions visible and helps quality travel beyond Figma.
Governance matters because a system becomes fragile when contribution depends on memory or informal agreements.
Great design systems grow through product work, collaboration and thoughtful decisions about what should, and should not, become reusable.

Back to portfolio