01
Three variants
Problem. 19 button variations with unclear hierarchy across products.
Solution. Three core variants: primary, secondary, and CTA, with CTA reserved for the single conversion action on a page.
ASUS · Design Systems
Built the web design system every new ASUS site starts from
I scoped ASUS's web design system for adoption over completeness. Design-discrepancy tickets fell ~60% and brand compliance rose from ~60% to ~95% within six months.
- Product
- Web Platform Design System
- My role
- UI Designer & Design System Architect
- Timeline
- Q3 2021–Q4 2022
- Team
- DMURD1+1
TL;DR
Every team rebuilt the same UI.
Across 18 months (Q3 2021–Q4 2022) I led the web design system from audit through rollout: scoped high-frequency patterns first, consolidated 19 button variants into 3, and made the system the default starting point for new ASUS web projects.
The problem
Duplicated work
International design teams across global and regional units rebuilt buttons, forms, and navigation from scratch on every project.
The solution
Foundations first
Stricter foundation rules and shared tokens so teams reused patterns instead of reinventing them.
What I owned
I led the system
Foundations, token strategy, component specs, and the documentation framework, with two designers on component production and doc authoring.
Key outcome
60→95%
Brand compliance rose from ~60% to ~95%, scored against the brand team's page-audit checklist. New web projects started from the system, not a blank file.
Problem
Same product. Different UI every time.
ASUS was scaling web experiences across global and regional teams. UI patterns diverged because every project started from a blank file. Each launch added design debt: duplicated specs, inconsistent QA, and regional sites that looked like different brands.
Before the system: Before the system: the same product card in the old Myriad Pro styling — inconsistent buttons, pricing, and type.. After the system: After the system: the same product card rebuilt on TT Norms Pro with system buttons, tokens, and type scale..
Stakeholders
One system, many priorities.
The primary user was not the visitor. It was the designer opening a blank Figma file on Monday.
Research & reframe
Perfect system or adoptable system?
The audit showed duplicated components, inconsistent spacing, and multiple text styles used for the same purpose. But it also showed why. Regional teams had real local constraints: different markets, launch calendars, and fonts.
Teams did not need a complete library on day one. They needed high-frequency patterns they could ship on the next project: strict where consistency mattered, flexible where regions legitimately differed.
Old question
How do we standardize every component across every product?
Real question
What must be identical everywhere, and where do regional teams keep the freedom they actually need?
Key insight. Strict foundations, flexible composition. Otherwise the regions fork the system and we lose them.
My role
What I owned and what was shared.
I led foundations, token strategy, component specifications, the documentation framework, and system maintenance. Two other designers built component production and authored docs against the standards I set. Three designers, one shared source of truth.
The solution
From audit to rollout.
01
Audit & discovery
With UX research, I documented layout, type, color, spacing, and component drift across live ASUS sites in a dedicated Figma file. The findings became the scope list for v1.
02
High-frequency first
Buttons, forms, navigation, and the core type and color rules: the patterns teams rebuilt most. Scope was deliberately constrained so the first release was adoptable, not exhaustive.
03
Shared baselines
Color, typography, spacing, and grid. Stricter foundation rules with flexible composition on top.
04
Core web components
Structure, states, and responsive behavior built from real usage across ASUS products.
05
Specs teams could use
Notion docs with design intent, variants, tokens, and accessibility specs. The reference engineering built against.
Design details
Nineteen variants became three.
Buttons were the highest-frequency inconsistency: six heights, no clear hierarchy, and many variants failed contrast.
02
Size system
Problem. Six heights with no naming convention.
Solution. Small, medium, and large with consistent padding and touch targets.
03
Accessibility
Problem. Contrast failures across light and dark themes.
Solution. Every variant validated for WCAG 2.1 AA, with the passing foreground/background pairings documented as rules.
Design decisions
Three decisions that held the system together.
01
Structured blue scale
10 shades mapped to use cases. Every pairing validated against WCAG 2.1 AA.
Trade-off: less decorative flexibility, but predictable hierarchy and accessible color in every context.
02
Meaning over appearance
Information, success, warning, and error tokens. Intent stays consistent across products.
Trade-off: upfront alignment across teams, but clarity that scales as new products adopt the system.
03
Global structure, regional flexibility
Font order with fallback rules for markets where the primary typeface is unavailable.
Trade-off: more setup complexity, but hierarchy holds across languages without layout breakage.
The hard part
What to standardize, and what to leave alone.
The hardest work was not drawing components. It was deciding what to unify and what to leave regional.
/ 01
Too much
Force one component everywhere and regional teams fork it. System on paper, drift in production.
/ 02
Too little
Leave every variation and nothing consolidates. The blank-file problem comes back.
/ 03
The call
Unify foundations hard, keep composition open where markets truly differ.
Adoption & maintenance
Adoption was a process, not a launch.
Building components was the easy half. Adoption took an operating rhythm, and a standard easier to reach for than a blank file.
/ 01
Introduce
Workshops and reviews walked teams through the system before they needed it.
/ 02
Communicate
Every token or component change shipped with an announcement and updated docs.
/ 03
Maintain
Versioning kept docs and implementation in sync as teams adopted at different speeds.
Final design
What shipped in the system.
Foundations, components, and documentation that became the default starting point for new ASUS web projects. ProArt and later launches shipped from these shared foundations instead of one-off rebuilds.
Impact
What changed after adoption.
Measured six months after v1 rollout, against the pre-system baseline. Each number below names how it was tracked.
/ 01
~0%
Fewer design-discrepancy tickets
Internal Jira tickets logged for mismatched components across pages. Standardizing buttons, forms, and navigation first drove the drop, comparing the six months before and after adoption.
/ 02
60→0%
Brand compliance
Scored against the brand team's page-audit checklist across global and regional sites. Shared typography, color, and spacing reduced visual drift between teams.
/ 03
~0%
Fewer design–dev mismatch tickets
Tickets filed when built UI diverged from the published spec. Once components had a single source of truth and handoff docs, behavior became predictable across products.
/ 04
~0%
Fewer WCAG violations
From accessibility audits of production pages. Contrast and states were validated in the component spec, so accessibility was built in, not patched in QA.
Conversion
+15%
Shared components and consistent commerce patterns lifted conversion across official website and e-commerce experiences.
User satisfaction
+18%
A more consistent, accessible experience across pages raised measured satisfaction.
Experience templates
30+
Core experience templates the system supported, from category and product detail to compare, campaign, and checkout.
Reflection
Adoption matters as much as the system.
Constraints scale
Stricter foundations upfront beat a theoretically complete system teams would not adopt.
Alignment is design
Deciding what to standardize and what to leave regional was the design work, not a step that came after it.
Docs are a product
Specs that explain why a decision exists get used. Rules without rationale get ignored.
Looking back, what made it work was not completeness. Teams adopted the system because reaching for it was easier than starting over, and that was a design decision too.