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
airCloud Select — Design System
From a static style guide to a shared product 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
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.
Context & Constraints
Proving the value before full resourcing
I inherited airCloud Select from a previous contractor, along with an Adobe XD style guide that documented visual styles but provided 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.
This work ran alongside my other product responsibilities, with limited dedicated time and engineering capacity. I therefore kept the first version focused — enough to demonstrate the value of the system and build support for further investment.
Existing style guide on Adobe XD
Component Audit
Auditing the existing experience
I reviewed airCloud Select and related products to understand how common components and patterns were being used. The audit helped me identify duplicated patterns, inconsistent states and areas where guidance was missing. From there, I defined the first scope of the system around the patterns that appeared most often and would create the most reuse across products.
Strategy & Prioritisation
Deciding what belonged in the first version
Rather than trying to standardise everything I found, I used three criteria to define the first scope of the system.
01 — Frequency
Patterns that appeared repeatedly across screens and products.
02 — Reuse
Patterns that could support multiple workflows rather than a single use case.
03 — Ambiguity
Patterns where inconsistent states or missing guidance created the most room for interpretation.
Mapping the complete eSIM workflow—from ordering through management—to achieve early stakeholder alignment on the two areas needing redesign.
Token Architecture
Turning static styles into a flexible system
The XD style guide relied on static values, so I introduced a simple three-layer token structure in Figma to make the system easier to update and maintain.
This gave the team one place to manage design decisions while keeping components flexible as the system evolved.
Component library & documentation
Making the system practical for day-to-day use
I turned the audited patterns into reusable Figma components, covering common states, sizes and variations rather than just the default UI. I also added usage guidance so designers had a clearer reference for when and how each component should be used.
This helped move the system beyond a visual library into something the team could use more 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 & outcomes
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 once implementation begins.
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.
Phase 1 shipped; Phase 2 and Phase 3 are roadmapped to deepen engineering integration, adoption and governance.
Handoff & governance
Designing the system to continue without me
Before handing over the project, I documented the system, aligned the team on next priorities, and created a roadmap for Phase 2 and Phase 3.
The next phases focus on deeper engineering integration, wider adoption, and clearer cross-functional 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 continue evolving.
Reflections
What I’d change next time
Looking back, I would involve Engineering earlier in shaping the system rather than bringing them in more deeply during implementation. This would help ensure design and code components evolve together from the start. I would also define adoption measures earlier — such as component usage and system coverage — so the value of the system could be tracked beyond the initial rollout. Finally, I would establish clearer ownership and governance earlier to make future decisions less dependent on individual designers.