Maximize Parity Between Designed and Developed Components
Making sure that designed and developed components function as similarly as possible requires some additional up-front work and a commitment to cross-functional collaborative problem solving, but the potential improvements in design and developer experience can transform the ways that teams work — easing communication during design and development handoff at every level (within system and product teams), reducing churn in the design and development process, and improving time-to-market for new features.
One Design System Multiple Contexts
The goal of a design system is to be a source of truth for functional, reusable, and extensible components that can be used to create products quickly and efficiently. There are many benefits to this way of working, but there are also plenty of challenges. Including that the “single” source of truth — the design system — is often split between a design context (Figma) and one or more engineering contexts. Keeping design and engineering sources of truth aligned takes careful coordination on the part of system maintainers and is made more difficult when designers and engineers have limited visibility into each other’s workflows.
Setting the requirement for maximizing parity between designed and engineered components solves this visibility problem by requiring tight communication and collaboration between design and engineering. For a designed component to match an engineered component on a functional level the designer has to have insight into how a component is engineered, and an engineer has to have insight into how a component functions in design.
The incorporation of auto layout, properties, variants, and variables into design tooling has enabled design systems to leverage the core programming concepts of functionality, reusability, and extensibility into their approach to component creation and structure. To supercharge the value of design systems we need to push for fine-grained parity between designed components and their engineered counterparts wherever possible. When designers and engineers are using components whose usage behavior matches, their ability to communicate about intended functionality becomes significantly easier.
What Do You Call That Again?
Aligning design and engineering design system libraries starts with language - shared language is key to effective team communication about components.
Common Approach to Names and Organization
A design system new or established should have a standardized naming convention that is agreed upon by the team. It doesn’t have to be perfect, but it does need to be used by everyone. All teams committing to following the same approach majorly reduces confusion and friction in collaboration. Engineers automatically know where to find component specifications inside of a Figma file, and designers automatically know where to locate a component inside of Storybook. Easing day-to-day collaboration and feedback cycles pays massive dividends in time saved and practitioner morale over the lifecycle of a product.
Matching Properties
Creating matching properties in designed and engineered components requires an ongoing commitment on the part of designers and engineers. It also requires flexibility — finding a common solution may require adjusting default approaches — the efficiencies provided to downstream system users increases along with system usage.
Ideally, every property for a component would match across contexts, but there will always be places where properties have to be named slightly differently due to how those contexts function. For example, Figma does not currently allow for showing/hiding additional layers when a text property is empty - a common code pattern. The goal is to match core property names and purposes while making system users aware of differences via documentation.
Matching Component Structure
Beyond component names and properties, it is important that designed and engineered components share a common architecture — matching layers and nested components in Figma with elements and nested components in the engineering context. Mirroring the layers in Figma with the corresponding elements in the developed component makes it easy for engineers to navigate the component in designs, and models for designers using how the developed version is structured.
Efficiencies From Mirroring Component Function
The purpose of matching component naming, properties, and structure between contexts is to end up with components that function in the same, or very similar, ways in both contexts. Accounting for differences in tooling and working methods may mean some differences are required, but the intention is to match the component options for both designers and developers. Options for modifying a component affects how it is used. Offering designers and developers the same usage options for components makes their collaboration process simpler because everyone is using the same building blocks.
Having designed components whose functionality mirrors those of the developed components also pushes designers to use the components in similar ways to how they are used in applications. Ideally, this makes it harder for designers to use a component in a way that is unable to be built using existing components, reducing churn in designed feature proposals and streamlining time-to-market.
Working this way may seem overburdening to some designers and engineers, but drawing design and development processes closer together will benefit both designers and engineers in the long run by improving collaboration, simplifying documentation and onboarding, and making it faster to ship great software.
