A "welcome" is in order, and let's also set some expectations while we are at it!

An Introduction to Figma, Figmagic, and Design Systems

I hope you are excited! We'll be using some very nice tools and some skeletons I've pre-provided to fast-track our way to a design system!

The course project

Introduction

Let's take care of the essentials first, like setting up a development environment, Git and Node.

Prerequisites

Figma reshaped how millions of people and companies follow the design process. Now, we're going to form our process around it.

An Intro to Figma: Shortcuts, Frames, and Components

Get a spot in the world's biggest (probably!?) JavaScript community—NPM.

How to Set up NPM to Publish JavaScript Packages

Get hooked up with the premier place on the planet to share, build, and discuss code—open source or otherwise.

Setting up GitHub

Next stop is hosting, where we'll use Cloudflare Pages, one of the most exciting tech services around.

Setting up Cloudflare

Last but not least, we need to get our visual inspection platform and Storybook hosting working. For this, we will turn to Chromatic.

Setting up Chromatic

Preparation

Let me introduce you to my take on the concept of "continuous design."

An Intro to Continuous Design: DevOps for Design

Time to set the stage and see what we can do to be a top shop using continuous design principles and tooling.

Build a Continuous Design Workflow With a Design System

A diagram can be the difference between an organization of "petty kings" doing their own thing and having actionable plans built on a shared identity. What we need is some kind of governance.

Build Better Design and Change Governance With Flows

One magic, simple concept (design token) and a one-stop shop to contain our design equal one hell of a powerhouse.

Intro to Design Tokens: How to Communicate in Design Work

Going from static files, private work, and image-based output to a collaborative, real-time component-oriented tool changes everything about the design workflow.

Why Figma? The Pros of Collaborative Design

Figmagic is the last piece in our toolchain that acts as the glue needed to super-charge your productivity.

An Intro to Figmagic, the Figma CLI For Token Design

Enabling 'Continuous Design'

It's high time to get to know the Figma API, one of the real stars of our show.

How to Use the Figma API and Read Figma Documents

Time to get knee-deep in coding, which we will kick-start by using a bit of boilerplate that we're going to scaffold.

How to Scaffold a React Codebase With Degit

It's vital we have a solid grounding for our component workflow if we are to build an entire library of them. In this lesson, we will set up a smooth, component-driven development workflow from code to Storybook.

Build a Component Development Workflow With Storybook

That song with the "I like to move it-move it" lyrics must have been about pushing code to production...right?

Automatically Deploy React Code to GitHub and Cloudflare

While dogfooding does sound yucky, it's a word that connotes the practice of using one's own things, sometimes to build something new. That's what we will do now with the components we've built.

How to Publish a React Component Library to NPM

Putting in the last fixes for our tooling means getting our Continuous Integration operational.

Finishing the CI Setup

Setting up a pipeline for design and code

With all the other hard, boxy stuff behind us, the perspective now moves to the front-end components and Figma.

How to Set up Figmagic to Interact With Figma via CLI

Working effectively with Figmagic means understanding how and what it actually parses from a document.

How Figma Files Are Organized in Figmagic

Getting to know the configuration options is super important if you want to make the best use of Figmagic.

An Intro to Figmagic Command Line Configuration

Getting to know Figmagic

Let's find our way by analyzing our UX sketches before digging into the details and building anything.

UX Sketching and Double Diamonds: Build Atomic Design

Let's move on from basics to the intermediate level and actually make some designs.

How to Create Design Tokens and Styles in Figma

Let's put the Figma-first approach to the test by taking the step to turn a design into code.

How to Break up Designs Into Small, Atomic Components

Starting our design system

And now for some bells and whistles—graphics and icons!

How to Build Icons in Figma and Export Them With Figmagic

Galloping ever onwards, we'll wave our magic wand and summon our low-complexity components.

Flat vs Nested Elements in Figma and Figmagic

Now, we leave the easy flat components for the more detailed nested ones!

How to Create Nested Figma Elements in Figmagic

Code generation with Figmagic 4 will only take you so far. For our most important and complicated components, we will need to do some manual work, composing small bits into more advanced ones. Let's compose one from what we've made so far!

How to Compose Complex Components With Figmagic

Extra credit time—adding the components for the checkout view.

Finishing the Checkout Components (optional)

Building elements and components

Good documentation is vital and shows that you care about your design system and those who will use it. Lacking good documentation practices could spell doom for a design system.

How to Author Quality Design Documentation

The very first documentation step we will take is to describe what we have built so far.

Add Storybook Descriptions For Self-Documenting Designs

Storybook is a brilliant tool for documentation, and we'll make good use of it in several ways.

How to Structure Storybook for Documentation

Documentation and Storybook

