Bento Design System
Closing the gap between design and engineering
A design system doesn’t stop at the design file. Its value depends on how clearly design decisions translate into implementation. As Bento matured, the focus expanded from creating reusable components to improving the workflow around them — giving designers and engineers a clearer shared reference through documentation, Figma’s developer tooling, and closer collaboration.
Design and code could still drift apart
A shared component library gave designers a consistent starting point, but implementation introduced another layer of interpretation.
Specifications, tokens and component behaviour needed to move clearly from design into development. When that information lived across different files, documentation or conversations, engineers still had to translate design decisions before they could implement them.
The next challenge for Bento was therefore not creating more components. It was creating a clearer shared reference between design and engineering.

Bringing design and implementation closer together
As Figma’s developer tooling evolved, we used it to make Bento easier to inspect and implement directly from the source.
Component properties, spacing, styles and variables could be surfaced alongside the design itself, giving engineers more context without relying on separate handoff files or manually written specifications.
This created a more direct connection between the decisions made in the system and the information needed to build them.

Making decisions easier to understand
Components alone couldn’t explain every decision behind the system. Teams also needed guidance for how and when patterns should be used.
We documented component behaviour, states, accessibility and usage alongside the components themselves, keeping the guidance close to the work rather than treating documentation as a separate deliverable.
This gave designers and engineers a shared understanding of both what a component was and how it was intended to behave.

Creating a shared language around the system
Better tooling made the specifications easier to access, but the system still depended on collaboration between the people designing and building it.
Bento gave designers and engineers a shared place to discuss component behaviour, implementation details and changes. Instead of treating handoff as the end of the design process, the system became a reference point for conversations throughout the work.
This helped move the relationship from design handing work to engineering toward design and engineering working around the same system.

Keeping Bento useful as products changed
A design system isn’t finished when its components are published. New product requirements, implementation constraints and feedback from teams continued to reveal where the system needed to evolve.
Instead of treating those moments as exceptions, they became inputs back into Bento — refining existing components, clarifying guidance and extending the system when a reusable solution was needed.
This created a feedback loop between the system and the products using it, helping Bento evolve alongside the teams it supported.

A system teams could build from together
Bento became more than a shared component library. It created a common reference across design and engineering — connecting component decisions, documentation and implementation more closely.
The result was a system that was easier to understand, easier to work from, and able to evolve through the teams using it.
For me, that was the larger shift: design system work wasn’t only about maintaining UI consistency. It was about creating the shared infrastructure that helped teams build together.