Close
Type at least 1 character to search

Mozilla / Firefox

San Francisco, California

Acorn (Firefox) design system: Retooling and expanding Firefox’s design system during a major browser redesign, with a focus on designer usability, component architecture and craft, engineering alignment, and adoption and enablement.

My role
Senior system designer

Product type

  • Design system refresh
  • Design ecosystem

Principles

  • Systems thinking
  • Inclusive design
  • Accessibility
  • Brand cohesion
  • Ecosystem cohesion

Leadership

  • System strategy
  • Design governance
  • Cross-functional collab.
  • Adoption strategy
  • Support, training

Design + craft

  • Component craft
  • Visual design
  • Interaction design
  • Documentation
  • AI prototyping
  • AI content

Acorn at a glance

Acorn provides the foundations, components, patterns, and guidance used to design the Firefox browser. Its architecture accommodates browser-specific interactions, operating system differences, customizable layouts, and accessibility settings.

Project Nova

Project Nova was a major modernization of Firefox’s interface, introducing stronger visual expression, product personality, and moments of delight, as well as a moderate retooling of some interactions. The direction was informed by large-scale research, particularly with Gen Z participants. Although participants considered Firefox highly functional, many felt its appearance made the product seem dated.

Responding required the visual language, interaction patterns, and supporting system to evolve together. Nova provided an opportunity to address existing limitations while preparing Acorn for more ambitious product experiences. 

My role

I combined system direction with hands-on component craft, working across product design, accessibility, and engineering to translate emerging requirements into reusable solutions.

I served as a system, visual, interaction, and UI authority for the redesign, ensuring that newly introduced patterns aligned with brand, Firefox design standards, and engineering constraints, and were visually consistent across all surfaces. My work revolved heavily around design system governance, system architecture, component craft, engineering parity, and the enabling of teams to successfully adopt the updated, more robust system. I also guided adoption and supported designers as they applied the system to product work.

Three stations the design work moves through, round after round with different work each time. Proposed patterns, where multiple teams design into the system at once. System review, which asks whether a pattern is reusable, accessible, consistent and feasible, checking each in turn. Outcome decided, where it goes into Acorn or remains locally owned. The system Challenge Proposed patterns Multiple teams designinginto the system at once System review Is it reusable, accessible,consistent, and feasible? Outcome decided Goes into Acorn, orremains locally owned

The system challenge

The redesign moved quickly across multiple product teams that were exploring and delivering new UI patterns in parallel. Requirements continued to evolve, ownership was distributed, and teams often needed to make progress before every downstream use case was known.

Without clear governance, the redesign could easily have produced duplicate components, conflicting patterns, inaccessible solutions, and structures optimized for a single feature instead of the wider product. At the same time, applying rigid system rules too early could have blocked useful exploration and slowed the redesign.

The challenge was to create enough structure to protect the system while leaving room for teams to solve emerging product needs. This required judgment about when a design was mature enough to become a shared pattern, when a solution should remain locally owned, and when the system itself needed to change.

I helped teams work through this ambiguity by separating immediate product needs from reusable system needs. Proposals were evaluated for recurrence, accessibility, interaction consistency, technical feasibility, and their ability to scale across Firefox surfaces. This allowed the system to support experimentation while establishing clearer standards as patterns matured.

Design system strategy in four scenes: Foundations, architecture, tokens and modes; Component craft, flexible accessible parts; Adoption, the system applied in product; and Governance, shared decision-making, where adoption exposes gaps and resolved issues are folded back in. Foundations Architecture, tokens, modes Shapes whatcomponents cansupport Component craft Flexible, accessible parts Meticulously crafted,complex, inclusivecomponents Adoption System applied in product Enabling teams tobuild with foundationsand components Governance Shared decision-making Adoption exposesgaps, resolved issuesare folded back in Design system Strategy

Defining the strategy

I framed the work as a connected system transformation rather than a component production exercise.

A polished component would not solve the problem if it introduced architectural debt, could not be implemented consistently, or remained too difficult for designers to use correctly.

The strategy centered on four areas:

01.

