Design Systems

2
DA
Last updated last month

Motivation

A design system is intended to allow scalability and enforce consistency across a design team. However, there is often a big disconnect between the components the design team is using (static pictures), and the components being used in production (code). It's not uncommon that teams have multiple people dedicating countless hours per week to keeping these two disparate libraries consistent, and even then there are often issues. At this point, the maintenance cost can potentially outweigh efficiency gains.

This is why Framer X uses both visual components and interactive code components. You can start with visual components, getting your team aligned visually, and then work towards a unified source of truth using code components, right within the one tool. This not only allows the design and engineering teams to stay in sync, but designers, or really anyone at your company, are able to easily compile highly interactive interfaces using real production components.

Planning

If you're new to design systems, we have an entire section on our website dedicated to helping you learn about them. We also have a post specifically about how we think about design systems in Framer X.

The key building blocks for Design Systems in Framer X are components, so we have articles outlining them as well.

If you're just starting out and want to get designers aligned visually, creating Design Components for some basic building blocks for interface composition like buttons, input fields, or anything that's repetitive is a fantastic place to start. If you've got a few technically minded designers or a few engineers on your team who really want to unify the design and engineering workflow, Code Components and connecting them to production code is the way to go. Each company is different, so there's no exact playbook, but Framer X offers plenty of ways to start to see value immediately.

Workflow

A typical workflow starts with the designer creating a mockup. An engineer will then extract components from the mockup, and bring them to life with code (see Handoff). Static visual components become production code components.

For a single component, like a button, you end up with two sources of truth. The designer has a static mockup, the engineer has the interactive component that is used in production. Visual changes made by the designer won’t affect the component used in production, and vice versa. Framer X solves this disconnect by allowing the engineer to bring said production component back into Framer X and replace the visual mockup with the real code component. Both the designer and engineer are now using the same code component. The engineer can even surface property controls for others to allow customization, or to visualize multiple states of a single component.

The end result is a fully interactive component that can be used within Framer X. It can be manipulated, nested and customized like any other object on a design canvas. It includes all possible states, giving the designer context of all potential edge cases, and it allows the designer to validate components in a familiar context, which may lead to visual changes, bridging the gap between design and engineering.