When I joined Brave as a Product Designer, I encountered a familiar challenge that many rapidly growing companies face: a fragmented design system with inconsistent user experiences across different products and platforms.

The implementation of Nala has transformed how Brave approaches product design and development. Some highlights are:

Significantly reduced time spent on component creation and reduction of duplicate occurrences.

Substantial decrease in design inconsistency reports.

Notably faster design-to-development handoff time.

Eliminated orphaned design tokens through cascading updates: changes to foundational tokens (like a color shade) now automatically propagate across all products and instances, ensuring complete system-wide consistency.

New Chromium features are not headache inducing for us anymore. If they add or change something, we can probably just take it in without needing to spend days or weeks patching up our customization layer (not always, of course).

Reduced design debt across all products. Now updates don't even require coordination from designers or developers from a pod to make any changes, they come from upstream to all teams at once.

Decrease component-related bug reports.

Achieved high component reuse rate across new features.

Significantly reduced new features development time.

Fostered cross-team collaboration through shared component development: developers from different pods now contribute to a central component library, reducing duplication of effort and increasing knowledge sharing across teams.

Prevented component duplication through centralized oversight: my role provides a company-wide view of all design work, allowing me to identify opportunities for component reuse and standardization across different products and teams.

Markedly increased designer productivity and reduced time spent sweating out little details or figuring out component edge cases.

Shortened development cycles for major features.

Achieved widespread design system adoption across teams.

Substantial reduction in development hours and QA testing times.

Architecting and building the design system from the ground up.

Creating and maintaining product libraries across all platforms.

Creating flexible components, and making sure they were adaptable to as many requirements as possible, giving designers more freedom of use.

Establishing processes for design-to-development handoff and component documentation.

Facilitating communication between design, product and development teams.

Leading the migration to a Material Design-based token architecture after Chromium's 2023 material you update.

Rather than creating a one-size-fits-all solution, I developed a three-level architecture that balanced consistency with flexibility:

A perceptually uniform color system with predictable contrast ratios.

Typography foundations.

Basic components (buttons, inputs, tooltips, illustrations, icons, etc.).

Cross-platform design tokens.

Specific components and patterns for the desktop browser.

Material Design components and patterns for Android.

iOS-native design patterns.

Web-specific components.

Custom components for Brave Search.

Specialized UI patterns for Brave Wallet.

Unique elements for Brave News and Leo.

Of course, since most of our products live within the browser UI, there's a lot of cross-referencing between the different libraries: Our Wallet, for example, has implementations that live within the browser in all platforms, but also has a web version. So they all have to be in sync and make for a streamlined experience.  

Typography scale with responsive breakpoints and OS specific variables (MacOS / Windows / Android / iOS / Web).

Spacing and layout grid systems.

Shadows and other effects, like blurs, glass effects, etc.

Grid systems.

Component-specific tokens.

Animation and transition definitions.