Foundations and architecture

Strengthen the underlying structures needed to support new themes, surfaces, operating systems, and responsive behavior.

02.

Component craft and strategy

Translate new product concepts into flexible, accessible building blocks without accumulating unnecessary variants.

03.

Governance and partnership

Create shared decision-making practices across product design, system design, accessibility, and engineering.

04.

Adoption and enablement

Help designers understand and benefit from the advanced capabilities built into the system.

These areas were treated as interdependent. Architecture shaped what components could support. Product use exposed gaps in the architecture. Governance helped teams resolve those gaps consistently. Adoption feedback revealed where the system still needed to become clearer.

01. Foundations and architecture

I restructured portions of Acorn to address limitations exposed by the redesign and strengthen governance within the system itself. I embedded clearer guidance in component architecture, naming, library organization, and documentation, making intended usage and sources of truth easier to identify.

This work included:

  • Consolidating duplicate components and variants, and adding missing components.
  • Expanding component properties and nested instances to support intended customization.
  • Standardizing layer, component, and property naming.
  • Clarifying parent, child, and unpublished subcomponent relationships.
  • Standardizing component pages and documentation.
  • Confirming that variables, styles, effects, and dependencies came from the correct libraries.
  • Expanding support for Light, Dark, High Contrast, Private, and Smart Window modes.
  • Accounting for browser chrome, in-content surfaces, and operating system differences.

These changes made governance part of everyday system use and gave contributors clearer conventions to follow. Consistent naming, explicit relationships, and predictable structures also made the system more machine-readable, helping automated tools interpret components and their dependencies more reliably. 

Token and variable architecture

Acorn variables are closely aligned with engineering design tokens to improve parity between design and implementation. Tokens are managed through JSON and exchanged between Figma and the codebase, creating a shared foundation for color, typography, spacing, effects, and other system decisions.

01 · PRIMITIVE

violet-60

A raw value color, size, duration, spacing value. No meaning attached yet.

02 · SEMANTIC

brand.color.primary

Assigns purpose to a value, such as its role in the brand palette.

03 · COMPONENT

button.background.state

Applies that value to a specific component role or state.

ALIAS CHAIN

violet-60 ⇒ color-brand-primary ⇒ button.primary.background

This format allows for more granular control over token application, without an overly complicated token architecture. The entire system can be updated by changing the primitive, just a single brand can be updated by changing the semantic token, and individual components can be updated by changing the component level token.

Modes and contextual behavior

Acorn supports combinations of modes that reflect meaningful changes in Firefox. These modes change more than color. They can affect typography, border radius, window treatment, available controls, and component behavior. Encoding those differences into the system allows designers to move between contexts without manually rebuilding or correcting the interface. 

Firefox modes include:

Theme

Light, Dark, and High Contrast color modes.

Window type

Classic, Private, and Smart window modes.

Surface

Browser-specific, or content-specific modes.

Operating system

macOS, Windows, Ubuntu, and KDE

02. Component craft and strategy

I championed a principle for Acorn that was not a priority previously: the idea that the system should absorb complexity, not the user, to allow designers to focus their efforts on the experience they are creating. Because it’s important to consider that compliance is not the same as true adoption, and the latter is what should be strived for.

I brought related pieces together into more complete components, incorporating common anatomy, positioning, and behavior into reusable structures. The goal was to make routine tasks straightforward while balancing useful configuration with maintainability.

Architectural decisions focused on:

  • Which anatomy and behaviors were shared.
  • Which differences belonged in variants, properties, modes, or nested components.
  • Which controls designers needed to access directly.
  • Where flexibility is needed vs risked introducing unsupported combinations.

This approach placed recurring setup work within the library and made intended usage easier to follow, helping designers work more efficiently and consistently while preserving the flexibility to address product-specific needs.

Button component
Chrome top component

The Chrome top component is the primary (or default) Firefox browser interface, although there are also many other surfaces, such as vertical tabs, sidebars, settings, and more.

The Chrome top component is comprised of several nested components, including the tabstrip, toolbar, URLbar, bookmarks bar, and info bar. Slots are used in these nested components to allow designers to customize placement and options.

