Reducing the Gap Between Design and Code in a Design System

The 8percent web frontend team, while implementing the in-house design system EDS (Eight Design System), found that the gap between EDS Figma and EDS Code (eds-wc) created repeated communication costs and fatigue.

The problem stood out at two stages.

• At the design system development stage, it's hard for designers to perfectly predict all component properties from the start, so developers end up repeatedly requesting revisions after reviewing the spec.
• At the service development stage, developers have to interpret the Service Figma created by service designers, and if Figma and code are already misaligned from the previous stage, the time spent checking specs increases significantly.

In particular, Figma lacks clear property naming rules and guidelines, so properties with the same meaning can be defined differently across teams. For example, if state combinations like disabled and checked, the value system for size, and icon-related property definitions are inconsistent, developers have no choice but to re-check, and arbitrary modifications eventually occur, widening the gap between EDS Figma and EDS Code.

To reduce this, three improvements were applied.

• When writing specs for new components, designers and developers discuss the interface together.
• An EDS Figma convention was added so developers can get the information needed for code implementation just by looking at Figma.
• The Figma Plugin API abstracts Figma down to the code level, providing implementable data without needing to re-check the spec.

The core of the convention is standardizing the structure of ComponentSetNode and InstanceNode enough to extract implementation data from them. Component functions must be distinguished by name or property, component names must be identifiable, and property values representing the same function must be unified across the whole team. For example, size must use the same value system across all components, and state values like disabled must also be defined consistently.

Based on these standards, two tools were built.

• EDS Lint: A Figma plugin that checks whether a ComponentSetNode was built according to the convention. It gives real-time notifications for missing required properties, use of undefined properties, and use of incorrect values.
• EDS Codegen: Converts a ComponentSet Instance in Figma into HTML, React, and Vue code supported by eds-wc. Developers can get code directly from Figma without separately checking the spec.

Ultimately, the key point is not to treat a design system as simply "making things look pretty," but to make design and development use the same interface language. When Figma conventions are combined with plugin-based automation, it reduces unnecessary back-and-forth between the design system and service development, raising productivity across the whole team.