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
Principles
Leadership
Design + craft
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 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.
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.
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.
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:
Foundations and architecture
Strengthen the underlying structures needed to support new themes, surfaces, operating systems, and responsive behavior.
Component craft and strategy
Translate new product concepts into flexible, accessible building blocks without accumulating unnecessary variants.
Governance and partnership
Create shared decision-making practices across product design, system design, accessibility, and engineering.
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.
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:
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.
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.
A raw value color, size, duration, spacing value. No meaning attached yet.
Assigns purpose to a value, such as its role in the brand palette.
Applies that value to a specific component role or state.
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.
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:
Light, Dark, and High Contrast color modes.
Classic, Private, and Smart window modes.
Browser-specific, or content-specific modes.
macOS, Windows, Ubuntu, and KDE
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:
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.
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.
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.
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 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.
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.
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
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:
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.
I reinforced the governance model we established for Acorn, working with teammates and regularly correcting inconsistencies myself. That attention extended to:
These standards made contributions easier to review and the library easier to maintain as it evolved.
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:
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.
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:
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.
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.
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.
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.
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:
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.
The Nova redesign shipped with a stronger system foundation capable of supporting Firefox’s evolving interface, while maintaining accessibility, consistency, and engineering alignment.
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.