This component also uses boolean variables to show and hide elements across the modes. In the previews below, you’ll notice that the buttons shown in the classic, private, and smart windows differ. This is done automatically for the user as they switch between the window modes, ensuring the correct content is always shown for the different window types.

Note: in design and development, “chrome” refers to any visible part of a program or app that is not the primary content itself. For example, the toolbars, menus, tabstrips, and sidebars are part of the chrome). Firefox’s use of the word “chrome” is not related to Google’s Chrome browser, and long predates its existence.

Component craft deep dive: the Browser component

The Browser component is one of the most frequently used assets in Acorn because it provides a configurable, functional representation of the Firefox interface. Instead of requiring designers to assemble individual toolbars, tabs, sidebars, and content areas, it brings the browser structure together as a coordinated system. 

Top-level Browser component customizations include the default Firefox UI, vertical tabs layout, sidebar options, split window, custom tab groups, search and suggest panel, compact mode, toggle-able toolbars, auto responsiveness, slots for custom content, and all applicable modes. Any of these options can be combined to create fully customized UI designs, and every nested element includes its own set of advanced properties accessible from the component properties panel.

Browser component architecture

As with all components, I thoughtfully structured and built the Browser component to absorb the complexity of the nested hierarchy, as opposed to placing that work on the designers. All features of the browser are built into this component via nested instances, component properties, and modes, with just 4 top-level variants. This level of completeness helps ensure the UI is used correctly in UX flows, as it eliminates the need for designers to manually find, position, and use the individual components correctly. In addition to saving design time, this method significantly reduces, and often eliminates, design debt and entropy, extending the life of the current system iteration.

Slots and controlled flexibility

Slots allow designers to insert custom content into approved areas without detaching the component or breaking its architecture. They create flexibility where product needs are expected to vary while preserving the surrounding system structure and behavior.

This was particularly valuable for a browser system because product teams frequently need to demonstrate new panels, messages, tools, and content within the existing Firefox interface. Slots gave them room to explore those experiences while retaining accurate browser chrome, responsive behavior, and mode support. 

Patterns in product context

Acorn needed to support more than isolated components. Many Firefox experiences depend on several components working together across tabs, toolbars, panels, sidebars, notifications, settings, and in-content surfaces.

I evaluated new work in context to understand how individual decisions affected the complete experience. This included reviewing hierarchy, focus order, responsive behavior, mode changes, interaction feedback, and relationships between browser chrome and product content.

In-context examples and prototypes helped teams evaluate placement, composition, and behavior before implementation. They also made it easier to identify when a request represented a reusable Firefox pattern rather than a one-time arrangement of components.

This systems-level view became especially important when a technically compliant component decision created a weaker interaction in practice. The accessible button-state work was one example of using context to evaluate the full experience rather than treating each requirement in isolation. 

Color themes

Firefox supports custom colors and configurable tool placement. These examples demonstrate how coordinated palettes can create distinct appearances across the browser.

Color theme spectrum examples

03. Governance across teams

Deciding what belongs in Acorn

Nova required a governance model that maintained consistency without becoming a bottleneck. I worked directly with product designers during the design phase, helping them address accessibility, brand cohesion, interaction consistency, and technical feasibility before patterns entered Acorn. When reviewing a proposal, I considered:

  • Whether the need recurred across teams or surfaces.
  • Whether an existing component could support it.
  • Whether the proposal introduced duplication.
  • How it behaved across supported contexts.
  • Whether it could be implemented accessibly and consistently.
  • What guidance or guardrails adopters would need.

I presented recommendations as considerations supported by system knowledge, evidence, and product context. Patterns specific to one feature, or still undergoing significant exploration, could remain locally owned. Shared patterns needed clear behavior, supported configurations, and responsibilities for maintenance.

Championing shared system standards

