Patagonia's AI Agent
Conversational B2C interface shaped by the brand's personality and values.
Awin Design System
Building a scalable, token-based design system for a global B2B SaaS platform, aligning design and engineering while supporting complex, data-heavy interfaces.
Role
Senior UX/UI Designer (IC)
Main Goal
New scalable foundation
Challenge
An increasingly fragmented platform
Awin's growth from 2 to 10+ dev teams triggered a UI breaking point. Without a unified system, squads operated in silos. Design patterns were "repeated" rather than "reused". Teams were constantly recreating components from scratch.
The platform hosted five different date-pickers, each with accessibility gaps. Maintenance became a "consistency tax": rebranding required manual fixes across hundreds of instances instead of a simple token swap.
On top of that, Awin runs as a white-label platform: the same components had to render under multiple white label brands.
Approach
From UI audit to scalable design foundations
1. Comprehensive Interface Audit
I began with a comprehensive audit of key dashboards and reports, cross-referencing behavioral analytics (Amplitude and Hotjar) with heuristic evaluations and Lighthouse audits. This data-driven approach moved the conversation beyond visual critique, allowing us to pinpoint high-impact usability gaps and user friction where it mattered most in real-world usage.
2. Strategic Scoping
To define scope, I mapped the platform via a component-to-page matrix and scored each page in a prioritization matrix across component coverage, build complexity, technical independence, and usage. This informed a phased rollout that prioritised proof-of-concept speed over visual impact.
We chose the Link Builder as the first live pilot. It served the largest user segment (publishers) and was built almost entirely from form primitives (inputs, buttons, selects), the highest-coverage components. A simple page first let us prove the architecture before applying it to data-dense surfaces. See the rollout trade-off
Starting with a low-risk pilot meant the most marketable pages, Dashboard and Reporting, wouldn't show systemised UI for months. To keep stakeholders aligned in the meantime, I built high-fidelity prototypes of both. These functioned as a future-state artifact, making the design system vision tangible and showing a direction rather than just a first step.
3. Token Architecture and System Foundations
Components were standardised in Figma but not tokenised at source. I chose a three-layer token architecture: primitives hold raw values like colour hex codes and pixel measurements, semantic tokens express intent across the system, and brand tokens provide per-brand or per-component overrides on top of the semantic layer. Components render under multiple brand identities by swapping only the brand layer. See token layers
-
Primitives : color, typography, spacing, radius -
Semantic : [ type | variant | modifier ] -
Brand : awin, white-label-1, white-label-2
On top: atomic component hierarchy, WCAG AA contrast with data-viz palettes, an 8pt spacing system with density variants, and Inter typography for legibility in dense tables.
4. Governance and Adoption
I introduced a hybrid contribution model: a small stewardship team owned foundations and tokens; product squads contributed components back. New components had to meet three criteria before they were built:
- Reach: used in more than 2 scenarios?
- Fit: brand-agnostic and fits across diverse contexts?
- Build vs extend: can the system already cover this?
New-built components then entered a review or "incubation" period before adding them to the core library. This included real-use evaluation in product contexts, API fit and UX intent assessment. Additionally a final quality gate (a11y tests, token lint, and visual diff) before merge. Unmet criteria didn't mean rejection but a documented local path.
Solution
A unified design language
Teams build from the same parts. Squads compose from one shared library and contribute new components back through a review path, so no team rebuilds what another already has.
A rebrand is a configuration change. Brand logic lives in one token layer, so a new brand or white-label client changes values in that layer instead of code across hundreds of screens.
Quality is set at the foundation. Accessibility, contrast and density are built into tokens and components, and every addition is tested before merge, so dense data screens stay readable under every brand.
See documentation examples: Typography | Color | Input
Impact
What changed
- 1 shared library across 10+ squads: replacing components each team had built on its own.
- 3 questions before anything is built: reach, fit, and whether the system already covers it. Components that don't pass get a documented local path.
- Figma to code parity: both use the same tokens and properties, so handoff is a token name instead of a value to re-measure, and visual diff catches any mismatch before merge.
- WCAG AA contrast across UI and data-viz palettes: held by accessibility tests, token lint and visual diff before every merge.
- 0 licensing cost for typography: Inter, an open-source typeface, chosen for legibility in dense tables.
Result
Screens
- Semantic spacing
- Optimized Typography
- WCAG AA accessible
- Atomic architecture
- Improved touch targets
