Updating our web system for a new era

Back in 2020, we shared how we built our design system for our website, figma.com. That site had one job: to introduce a new design tool to the world. Fast forward to 2024, and things look pretty different. Figma has gone from a design tool to a platform for all kinds of product teams, and our web presence needed to keep up.

As a designer on the Brand Studio team, I saw firsthand how our previous system was starting to show its limitations. We had many components in our library that were only slightly different from one another, making it challenging for designers and content authors to choose the right one. Our color system wasn’t flexible enough to accommodate our evolving brand palette, and our typography wasn’t optimized for the range of content we now produce. As our product ecosystem grew, we needed a web presence that could showcase everything we do now, help different people find what they need, and really show off what’s possible with Figma.

Our latest brand refresh proved the perfect impetus: From our new Figma Sans typeface to our revamped illustration style, we wanted to create a cohesive look that represents who we are now, and that meant bringing it to life across our website, too. This story is about our journey—but we hope that it can also serve as a catalyst for other design systems teams looking to improve their own systems. Whether you’re dealing with component sprawl, struggling with color management, or figuring out how to organize your type styles, we hope that you’ll find actionable approaches here that you can apply to your own work.

Rethinking our components

Components have always been a big part of how we work in Figma, but this refresh gave us a chance to rethink how we use them in our web system. We wanted to conduct an audit to get a better understanding of how they were currently working (or not) across our web pages.

The Web Experience team ran a script that showed us which components were used, how often, and across which pages. This highlighted opportunities to simplify our system, including our ‘flex’ component—one of our most widely used building blocks. The original version had ballooned to 48 variants as we added options over time. After auditing how teams actually used it, we were able to streamline it down to 24 variants while maintaining its core functionality. We also made some key decisions about consistency, like removing centered text as an option so that left-aligned text became the default throughout the entire web system. The result? A more focused property panel that made the component both easier to use and more aligned with our refreshed design language.

These decisions not only simplified our component library but also made it more flexible and easier to use. Now, instead of being faced with a range of choices—many with the same functionality—the web designers and builders who use our library are able to select from only the best solutions for their needs. We also made templates for common page layouts and a set of “building block” components that can be combined in different ways, making it easier to create on-brand pages.

This shift from our original “FLEGO” (Figma + LEGO) system to our current component library reflects a fundamental change in how we think about scalable design. Where our old system treated components as independent building blocks—like LEGOs you could stack together—our new approach is more integrated. For example, our old system had separate components for text containers with different alignments and backgrounds. Now, we use variables and nested components to handle these variations, reducing redundancy and making updates easier to manage. This not only simplifies our library but makes it more maintainable and efficient as we grow.

Playing with prototypes

Once the rest of our Brand Studio nailed down the key elements of our refreshed visual language, our web design team—including myself and Designers Andy Luce and Catherine Bui—started exploring how it could manifest on our website. Figma has a strong prototyping culture, so we began with prototyping which let us explore ideas without being held back by our existing system. We could quickly try out different interactions, test how designs would work on different screen sizes, and play around with motion.

One big focus was rethinking our call-to-action (CTA) buttons. It’s such a small component, but it’s everywhere. We knew if we could imbue a little bit of the brand there, it would be really special. At the same time, we were still in the process of finalizing the brand refresh, and didn’t know yet which parts of the brand would make sense to incorporate here. So, we made a grid of over 50 button prototypes, trying out different states, animations, and ways they could adjust to different screen sizes. We explored jumbo buttons and really small buttons, and buttons that expanded on hover, revealing more text or changing color.

Being able to test these buttons in context helped refine our ideas quickly, vetting the ones we liked best before taking them to the wider team. We tested how different button styles worked across various components and page layouts. There were quite a few buttons that we loved in certain instances, but they didn’t work across others, which we only discovered once we dropped them into a prototype. For example, we experimented with a ‘deconstructed button’ that played around with color-blocking (similar to highlighted text), and that could expand to show an arrow on hover. We loved how unique and bold it felt, but the expanding size on hover made it difficult to place next to other content, or in layouts like the pricing page, where we need consistent button width.

We also used prototyping to work out more complex elements, like our new sign-up outro CTA that appears at the end of pages. We explored how a component like this could impact user flows and aid in product storytelling across different screen sizes. For our product hero sections, prototyping let us fine-tune sizing and test different content orders with the wider team. Being able to try these variations directly on our devices helped us narrow down the best solutions before handing them off to Matt McDonald, Senior Web Developer on our Web Experience team. This saved time during development and Quality Assurance (QA), since we’d already validated our design decisions through prototyping.

Similarly, interactive prototypes let us fine-tune behaviors with our Brand Motion Designer Gilles Desmadrille. Our Brand Studio indexes high on motion—we have a whole motion design team—and being able to think through those interactions at the onset lets us make motion elements feel much more intentional and integrated. We experimented with subtle hover animations for buttons, smooth transitions between sections, and playful micro-interactions throughout the site. Prototyping these experiences meant that we knew the exact transition time and easing we wanted and were able to provide those details to Matt and our development partners on the Web Experience team so they could build them—exactly as we had it in Figma—again, saving us from finessing those details in QA.

Branching and organizing our work

As mentioned, much of the visual brand refresh was happening concurrently with this work, and we often wanted to test the developing visuals alongside the web system while we were overhauling it. This is where Figma’s branching feature became critical. Working on a branch let us try out elements like our in-progress typeface across our whole system without disrupting our main working file. In this way, we could easily switch between branches to see how different versions of the typeface affected our overall design.

