Communicating the importance of Design Systems
In late 2024 I joined Figma as their first Product Enablement Manager. As Figmas offerings became more sophisticated, it became necessary for Sales reps to have a stronger understanding of the Product Development landscape. I came in to create programs, resources and plans for shrinking this gap.
Overview
Being a relatively newer focus, Design Systems have advanced quickly over the last few years. As a leader in the space, Figma has needed to quickly adjust their offerings to fill the gaps needed by product teams that were investing more and more into Design Systems. Figma moving further into this realm transformed itself from a predominantly product design focused tool to one with much more technical focus. Design Tokens, Code Connect, MCP Tooling and more were being developed to further connect product design output with their counterparts in engineering.
By moving into this territory, Figma was no longer selling itself as a purely Product Design focused product. Customers were now more design system and engineering focused than ever before. Because of this, Figma began looking for ways to improve their sales teams' understanding of these new customers and the world they work in.
In late 2024, I was hired by Figma as their first product Enablement Manager. The position's focus was to help non-product focused Figma employees understand this new environment the product was moving into. Understanding the details, history and application of Product Development would ensure they could engage in deeper conversations with these new users.
Quick Wins
Figma moved fast and was looking for some immediate enablement for their Sales teams while we developed a more robust program for the future. Fortunately, I had materials ready to roll out from my previous position. During my time at Paramount, I ran a program called Figma Academy that taught the users of our Design System how to implement new Figma features as well as learning about updates to the system. These sessions were highly relevant (or easily modifiable to be) to the sales folks at Figma as many of them lacked hands-on experience with the tool.
We began by running weekly sessions that dove into topics both hands-on in the tool or relevant to the landscape of Design Systems. Interactive sessions included things like understanding auto-layout, the power of components, design token management and more. Then we’d follow-up with a session on how those previous topics translate over to code and why their alignment was so important.
Many of the participants in this program said that this helped build their confidence with customers when discussing the product. While they weren’t out there building UI for customers, being able to share some sort of common ground relieved some pressure during conversation. Confidence is key!
Long Term
While our short-term programs ran, we began planning the future of product enablement at Figma.
We broke down the enablement program into 3 spaces:
Knowledge Base
Live Training
New Hire Training
Knowledge Base
We wanted a centralized repository for all learnings we created as well as other materials like competitive battle cards, user personas, talk tracks, feature one-pagers and more. These were similar to what we had available from our Sales Enablement team but with more focus on technical talking points.
Live Training
The meat and potatoes of Product Enablement became our Live Training sessions named the Advanced Practitioner Program. This was a live enablement training program that brought Figma employees together to learn about three major pillars of Product Development: Product Design, Engineering/Development and Design Systems
The Product Design portion was designed to provide crucial context into the space that Figma was brought to life in. What kind of problems do Product Designers solve? What tools have they used and why? What has changed about their work in the last 10 years?
Engineering and Development focused on giving a general overview of how web applications function both on the front and backend to help differentiate where we sit in the process. We explored topics like programming languages vs frameworks, frontend vs backend code, how engineers historically interact with Product Design and more. Again, this section provided important context for employees to interact with new technical customers.
Lastly, we joined our first two topics together with Design Systems. We looked at early visual design languages and why they were created. Why a unified interface had become so important and the bridges we needed to gap in order to do so. We gave a look into the power of things like Design Tokens, Connected Components, Dev Mode and more. With the learnings from our previous sessions, we could better show how Design Systems were allowing for a more unified development process.
These sessions happened over the course of three days and occurred once every quarter. We also provided recordings and slide decks used as materials available for all.
New Hire Training
For new hire training, we saved some time and resources by adjusting our advanced practitioner program to take place over 2 days of in-person training. Diving into less technical detail and explaining more of the history that supports why the problems we solve are important. We also opened up a lot of time for hands-on usage of Figma for new-hires to understand the basics of using our tool. These trainings took place once per quarter in the San Francisco Figma Office.
Results
After the implementation of our new Product Enablement programs, we learned from sales employees that their confidence had risen when speaking with technical customers. They felt that the ability to speak a bit closer to customers environments and issues helped speed up deals and build better relationships. We also tracked some KPI’s to measure this success.
Win rate on design system accounts: 31% → 44%
Average deal size on technical accounts: up 18%
SE escalation requests from trained reps: down 28%
All in all, we measured the program to be a success!
© 2026 A. Still