One design system, shared across the org
Different teams, different patterns. I unified them into one system.
airCloud Select was one of Hitachi Heating & Cooling’s B2B software products. It relied on an Adobe XD style guide rather than a shared working system that could evolve with the product.
When the team migrated from XD to Figma, I saw an opportunity to do more than recreate the existing files in a new tool. I proposed and led the initiative to build a reusable, token-based design system — from auditing and prioritising existing patterns through component architecture, stakeholder alignment and documentation.
System at a glance
10+
component families
50+
variants
3
cross-functional workshops
3-tier
token architecture
ROLE
Lead Product Designer
TEAM
Product
Engineering
Brand
Marketing
SCOPE
Design system strategy
Component architecture
Stakeholder alignment
Documentation
Stakeholder alignment
Documentation
TOOLS
Figma
Figma Variables
THE PROBLEM
A static style guide wasn't enough to support a growing product ecosystem
The issue wasn’t a lack of design guidance — it was that the guidance wasn’t connected to how products were being designed and built.
01 — Handoff friction
Without shared component definitions and usage guidance, UI decisions often needed extra clarification between Design and Engineering.
02 — Product drift
Similar components and patterns were evolving differently across products, making consistency harder to maintain over time.
03 — Limited shared ownership
Design standards were largely maintained within Design, with limited involvement from the wider teams responsible for building and evolving the products.
As the product portfolio grew, these gaps increased repeated decision-making, made consistency harder to maintain, and created more work across Design and Engineering.
THE APPROACH
Auditing first, prioritising with intent
I inherited airCloud Select from a previous contractor, along with an Adobe XD style guide that documented visual styles but offered little guidance on how components should be used. As the organisation migrated to Figma, I was designing new screens while auditing the existing product and rebuilding its reusable foundations in the new tool — alongside my other product responsibilities, with limited dedicated time and engineering capacity.
I reviewed airCloud Select and related products to see how common components and patterns were actually being used, which surfaced duplicated patterns, inconsistent states and gaps in guidance.
Rather than standardising everything I found, I scoped the first version around three criteria:
01 — Frequency
Patterns that appeared repeatedly across screens and products.
02 — Reuse
Patterns that could support multiple workflows, not just one.
03 — Ambiguity
Patterns where inconsistent states or missing guidance created the most room for interpretation.
Existing style guide on Adobe XD
BUILDING THE SYSTEM
From static styles to a system the team could use
The XD style guide relied on static values, so I introduced a simple three-layer token structure in Figma — giving the team one place to manage design decisions while keeping components flexible as the system evolved. On top of that structure, I turned the audited patterns into reusable Figma components, covering common states, sizes and variations rather than just the default UI, along with usage guidance for when and how each component should be used. This moved the system beyond a visual library into something the team could use consistently in day-to-day product work.
CROSS-FUNCTIONAL BUY-IN
Turning a design initiative into shared ownership
Once the initial system was tangible enough to discuss, I used it as the basis for workshops with Product, Engineering, Brand and Marketing.
The design system could not scale if it remained owned only by Design. Across three workshops, I aligned the different functions on where consistency mattered, what needed to stay flexible, and how the system should evolve. These sessions helped turn the work into a shared initiative and build support for further investment and closer engineering involvement.
IMPACT & WHAT'S NEXT
Building a foundation the organisation kept investing in
01 — A clearer shared foundation
The system gave designers a reusable reference for common patterns and reduced reliance on static guidelines.
02 — Engineering-ready documentation
Components, states and sizing were specified down to the pixel, giving engineering a clear, detailed reference to build from.
03 — Continued investment
The initial system helped build stakeholder support for further development — including a leadership commitment to additional engineering resourcing and a roadmap for the next phase.
Before handing over, I documented the system, aligned the team on priorities, and set a roadmap for Phase 2 and Phase 3 — deeper engineering integration, wider adoption and clearer governance. Not everything was solved; shared ownership and decision rights still need to mature. But the foundation and stakeholder support were in place for the system to keep evolving without me.
REFLECTIONS
What I’d change next time
Involve Engineering earlier, so design and code components evolve together from the start.
Define adoption measures earlier (component usage, system coverage) to track value beyond the initial rollout.
Establish clearer ownership and governance earlier, so future decisions depend less on individual designers.