This approach not only kept our files organized but helped with decision-making. We could compare different beta fonts in the context of our actual type stack (the hierarchy of text styles used across our site). For example, we could see how different weights and widths of Figma Sans letterforms performed at various sizes, from headlines to body text, and how the typeface interacted with our other design elements. We could then share that feedback with the type foundry Grilli Type, making the final typeface a lot more accurate and representative of how we would actually use it.

We also rethought how we organize our type styles. Instead of separate type stacks for mobile, tablet, and desktop, we organized everything by headlines and body size. This made it much easier to implement our type stack across all screen sizes once we finalized our type changes, while also improving usability for others using our library.

Using variables to keep things consistent

Our ‘Color Library’ variables collection.

Historically, if we wanted to have a quote component in white text on black or black text on white, we’d have to make a different component for each version. Variables changed all that—and we were eager to implement the new feature in our web design system.

The new visual language introduces a palette of 29 colors, with 25 in use as backgrounds on web. To maintain accessibility standards, we established specific color applications—black or white for body text, and three distinct red shades for form errors. Catherine structured these requirements into color variables, building themes that scale seamlessly throughout the system. UI3’s updated eyedropper has improved this process: Now we can instantly capture and apply colors while preserving system consistency. The tool lets us pick up color variables and styles directly, or create new ones as needed. Being able to quickly tab through different color formats (hex, RGB, HSL, HSB) and copy them directly to our clipboard streamlines our workflow, especially when sharing color values with our development team.

This upfront work paid off in the component library—reducing the need for dark and light variants of each component. Instead, variable modes and color themes let users swap between different background color combinations while ensuring color contrast accessibility and consistency. And when our Brand Studio needs to make global changes, like adjusting a color value, we can do it easily and see the changes show up throughout the entire system.

Calling out details with Dev Mode annotations

Dev Mode was another new feature we were excited to try out more during this update, and played an important role in how we worked with development. We used annotations extensively to document design considerations across all components and breakpoints. We also used them to clearly specify how many columns each item in the design took up, which helped designers systematize their width decisions at each breakpoint and made it easier for our developers to build.

Web Developer Winter LaMon saw this as a huge improvement: “Moving away from scattered comments and sticky notes to organized, contextual annotations made our handoff process much smoother. We used to have design files with comment bubbles all over the place, then add Slack—it was a lot to keep track of.” Being able to inspect designs directly in Figma, with all the relevant styles and variables right there, significantly sped up the development process by eliminating a lot of the back-and-forth that used to slow us down.

Even with everything documented, sometimes a chat in real-time can add some much-needed clarity. In these situations, cursor and audio chat was an unsung hero in our process. As a distributed team working on a complex project, we could have impromptu design reviews and quick problem-solving sessions while looking at the same file. It brought a level of spontaneity and immediacy to our remote collaboration that was really valuable.

Developer-approved nomenclature

Once we had our file organized and our global styles (like typography, grid, and UI elements) set up, we focused on making everything responsive. We carefully designed each component for key breakpoints, naming them and ordering them from XS to XXL (a naming nomenclature endorsed by our development partners). By thinking through the layout for each breakpoint, we caught many potential problems and solved them before they came up in the code.

Web Developer Manager Meaza Abate emphasizes the importance of consistent naming conventions: “The nomenclature was actually a big part of our process. We made sure that elements were named consistently across the board—even down to the variables and colors—so that they’re exactly the same in Figma as they are in our code base. Now anytime we use Dev Mode to inspect, we know it’s exactly the way we expect to find it in the code.”

Previously, designers were able to opt out of this naming process, which often left developers to decide on names during implementation. By having the Brand Studio take on the responsibility of naming components, we also added another checkpoint to our process which could reveal whether certain modules were actually repetitive.

Keeping everyone in check with Notion

To streamline the development process further, Program Manager Ricky Ramsaran created a detailed Notion document for ongoing QA edits. This comprehensive database allowed us to assign tasks, prioritize tickets, and track progress, keeping everyone aligned. As the Web Experience team batched component development by group, we were able to then batch our quality check for those components, working in tandem. In this way, we were able to catch patterns we might have missed and apply those learnings to future batches, instead of waiting until everything was complete and then having to go back and make changes across all components.

What we learned

In the end, this project wasn’t just about refreshing a web design system—it was about finding a way to use Figma that felt efficient to us. We learned that there’s no one-size-fits-all approach to evolving a web system. Every team and company has its own rhythms, challenges, and goals, so the best approach is one that adapts to your needs and empowers thoughtful, collaborative work.

This project reminded us of something we’ve always believed: that the best tools are those that fade into the background, letting creativity and collaboration take center stage. We hope that by sharing our process, we can inspire others to push the boundaries of what’s possible with Figma, while finding their own approach to building and evolving their design systems.

Big thanks to my fellow teammates on Brand Studio: Andrea Helmbolt, Andy Luce, Catherine Bui, Damien Correll, Gilles Desmadrille, Kaley Aposporos, Sydney Halle, and Taryn Cowart, as well as our Web Experience team partners: Winter LaMon, Matt McDonald, JP Candelier, Meaza Abate, Ally Sabrowsky, David Wilson, and Ricky Ramsaran.