We have talked about "continuity" a lot, so it's about time we address how to deal with change in practice.

How to Plan for Design and Component Life Cycles

Things need to be in order before we continue.

Export Components With GitHub Chromatic Actions

Time to fill up our UI platform with our work to date!

A Beginner's Guide to Using Chromatic With Storybook

Communicating and giving feedback on our work is the lifeblood of a design system.

Building a Feedback Loop For Your Design System

Let's automate the release of new components.

Publish New Design Components With GitHub Actions

Time to place the final cherry on the top. Cue up "I've got the power"!

How to Trigger GitHub Actions From a Figma Plugin

The design life cycle

Summary and thank you

Among developers and architects, "continuous integration and delivery/deployment" (CI/CD for short) has increasingly become the norm for almost two decades. And while frontend development has gone through the framework revolution, going from design to code with the speed expected of CI/CD is still a pain. But it doesn't need to be!

This 10-module course is taught by Mikael Vesavuori, an architect and developer who has helped companies like Polestar redefine their technology and design processes, tooling and ways of working.

In the course, we will create a full component-based React-driven application with Figmagic, underpinned by Storybook, good documentation, and with CI and automated testing.

We will bring the dev-designer collaboration to its current state-of-the-art with a DevOps-inspired life cycle, which could be called “continuous design” (after continuous integration/deployment or CI/CD).

While there is a pre-defined, specific toolset that we’ll use, the end goal of the course is to teach you a wider perspective of what it means to work end-to-end with design systems. Nearly all individual tools are exchangeable: we’re more interested in the capabilities enabling our desired way-of-working than the specific tools chosen to get there.

This course is a comprehensive guide to building a React component library based on a well-architectured design system. You’ll create a full component-based React-driven application with Figmagic, underpinned by Storybook, good documentation, and with CI and automated testing. Learn senior-level system architecture skills for frontend React code; skills you can apply broadly in working on any frontend application.

The newline Guide to React Component Design Systems with Figmagic

How to set up a continuous design pipeline from code to CI/CD, using some of the best services out there

What Figma, Figmagic, and design tokens are and how they enable you to be more productive

How design tokens can function as a contract between designers and developers, setting up powerful new ways of working

The history of design/code tooling and how to argue for process and tooling change

Understand the value of documentation, using Storybook and Figma to document your work

First be structured and systemic, then set the system itself

Design is a messy, often intuitive process. It often has to go through multiple phases until we've closed the circle from idea or intuition (or user need) to something that resembles a complete realization. Design is highly qualitative, iterative, and usually bears no direct relation to efficiency as we typically think about it.

On the other end of the spectrum, we need overall guidance: something that informs us about guardrails, direction, vision, and any "hard lines" we need to know about. Such a process requires certain rigor, standards, and efficiency.

Example of a design system: IBM Design Language.

The entity that attempts to bridge these two different notions into a union is the "design system." The design system concept is malleable, as there are only loose conventions around what they are in practice. Typically a design system is a shared, centralized location that acts as a single source of truth, which is to say it acts as the authority on design questions. As a static but living artifact, it delegates knowledge into a fixed format instead of leaving 

 decision and bit of knowledge with people. From a practical perspective, it also provides the latest design elements (UI assets, graphics, static assets kits) and all the direction needed to inform designers and design users (could be developers) how it's meant to be realized into new artifacts, like a product.

What a design system does is, in a sense, nothing that any organization has not already done for centuries: it creates structure and order and replaces a great deal of implicit or tacit knowledge with express directions and guidance. Ideally, the creation of new design artifacts, like components, is eased by these directions, and designers can spend more time innovating in new areas rather than reinvent the wheel on the "known knowns."

Ultimately, a design system creates a foundation for shared understanding. In the next lesson, we'll look more specifically at "design tokens," the concept we use to atomically describe our design system.

Given that digital design is, by necessity, coupled with software development, the struggle to contain any unmotivated half-baked new components and non-normalized variants 

 lead to increased implementation and maintenance cost (or technical debt).

Example: Component in IBM Design Language.

To be frank, any designed items are most likely expected to be coded at some point, so even a design-to-be is a future cost. If you reproduce a lot of similar components and are unable to make unique items that are clearly distinguishable by presentation and logic, then it's going to be hard to have a neat and ordered component selection/bank.

Setting up some basic house rules around what is a motivated and unique new component—or another type of item—will keep the sum total of the design system assets under control.

What are the fundamental parts of a design system?

If you Google for longer than ten seconds, you'll get an overload of maps, charts, diagrams, and theories about what the crucial elements of a design system are. In general, you will find something along these lines:

" of design systems, meaning that graphic designers often drool over the new hotness coming out of a startup (

