Azion Design System
Azion is an edge platform for building, publishing, and operating web applications. Its Console is the interface where developers and engineering teams configure workloads, protect environments, and manage technical resources at scale. The Azion Design System is the shared interface foundation behind that Console, the website, documentation, and internal products, bringing together tokens, components, documentation, and usage criteria so design and engineering can work with more consistency and predictability. Before that foundation, style and implementation moved with little sync: static style guides, local components, and different patterns for similar needs. The system was built to turn that fragmented legacy into a shared language, and it evolved with the product ecosystem, from custom components to PrimeVue and Tailwind, with governance, versioning, and Design QA along the way.
From fragmented patterns to a shared foundation
Azion operates a broad ecosystem of technical products: Console, corporate website, documentation, and internal tools. Each surface evolved at a different pace and with different constraints, but all shared the need to ship complex interfaces with more speed and predictability. Before 2021, much of the interface came from Django-based legacy code, static Figma style guides, and implementations that rarely aligned. Similar patterns had different interactions, new components appeared on almost every screen, dozens of table implementations coexisted with distinct behaviors, and handoff required heavy interpretation. The main business pressure was clear: ship faster without losing quality. The Azion Design System started in that context, in parallel with the Console's visual and technical overhaul. Not as a rebrand, which would come later, but as infrastructure to bring design and engineering closer around a more shared language.
Challenges
- Replace static style guides and divergent implementations with a shared source of truth.
- Standardize interaction patterns without ignoring the complexity of developer-facing products.
- Increase velocity during the Console redesign without compromising quality and maintainability.
- Bring Figma components, documentation, and implementation closer together.
- Support Console- and site-specific needs without fragmenting the Core layer.
Responsibilities
- Operational management and structuring of the Design System
- Component auditing and prioritization
- Foundations, tokens, and component architecture
- Documentation and governance
- Design QA and implementation follow-through
- Facilitation across design, product, engineering, and stakeholders
- Research and adoption of PrimeVue and Tailwind
- Evolution of the Figma-to-code connection
Goals
Build a reusable foundation to accelerate ecosystem evolution.
Unify experience patterns and shared language between design and engineering.
Structure documentation and governance to sustain adoption over time.
My role
I handled much of the Design System's day-to-day operations from the design side, in partnership with engineering leadership. The role sat closer to staff and ops than to formal lead: I organized meetings, structured the workflow, reported progress to managers and directors, and managed a large share of the system's ongoing work, from component inventory to tokens, design, documentation, governance, and Design QA. My technical contribution helped reduce the distance between Figma and implementation: closer naming, aligned properties, and clear review criteria. I also researched and proposed adopting PrimeVue and collaborated with engineering on architecture and the wrappers that extended the library. I influenced many decisions, but they were debated collectively with design, engineering, and, when needed, managers and directors. I had autonomy to operate and propose, without unilateral authority over every component or variant.
How could we turn a fragmented legacy into a shared source?
Problem
The ecosystem carried Django legacy code, copy-pasted style guides, divergent components between Figma and code, inconsistent interaction patterns, and dozens of table implementations. Every new screen added interface debt.
How we solved it
We ran a screen-by-screen audit across Console and website, mapped existing components, grouped overlaps, and classified needs into Core, Console, and Site layers. A priority matrix combined component importance, development ease, and ability to deliver quickly.
We gained a concrete view of interface debt, reduced perception-only decisions, and formed an initial roadmap with clarity on what to reuse, rebuild, or retire.
Where should we start without blocking product delivery?
Problem
The system had to emerge while teams kept shipping. Waiting for a complete library was not viable, and isolated components would not prove the architecture worked on real screens.
How we solved it
We started with tokens and foundations, moved to buttons, cards, menus, and recurring layout structures, and built an MVP in Storybook. We applied components on Home, Edge Applications, and Functions, in parallel with product delivery.
We validated the architecture quickly, collected continuous feedback, and tested components in real context, with incremental system evolution.
When did building everything from scratch stop being the best decision?
Problem
The first architecture used custom components, but the team needed to redesign much of the Console in about six months and many Core components were still missing. Keeping the same pace would put the deadline at risk.
How we solved it
We adopted PrimeVue as the base, applied Azion tokens, used Tailwind as a shared language between design and frontend, and preserved custom patterns where they mattered. Console Kit became the library developers could consume.
We reduced time to build the initial library, lowered the learning curve, and sped up screen migration, without treating the earlier architecture as a failure, but as a trade-off between control and speed.
How could we gain speed without being constrained by the adopted library?
Problem
PrimeVue accelerated the first stage, but over time we needed variants, properties, and behaviors the library did not support. Changing components directly would increase coupling and make maintenance harder.
How we solved it
We created wrappers that encapsulated PrimeVue components, preserved useful properties, added Azion-specific properties and variants, and adapted APIs to the Console context.
We balanced speed and flexibility, extended components safely, and gained control over specific behaviors without abandoning the existing base.
How could we reduce the distance between Figma and implementation?
Problem
Design and code components did not always match, handoff required interpretation, new screens created local variations, and some decisions were lost between design, development, and QA.
How we solved it
We created handoff sheets, aligned naming and properties, documented in Zeroheight, Storybook, and later on a custom platform, and brought token logic closer to the structure used in Tailwind. In recent phases, we evolved the connection with Figma MCP, GitHub, and design-to-code tooling.
The shared language improved, with fewer ambiguities, more objective review, and more efficient Design QA. The design-to-code relationship evolved progressively, without full automation.
How did we decide what belonged in the Core?
Problem
New products and screens generated requests for components and variants. Promoting everything to Core would increase complexity; keeping everything local would recreate the initial fragmentation.
How we solved it
We discussed proposals with a mostly senior group, checked whether an existing component could solve the need, assessed reuse potential, and classified each solution into Core, Console, or Site layers. Relevant decisions were shared with engineering and escalated to managers when needed.
We reduced component proliferation, clarified boundaries, and gained predictability to meet local needs without weakening the shared system.
How could the system evolve without losing traceability?
Problem
Shared components affected multiple experiences, changes needed to be understood by different teams, and Figma, code, and documentation could drift apart.
How we solved it
We distributed the library via NPM, versioned releases with commit-based Semantic Release, maintained a changelog and matching Figma versioning, and documented component evolution.
We gained clearer change visibility, safer adoption of new versions, and better communication among consumers, with a more sustainable maintenance base.
How could a new brand be applied without rebuilding every product?
Problem
The 2025 rebrand brought new colors, typography, and communication patterns. Applying changes manually in each product would recreate inconsistencies across an ecosystem spanning Console, website, documentation, and internal tools.
How we solved it
We incorporated brand decisions into foundations and tokens, reviewed components and states, propagated changes through the system, and preserved layer-specific needs.
The new identity was adopted more consistently, with less update effort and fewer local changes, demonstrating the Design System as product and brand infrastructure.
Quantitative Impact
- 4.000+
- Active users served by the Azion Console
- +74%
- Development velocity
- +83%
- Performance compared to legacy
Qualitative Impact
Greater consistency across different product areas
Faster delivery with reusable components
Less ambiguity between design and implementation
More predictable Design QA
Stronger collaboration between design and engineering
More efficient rebrand adaptation through tokens
Clearer governance for components and variants
Other assets
In retrospect
What worked especially well was auditing against the real product, prioritizing by impact and speed, building in parallel with delivery, and collaborating directly with engineering. Adopting an existing library was a pragmatic call to meet the redesign timeline without abandoning custom patterns that still mattered.
Today I would treat metrics, documentation, and governance as measurable deliverables from the start of each phase. I would also establish a baseline to track adoption, performance, rework, and development time before migrations.
The project reinforced Design Systems as internal products and shared infrastructure. It brought my practice closer to Design Engineering, component architecture, and build-versus-buy decisions in technical products.
Other cases