I reinforced the governance model we established for Acorn, working with teammates and regularly correcting inconsistencies myself. That attention extended to:

  • Component controls: Property names aligned with engineering, with consistent configuration and ordering.
  • Internal structure: Predictable layer naming, case conventions, ordering, and parent and subcomponent relationships.
  • Dependencies: Correct token, style, library, and instance-swap references.
  • Component cards: Descriptions, code and documentation links, dependencies, supported surfaces, properties, nested components, accessibility annotations, and mode examples.
  • Guidance at the point of use: Instructions available directly in the Figma component panel.

These standards made contributions easier to review and the library easier to maintain as it evolved.

Cross-functional partnership

Design and product team partnership

I worked directly with product designers during the design phase to identify issues early and help designs move efficiently toward implementation. Our reviews focused on four questions:

  • Does the design meet accessibility requirements?
  • Is it cohesive with the Firefox brand?
  • Are the interactions consistent with established product patterns?
  • Is there an existing Acorn component or pattern we can use or extend?
A product designer and a design systems designer review a design together. The systems designer drops a comment pin on four parts of the design in turn: the button, the toolbar, the list and the toggle. The designer answers each one and the pin resolves, and the design moves from In review to Ready for build. DESIGN REVIEW In review Ready for build 1 2 3 4 Designer Systems

My approach is always to design with people, not at them. I truly believe there’s always more than one right way to design anything, so I don’t aim to police or make designer’s feel like pixel pushers. Instead, I share my professional opinions as considerations, not as finite design principles or mandates, so designers retain ownership of their work. And I base on my opinions on what’s best for the user, not myself personally. When a design doesn’t meet requirements, I’m clear about what needs to change and why, then work with the designer to find the best solution.

For Acorn, I balanced collaboration with system quality by being firm on requirements, yet flexible on execution, and involving designers early to reduce unnecessary iteration.

A Figma component's properties beside the matching moz-button markup. Each property is linked to its attribute. As the type, size, icon and disabled properties change in Figma, the matching attributes change in code at the same moment, and both button previews update together. Save Save Save Save FIGMA CODE type primarydefault size defaultsmall Icon bookmarkdownload disabled <moz-button type="primary" type="default" size="default" size="small" iconsrc="bookmark.svg" iconsrc="download.svg" disabled >Save</moz-button> >Save</moz-button> Properties map 1:1
Engineering partnership

I aim to involve engineering early when component anatomy, naming, behavior, or token decisions could affect implementation. The objective is to create shared structures that make sense in both Figma and code, rather than resolving parity problems after the design work is complete, or simply throwing specs over the fence at engineering. Early collaboration gives us space to discuss technical constraints, clarify assumptions, and make decisions together before those choices become costly to change. It also helps us establish a shared vocabulary, so designers and engineers can understand how a component is organized and how it should behave. 

For Acorn, I worked with engineering on: 

  • Aligning component naming with code.
  • Designing within technical constraints.
  • Reusing existing implementation patterns.
  • Connecting Figma variables to tokens.
  • Documenting states, behavior, accessibility, and responsiveness.
  • Prototyping complex interactions in code.

This partnership helped engineering constraints inform better design decisions without allowing implementation details to dictate the experience. It also gave engineers clearer guidance and reduced ambiguity during build.

Additionally, this approach supports machine-readability by keeping design structures and code more closely aligned. I see that alignment as an ongoing responsibility, with both teams contributing to a system that’s easier to maintain and scale.

Influencing without authority

I influenced decisions beyond my direct ownership by helping partners evaluate competing priorities in the context of the overall experience. Clear reasoning and evidence made tradeoffs easier to understand and helped us reach decisions we could support together.

Balancing A11Y compliance with context

During the Nova redesign, my teammates and I collaborated with product to develop button colors across Light and Dark modes. The original hover and active states used semi-transparent backgrounds, so the palette was adjusted to ensure that labels and icons remained readable against the button surface in every state.

Our accessibility partners raised an additional requirement: the button surface also needed sufficient contrast against multiple page backgrounds. Testing revealed that no single color system could satisfy both contrast relationships across every state and background while preserving visual cohesion and predictable interactions.

