Case Study — 02
Ahua Design System
From two regional systems into Yara's global system of systems. Ahua unified a fragmented design landscape across platforms, regions, and teams — becoming the single source of truth for all of Yara's digital products worldwide.
Two systems.
No common
language.
By late 2021, Yara had two independent design systems serving different ends of the business: Ahua for mobile-first products in Asia and Africa, and Fertilise for web-based products in Europe and the Americas. Each system had unique components, token structures, and conventions, with no bridge between them.
This led to a company with a unified brand but fractured product experience. Teams duplicated and diverged on identical UI patterns, lacking a governance model, a contribution framework, or a single accountable team. Design decisions remained local and opaque, hindering cross-system visibility.
One token layer.
All platforms.
The architectural foundation for Ahua's expansion was a unified token model that could serve both mobile and web without maintaining two parallel structures. The token architecture was redesigned to be platform-agnostic at the semantic layer — the same colour.interactive.primary token resolved to the correct platform value, whether rendered in a React Native app in Kenya or a web dashboard in Norway. The token layer became the single contract that both platforms consumed.
Component architecture followed similar principles. Ahua's slot-based system ensured consistent component composition across platforms, enabling product teams to assemble complex UI patterns from shared primitives without duplicating logic. Navigational components — among the most platform-specific patterns in any system — required the most architectural investment, demanding custom slot structures that honoured each platform's conventions while remaining part of one unified system.
Standards that
travel without
me.
A design system used across countless product teams in multiple regions and time zones can't scale through central gatekeeping. I built a contribution and collaboration framework that defined how designers across the organisation could propose components, submit changes, and participate in system decisions — with oversight from the DS team, but without requiring sign-off on every individual commit.
Decision-making protocols defined clear ownership boundaries: system-level decisions vs product-level decisions, architectural changes vs local adaptations. This transparency eliminated the opacity that had made the old systems frustrating to work with. Contribution rates increased not because designers were pressured to contribute more, but because the path to contribution was finally clear and the outcome of each request was predictable.
Building the
team that builds
the system.
I hired and managed the team's first intern — my first direct report — deliberately delegating component execution work to free my own capacity for complex architectural problems: navigational components, the slot system architecture, and the cross-platform token model. We introduced 2-week sprints with defined rituals, providing the team with a predictable structure without sacrificing the flexibility design system work requires.
Figma branching was implemented to enable isolated component development — parallel work on the library without polluting the main file. In-tool review processes meant changes could be evaluated and approved before merging, creating a quality gate that didn't rely on verbal agreements. The intern grew into a full-time Junior Designer — a deliberate outcome built through structured delegation and mentorship, not a coincidence.
