Design Systems Are Borrowing from Engineering
At Figma's first-ever design systems conference, Schema 2022, product manager Jacob Miller laid out a case for how modern design work is increasingly mirroring software engineering practices. The core tension he describes is familiar to anyone building complex products: design needs both freeform exploration and structured systems, but adding structure to manage scale often comes at the cost of creative flexibility.
That complexity is a relatively new problem. Design used to be a local activity—files lived on your machine, coordination was minimal, and the occasional final_final_final2.png was the worst of your organizational headaches. Today, design spans large, distributed teams working across interconnected files and systems. Keeping everything coherent and high quality at scale while letting many contributors participate requires better solutions.
Miller argues that the design community is finding those solutions by borrowing from code. A handful of engineering-inspired practices are emerging as responses to specific pain points in design system management.
Composition Over Fan-Out for Flexible Layouts
Simple design systems often start with components that have a single layout. When you need multiple layouts, say a card that appears in horizontal and vertical orientations, you might initially create a couple of variants. That approach breaks down as the number of layouts multiplies. Component properties can help for simple optionality—like whether a card shows an image or a pull quote—but they are not suited for cases where entire orientations and element arrangements differ. You end up authoring and maintaining many near-duplicate components by hand.
The emerging answer is composition. Designers are creating smaller sub-components and nesting them inside larger, layout-specific components. Those nested pieces can combine and recombine in many configurations, yielding layouts that original system designers might never have envisioned. This brings the flexibility of modular code to visual design, without the cost of maintaining every possible permutation as a distinct top-level component.
Separating Structure from Presentation
A start-up design system typically bakes a single color into a component. Then someone asks for dark mode. Then sub-products and sub-brands appear, each needing their own theme. Managing a component that has three, four, or even five themes is technically possible but organizationally heavy.
The next step is the "headless" design system, a term Miller credits to Esther Cheran, co-creator of the Figma Tokens plugin. Instead of containing a set of themed visuals, a main component is built with no style at all—just a defined structure of invisible layers. Themes are then applied to those blank sub-layers. By separating the layer hierarchy from the look and feel—decoupling structure from presentation, as front-end developers would recognize—the component becomes infinitely adaptable. Different brands and products can all use the same core component while appearing entirely distinct.
The payoff is maintenance. A change to the layout of one headless component can roll out across all variations and brands automatically. Product teams can manage their own visual changes while still relying on a central, shared structural core.
Applying Tests and Branching to Design Workflows
As teams grow, ad hoc coordination stops working. It becomes hard to know what others are doing, and nearly impossible to avoid collisions on shared files. Once again, design is looking at software engineering for a remedy.
Test-driven design is modeled on test-driven development (TDD), where requirements are turned into test cases before full development begins. In a design context, this translates to using quick, automated checks to detect whether a change will break existing structure, catching issues before they reach the final product. Figma itself uses a form of this internally: visual regression tests place a detached version of a component next to its live version, using a blend mode to highlight any differences between them.
Branching and merging is another control being adopted for shared files. Working on a branch lets designers make their contributions without impacting others, with a review process ensuring changes are production-ready and conflict-free before merging them into a central file. This handles the organizational complexity of large teams while protecting the integrity of important, central design files.
The System Should Serve Creativity
Sub-components, headless architecture, test-driven design, and branching are all ways to contain complexity in increasingly large design efforts. But Miller is careful to point out that these processes are not an end in themselves. Teams should treat their design systems like products and listen to their users. If a system feels too constrained for individual contributors, it needs loosening.
He contrasts two views of design systems. Older arguments framed them as a way to reduce inconsistency and enforce brand alignment—a perspective stemming, in his view, from a lack of trust in designers. The more current rationale holds that systems exist to streamline repetitive work and free up people to focus on creative problem-solving. Judged by that standard, a design system that adds friction has failed in its mission.
The goal is stated plainly: design systems should lower the barrier for creative expression, not raise it.