One proposed solution was to invert the button colors between states. It improved contrast in some combinations, but coded prototypes revealed a disruptive, flashing effect that made the states harder to follow. This exposed the limitation of evaluating contrast values in isolation: an adjustment could improve one measure, while making the overall interaction harder to use.

I didn't the final decision. so my contribution was to present the problem in the context of the complete experience to help the group reason through the competing requirements. By asking which is more important, the readability of the button in hover, or the contrast between the button and page in fringe color combinations in hover, I introduced a decision framework that clarified what was non-negotiable, where there was room to flex, and which outcomes deserved the highest priority.

Readable labels and icons in every state were the highest priority. Clear state feedback and predictable interaction behavior were also essential. Contrast between the button surface and page backgrounds remained important, but we needed to evaluate the less common combinations alongside the usability consequences of the proposed solutions.

I brought that framing into the discussion alongside contrast data and coded prototypes. The data showed where requirements conflicted; the prototypes showed what those conflicts meant in use. Together, they helped partners consider how each option affected accessibility, interaction quality, and consistency across the system.

We aligned on an approach that maintained compliant foreground contrast in every state, preserved smooth and predictable interactions, and brought the button surface as close as possible to the contrast target on less common backgrounds.

The decision moved forward through shared reasoning. By making the context and tradeoffs explicit, I helped partners with different priorities move beyond isolated contrast checks and reach alignment around the complete experience.

04. Adoption and enablement

Advanced capabilities needed deliberate introduction. Publishing a component did not ensure designers would discover everything it could do.

I strengthened 1:1 support, emphasized office hours, and introduced short training presentations every two weeks. Sessions covered new features or demonstrated more advanced functionality.

Slots were introduced through one of these sessions, using practical examples to explain where they were useful and how to work with them.

Support also informed system improvements. Questions revealed opportunities to clarify controls, naming, documentation, and guidance. Beyond Acorn, I mentored designers on Figma, prototyping, visual craft, interaction design, and broader design practices.

Raising the standard for support

During four weeks in December, I covered two teammates’ work and provided direct support to their designers through Nova’s component questions and ambiguity.

Two designers independently contacted my manager to express their appreciation. After my teammates returned, designers continued seeking my help, and the team strengthened its support to meet those expectations.

The experience demonstrated the value of sustained partnership and helped make it a stronger part of Acorn’s operating culture.

AI and machine-readable systems

I explored AI workflows that reduced repetitive system work and made knowledge easier to maintain. I packaged useful approaches into reusable Claude Code skills stored in GitHub repositories, making their rules easier to version and refine.

Finding design debt and system drift

Large Figma ecosystems accumulate hidden dependencies over time, including outdated styles, incorrect library references, detached assets, and components nested deep inside product flows.

Using Claude Code, custom skills, and the Figma MCP, I developed workflows that inspect files and identify where incorrect assets, styles, variables, and component references are being used. Instead of simply reporting that dependencies exist, these processes help locate the specific instances creating the problem.

Encoding audit logic into reusable skills also makes the process repeatable, so the same checks can be run as the system evolves rather than rebuilt as a new prompt each time.

Some AI solutions I explored using Claude Code and Claude Design for Acorn include:

  • Design debt and entropy identifier
    Figma will tell you how many assets and styles are being pulled from any added file, but it doesn't tell you where they are. Finding deeply embedded items is incredibly time consuming, so I created an agent that locates and logs all assets and styles within the system and product flows that are incorrect or pulled from incorrect libraries, allowing the design system and product teams to eliminate design debt and greatly reduce entropy going forward.
  • Variable / token consistency and structures
    An agent for scanning variables collections for redundancies, missing or incorrect styles, and token related errors. Eventually, we're wanting to use AI as a tool to perform automatic cross-updates in both code and figma.
  • System and component audits
    An agent that audits and records any design-to-eng disparity, redundant components, missing components or parts, and areas that could be streamlined or optimized better.
  • Multi-directional updates
    We're aiming to create a process where our coded prototypes are the actual codebase, and updates to either code or Figma will automatically update the other library for ultimate design and code parity.More advanced experiments explore how automatically updated markdown files can guide AI skills and agents. These agents can scan design and code sources, generate UI rules, answer system-related questions, and help maintain code parity, visual consistency, and brand cohesion.

