Sources of truth, it isn't Figma

I have created a far more flexible workflow over the last 18 months of running my design engineering practice. I no longer need a massive Figma file to solve a design problem. This article from Design Systems International landed in my inbox the other day, and it perfectly sums up my feelings towards designing products and design tools.

A key question is whether it makes sense to keep a duplicated set of components in both code and design tool. There is no single answer to this as it depends on the size of the organization and the maturity of the components, but we always start from the understanding that the source of truth is in the code, and the Figma components are a utility for the creative process. We generally don’t recommend duplication of efforts in the early stages of this new collaboration workflow as it is often faster to update the Figma components to match the code when needed rather than trying to keep everything in sync at all times.

My current workflow now boils down to expressing creative direction in Figma through comps, mood boards and a few screens to determine what type of typography scales, spacing and a range of colour palettes.

After that, I move into code, setting up my tokens and a few core components to help with text and spacing.

This approach is better for solving complex state, aka a checkout. Design files in these scenarios are unsuitable for working out complex state management. Maybe for v1, but it becomes difficult to update as soon as you iterate, and nuances are lost or impossible to follow how the user got there.

With a mix of state charts to explain requirements and vision-based AI, designers won't be constrained by their coding abilities, and we can deliver better products to our users.