When every designer is building a different demo, consistency can quickly become an afterthought. I created a shared design system to bring the demos together, reduce duplicated work, and give designers and developers a reliable source of truth.
Role
UX Designer
Employer
Platform
Web / Design System / Figma Site
Background
The Center for Intelligent Power (CIP) was focused on demonstrating what Eaton's technology could do.
Rather than building complete customer-facing products, our team created interactive demos that showcased individual capabilities developed by data scientists and researchers.
Each designer was responsible for a different demo and worked closely with a developer to create an interface that helped stakeholders imagine how that capability could eventually be integrated into their own systems.
The interface itself wasn't the product.
The capability behind it was.
That created a very different design challenge from building a traditional product.
Problem Space
The demos were moving quickly, but the design process wasn't designed for a team working this way.
The existing company design system was also designed primarily around Eaton's established brand language. Our demos had a different purpose: they needed to communicate emerging technology, AI capabilities and the possibilities of what could be built next.
As a result:
Designers were recreating similar components across different demos.
Developers were implementing the same patterns from scratch.
There was no shared source of truth for components or behaviours.
Similar interactions looked different from one demo to another.
Documentation was scattered across Figma, Confluence and source code.
Developers had to repeatedly clarify how components were intended to work.
The problem wasn't simply visual inconsistency.
It was a collaboration problem.
Research & Discovery
I started looking across the demos rather than looking at them individually.
When I compared the different projects, I noticed that many of them were solving similar interface problems: buttons, inputs, cards, panels, modals, metrics, alerts, filters, data visualisations and AI-oriented interactions.
We didn't need every demo to look identical.
We needed a shared foundation that allowed each demo to feel like part of the same ecosystem while still giving designers enough flexibility to express the capability they were demonstrating.
The goal wasn't to build a massive enterprise design system.
It was to create something useful enough to remove duplication without adding unnecessary process.
I wanted the system to:
01 — Create consistency
Establish a shared visual and interaction language across demos.
03 — Improve developer confidence
Give developers one reliable place to understand how components should look and behave.
02 — Reduce duplicated work
Allow designers and developers to reuse existing patterns instead of recreating them.
04 — Encourage collaboration
Create a process where designers could contribute, challenge and improve the system together.
Designing for AI Without Breaking the Brand
One of the biggest discussions was how far the demo visual language should move away from Eaton's existing design system. The central design-system team understandably wanted to protect the visual language they had spent years building.
But our use case was different. We weren't creating another customer-facing Eaton product. We were creating experiences that helped stakeholders imagine the future.
Instead of creating a completely separate visual identity, I proposed an inner-source approach.
We could reuse what already existed where it made sense, while extending it for our specific context. For example, existing status colours and tags could be reused directly. Other parts of the visual language could be adapted, including color treatments, gradients and iconography, when we needed to communicate AI, intelligence or emerging technology.
This gave us a system that felt recognisably Eaton while still feeling appropriate for the future-facing work we were demonstrating
From Components to Governance
A component library alone wouldn't solve the problem.
Without collaboration, we could simply end up with another library that gradually became inconsistent.
So I introduced biweekly design-system sessions with the designers working on demos.
The conversations focused on practical questions:
Does someone need a new component?
Does something already exist that could solve the problem?
Is the proposed component actually different?
Could an existing component be extended instead?
What should become a shared pattern?
What should remain specific to one demo?
This shifted the system from being something I maintained for the team to something the team maintained together.
One Source of Truth
There was another problem to solve.
Developers already had documentation scattered across different places.
Some information lived in Figma.
Some lived in Confluence.
Some existed in source code.
And some existed only in conversations.
I wanted developers to have one place they could return to when implementing a component. So I consolidated the design-system documentation into a dedicated Figma Site.
The site became the shared reference point for:
Component overview
Variants
States
Sizes
Anatomy
Usage guidelines
Accessibility guidance
Developer resources
Examples
Version history
Changelog
The goal wasn't to create documentation for documentation's sake.
It was to make the intended behaviour of the system discoverable.
Making Components More Than Visual Assets
For each component, I tried to document the decisions that developers and designers actually needed. Accessibility wasn't treated as something to add after the component was designed. Where relevant, accessibility considerations were included directly in the component guidance.
What Changed
This project taught me how to work end‑to‑end across research, stakeholder collaboration, and iteration, from running interviews and validating ideas with users to aligning with leadership and adapting to technical and delivery constraints. It strengthened my ability to design not just for users, but within real organisational contexts.
Key Takeaways
This project changed how I think about design systems. I learned that a design system isn't primarily a collection of components. It's a way of working.
The hardest part wasn't deciding how a button should look. It was creating enough alignment between people that they trusted the system and wanted to use it.
Back to Top