there's just so many design systems these days

), the real use of design systems is most likely going to be internal. And that's a good thing!

Some misconceptions that can also be quickly addressed are:

---
title: Build a Continuous Design Workflow With a Design System
description: Time to set the stage and see what we can do to be a top shop using continuous design principles and tooling.
#privateVideoUrl: https://fullstack.wistia.com/media/xxxxx
isPublicLesson: false
useMdx: true
---

## What you will learn in this lesson

-   Learn what role a design system fills
-   Understand why design can become hard at scale
-   Get to know the trade-offs of a design system, but also how it can benefit you for years
-   Learn what requirements a continuous design toolchain needs to fulfill
-   Get to know the rationale behind the toolchain we will use throughout the course

## First be structured and systemic, then set the system itself

Design is a messy, often intuitive process. It often has to go through multiple phases until we've closed the circle from idea or intuition (or user need) to something that resembles a complete realization. Design is highly qualitative, iterative, and usually bears no direct relation to efficiency as we typically think about it.

On the other end of the spectrum, we need overall guidance: something that informs us about guardrails, direction, vision, and any "hard lines" we need to know about. Such a process requires certain rigor, standards, and efficiency.

![Example of a design system: IBM Design Language](https://d2uusema5elisf.cloudfront.net/courses/newline-guide-to-react-component-design-systems-with-figmagic/module_03/lesson_03.02/public/assets/ibm-design-system.png)

_Example of a design system: IBM Design Language._

The entity that attempts to bridge these two different notions into a union is the "design system." The design system concept is malleable, as there are only loose conventions around what they are in practice. Typically a design system is a shared, centralized location that acts as a single source of truth, which is to say it acts as the authority on design questions. As a static but living artifact, it delegates knowledge into a fixed format instead of leaving _every_ decision and bit of knowledge with people. From a practical perspective, it also provides the latest design elements (UI assets, graphics, static assets kits) and all the direction needed to inform designers and design users (could be developers) how it's meant to be realized into new artifacts, like a product.

What a design system does is, in a sense, nothing that any organization has not already done for centuries: it creates structure and order and replaces a great deal of implicit or tacit knowledge with express directions and guidance. Ideally, the creation of new design artifacts, like components, is eased by these directions, and designers can spend more time innovating in new areas rather than reinvent the wheel on the "known knowns."

Ultimately, a design system creates a foundation for shared understanding. In the next lesson, we'll look more specifically at "design tokens," the concept we use to atomically describe our design system.

### The relation between design and code

Given that digital design is, by necessity, coupled with software development, the struggle to contain any unmotivated half-baked new components and non-normalized variants _will_ lead to increased implementation and maintenance cost (or technical debt).

![Example: Component in IBM Design Language](https://d2uusema5elisf.cloudfront.net/courses/newline-guide-to-react-component-design-systems-with-figmagic/module_03/lesson_03.02/public/assets/ibm-component.png)

_Example: Component in IBM Design Language._

To be frank, any designed items are most likely expected to be coded at some point, so even a design-to-be is a future cost. If you reproduce a lot of similar components and are unable to make unique items that are clearly distinguishable by presentation and logic, then it's going to be hard to have a neat and ordered component selection/bank.

Setting up some basic house rules around what is a motivated and unique new component—or another type of item—will keep the sum total of the design system assets under control.

## What are the fundamental parts of a design system?

![Design systems](https://d2uusema5elisf.cloudfront.net/courses/newline-guide-to-react-component-design-systems-with-figmagic/module_03/lesson_03.02/public/assets/design-system-scope.png)

If you Google for longer than ten seconds, you'll get an overload of maps, charts, diagrams, and theories about what the crucial elements of a design system are. In general, you will find something along these lines:

-   **Design elements**: A collection of design elements that could be anything from a few basic UI components to vast multimodal systems with a design language, set of style guides, detailed typography, tone of voice descriptions...
-   **Access**: A way for all stakeholders to access design, ideally in all phases from WIP to in-production.
-   **Documentation**: Well-rounded documentation capabilities, from the overarching and "free-form" to the nitty-gritty details of very specific parts.
-   **Implementation**: The possibility to display how components should be implemented in code either by simple documentation or with rich, interactive examples.
-   **Governance**: A known, explicit, useful, and directed governance model of who decides, owns, and operates the respective parts of the design system, ideally with a platform-agnostic approach.
-   **Work process**: A work process that enables all team members to work and hand over their work with minimal friction and pain.

While there has been a "[dribbblization](https://dribbble.com)" of design systems, meaning that graphic designers often drool over the new hotness coming out of a startup ([there's just so many design systems these days](https://designsystemsrepo.com)), the real use of design systems is most likely going to be internal. And that's a good thing!