Exploring tighter connections between design and code

One of my longer-term areas of experimentation is reducing the separation between the design system in Figma and its implementation in code.

Using Claude Code, Figma MCP, Cursor, and structured markdown files, I explored workflows where AI agents could read system rules, inspect both design and code sources, answer system-related questions, identify disparities, and potentially propagate approved changes between environments.

The longer-term goal is a more connected system where Figma and code remain synchronized with less manual maintenance, strengthening design-to-engineering parity while reducing opportunities for system drift.

Accelerating accessibility and contrast audits

Accessibility testing can become especially time consuming in Acorn because components often need to work across many opaque background colors, states, and theme combinations.

I used Claude Code to generate WCAG-focused accessibility reports that could evaluate large sets of color and contrast combinations much faster than checking them individually with manual tools. This was especially useful when validating text, icons, controls, and component backgrounds across multiple surfaces.

The reports helped me identify failures, edge cases, and patterns more quickly, giving me more time to focus on the harder design decisions where accessibility, visual quality, and usability needed to be balanced.

Prototyping complex system behavior

Some component concepts are difficult to communicate through static Figma screens alone, particularly when they involve responsive behavior, motion, nested interactions, or complex browser functionality.

I used Claude Code, Cursor, Figma Make, and Figma Agents to rapidly create functional prototypes based on Acorn patterns. One area of experimentation involved prototyping portions of the Browser component as working coded interfaces with accompanying specifications.

These prototypes helped make complex system behavior easier to evaluate with designers, engineers, and leadership before committing to implementation.

Streamlining component documentation

Maintaining detailed component documentation can be time consuming, particularly when specifications need to incorporate accessibility guidance, interaction behavior, and established platform conventions.

I developed a reusable Claude Code documentation skill to help structure and generate component documentation consistently. The workflow incorporates defined documentation rules and reference material, while tools such as ChatGPT and custom GPTs help with research and synthesis from public sources including Apple’s Human Interface Guidelines and Google Material Design.

Every output is reviewed and verified before publishing, but the workflow reduced the time required to produce a component entry by an estimated 70%.

Making system education more visual and engaging

AI also gave me new ways to communicate design system concepts beyond traditional documentation.

I experimented with Figma Weave, Nano Banana, and other generative visual tools to create custom imagery, motion, video, presentation graphics, and higher-fidelity demonstrations for training and adoption materials.

This is especially useful for explaining how components behave rather than simply showing how they look. It also allows me to explore visual direction and motion earlier, helping designers and engineers better understand how an experience should look, move, and feel.

Where I made the biggest difference

  • Making designer usability a system priority: Bringing everyday workflows into architectural and component decisions.
  • Raising expectations for support: Establishing more direct partnership and practical education for designers.
  • Applying governance consistently: Carrying shared standards into everyday component construction and maintenance.

Outcomes and system impact

The Nova redesign shipped with a stronger system foundation capable of supporting Firefox’s evolving interface, while maintaining accessibility, consistency, and engineering alignment. 

System outcomes
  • Reduced duplication through more capable component structures.
  • Expanded configuration and contextual mode support.
  • More consistent build standards, documentation, and token alignment.
Team outcomes
  • Broader adoption of updated components and advanced features.
  • Less review friction through clearer expectations and earlier collaboration.
  • Stronger access to support and a more direct feedback loop with system maintainers.
Product outcomes
  • A more cohesive and contemporary Firefox interface.
  • More consistent interactions and visual states across surfaces.
  • Clearer translation of product designs into implementation.

Reflection

Nova reinforced that system quality includes the experience of using and maintaining it. Technical capability becomes valuable when designers can discover it, apply it confidently, and carry its intent into implementation.

It also sharpened my judgment about where standards need firm boundaries and where contextual evaluation creates better solutions.

In future work, I would establish clearer baselines for common design tasks, including setup effort, errors, and assistance needed. That would provide stronger evidence of which system improvements help designers most and where further investment is needed.