Tutorials on Design Systems

The best design and development teams imbue design and brand consistency across multiple products with design systems . When designers and developers collaborate on and regularly contribute to a design system, communication between designers and developers improves since a design system serves as a single source of truth for design guidelines, workflows and elements. By having a design system, everyone understands what set of colors, typography, components, etc. defines the brand and unifies the digital experience. A tool for building robust design systems is Figma . Unlike most other tools, Figma allows teams to work together on design systems in real-time. Design systems constantly evolve to meet users' growing expectations and/or adopt the latest UI/UX trends and patterns, so using a tool like Figma helps to organize, maintain and easily locate design elements. Plus, Figma provides an Inspect panel , which gives developers an easy way to extract CSS code from any design element. This close mapping to code makes developer handoff more seamless. Designers can edit styles and assets within the design system, and developers can view those changes immediately and quickly adapt them into the products. Pairing Figma with Storybook speeds up this process. With a single Storybook addon, storybook-addon-designs , a Figma design system (or any design system) gets directly embedded in the addon panel of the Storybook UI. Any updates made to the design system are synced to the Storybook addon, so developers don't have to switch back and forth between Figma and Storybook to implement these updates in code. They no longer need to ask for links to the updated parts of the design system. Below, I'm going to show you how to embed a Figma file in Storybook with the storybook-addon-designs addon. For this tutorial, we will recreate a button component from the Material 3 Design Kit with React and write stories that represent the different UI states this component supports (e.g., disabled). Material 3 Design Kit is a Figma community file for Google's open-source Material design system . Before proceeding further, duplicate this file to your Figma account's Draft folder and open it to ensure you have access to the design system. When you navigate to the "Components" page, you should see the buttons in the Figma canvas. To get started, create a new directory named figma-storybook and initialize it with a package.json file: Install React and React DOM as dependencies: Install Storybook via the Storybook CLI: Note : Storybook automatically has built-in TypeScript support, so any components written in TypeScript should work with Storybook with no additional configuration needed. To style the React component, install two packages of the Emotion library as dependencies: Within the root of this project's directory, create a src directory and move the stories directory to this directory. Then, delete the contents of the stories directory. Since we moved the stories directory, let's inform Storybook of the new location of this directory: ( .storybook/main.js ) Looking at the design system in Figma, the button's CSS styles can be copied from the Inspect panel. Using these CSS styles, let's implement the button as a React component. Within the src directory, create a components directory and add two files: Here, we will define the button types filled , outlined , text , elevated and tonal as button categories to avoid any confusion with HTML <button /> types ( button , submit and reset ). Each category comes with five unique visual states: enabled , hovered , focused , pressed and disabled . We can implement the hovered , focused and pressed states purely with CSS via the pseudo-classes :hover , :focus and :active respectively. enabled serves as the default state, and disabled can be controlled via the <button /> element's disabled attribute. Now, let's write the <Button /> component and its styles: ( src/components/Button.tsx ) ( src/components/Button.styles.tsx ) Note : The ::after pseudo-element emulates the ripple effect that's recognizable from Material Design UIs. When the user clicks or touches the button, the ripple spreads out in a circular motion from the point of interaction, like a ripple in water. The ripple gives visual feedback to the user that the element has been clicked or touched. For Storybook to load the button's font family "Roboto," let's wrap stories with a decorator that adds an Emotion <Global /> component for injecting global styles like CSS resets and font faces. In this case, the <Global /> component will import the "Roboto" font family from Google Fonts and make it available to all components rendered in stories. ( .storybook/preview.js ) Within the src/stories directory, let's create a Button.stories.tsx file: We will write two stories for the <Button /> component, one for the enabled default state and another for the disabled state. The story for the enabled state should render a button that's clickable and touchable. The story for the disabled state should render a button that's grayed out and not interactive. ( src/stories/Button.stories.tsx ) Run Storybook and check that the <Button /> component looks and behaves correctly. If a designer decides to change the color of the button in the design system, then you would have to launch Figma and open the design system in Figma before being able to see what the new color is and copy the new color from the Inspect panel. Let's improve this workflow by having the design system readily accessible in Storybook. To connect stories directly to Figma, install the storybook-addon-designs addon as a dev. dependency: Within the .storybook/main.js file, register the storybook-addon-designs addon. ( .storybook/main.js ) In Figma, right-click on the filled button with the text "Enabled" and copy its link. A link makes navigating large Figma files easier by referencing a specific element within the file. When visiting the link, Figma brings the referenced element to the forefront of the canvas and highlights it. Within the src/stories/Button.stories.tsx file, set a design parameter for the Enabled story via the parameters key, like so: Parameters define a story's metadata and determine which addons to apply to a story. In this case, the design parameter tells Storybook to apply the storybook-addon-designs addon to the Enabled story. The object set to design configures the storybook-addon-designs addon for the Enabled story. ( src/stories/Button.stories.tsx ) type specifies the type of resource (e.g., image for image, iframe for iframe, figma for Figma file, etc.) to embed in the addon panel. url specifies the URL of the resource. For the Enabled story, we specify the type as figma and the url as the link to the filled button with the text "Enabled" in the Figma file to embed a live view of the Figma file (zoomed into this button) in the addon panel. Save the changes and wait for the Storybook UI to reload. The view has a "Figma" label in the top-left corner, and the user can move around and zoom in (and out of) the Figma file. Since you have a different link for each component variant, let's repeat these same steps for the Disabled story. ( src/stories/Button.stories.tsx ) Currently, all you can do within the live view is move around and zoom in (and out of) the Figma file. To be able to inspect design tokens and extract CSS code from the live view, we must embed the Figma file with an enhanced spec viewed called Figspec . The storybook-addon-designs addon supports a figspec type, but it requires providing a Figma access token to Storybook so that the addon can tell the Figma API to render the Figma file using Figspec components. Let's generate a Figma access token by: Copy the Figma access token. Then, create a .env file within the root of the project directory and add an environment variable named STORYBOOK_FIGMA_ACCESS_TOKEN that's set to the copied token. ( .env ) Within the src/stories/Button.stories.tsx file, replace all instances of the figma type with the figspec type, like so: ( src/stories/Button.stories.tsx ) Restart Storybook so that the environment variable is loaded. When you click on the button in the live view, a panel with the button's CSS code appears. Note : You can click either the button's background or the button's text to get either's CSS code. If you change the background color of the button in the Figma file, then that change will automatically be seen in the live view. If you find yourself stuck at any point while working through this tutorial, then feel free to visit the main branch of this GitHub repository here for the code. Try integrating your Figma design systems into your project's Storybook UI. If you want to learn more advanced techniques with Storybook, then check out the Storybook for React Apps course by Yann Braga, a senior software engineer at Chromatic and a maintainer of Storybook:

Hi folks!  The newline Guide to React Component Design Systems with Figmagic (Minibook) is live 🎉 🪄  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. 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. He brings a stunning depth of experience that will quickly transform your own ability to code and architect large-scale systems on the frontend. Find out more on this course here ➡️ :  The newline Guide to React Component Design Systems with Figmagic

In this post, we'll keep it short and sweet and make a sort of "hello world" implementation. This should get you a good sense of how things work when starting from scratch. Let's recap very briefly what we know about design systems, design tokens and Figmagic: Start Figma. Create a new design file by clicking New in the upper right corner and selecting Design file . In the left panel, click Page 1 and rename it to Design tokens . Figmagic picks up on a certain set of given page names, so it's vital that your naming is in line with what Figmagic expects. In that regard, Figmagic does not do any kind of intelligent inferring of data from a document other than matching its processing with named pages. On the blank new page, we need to create a frame. Press F and drag one out. Rename the frame Colors . On the design tokens page, the same principle goes for naming: Figmagic assumes that frames use a set of correct names that specify what type of entity they contain. I recommend having a high degree of hygiene when creating pages for design system usage since, while Figmagic is a tool that does not care about your internal layout, your teammates very surely will if it's all in shambles. Into the frame, add a few rectangles; I'll go with three rectangles. Change the fills of each to a unique color. I'm thinking red, green, and blue to make very distinct colors. Then, rename their layers to their color ( Red , Green , Blue in my case). Note that the names you give the layers will be what these colors are called in the token files that will be produced shortly. In this lesson, we will use our component library codebase , which includes Figmagic. Clone or download it, then install dependencies with npm install , and then finally navigate into it. To successfully run Figmagic, it needs to have a Figma URL (or document/file ID) and a Figma API token. Open up Figma. Click the Figma icon in the upper left corner. Click Help and account > Account settings . Scroll almost all the way down until you see Personal access tokens . Add a token description and press enter/return. You'll be presented a token, which will have a format like 83715-e8346292-bf3v-88s1-n932-j364ge9h687e . Copy it. Keep this token a secret, and don't check this into your code! If you do happen to leak it, just revoke the old one and get a new token. To get the file ID, right-click the heading of the file and click Copy Link , paste the link in a text editor, and copy the bit immediately after the /file/ section. The best way to handle these "secrets" is by placing them into an environment file, which, by convention, is called .env . Create it at the root of the project. Place the ID and token values into the file, like this: Figmagic will pick up that these values are present. No further configuration is technically needed. Now, to run Figmagic, you just do: Please refer to Figmagic's documentation to get a deeper understanding of what the default values are. There's going to be a bit of feedback on-screen. When it's done pulling the data from your document and processing it, you should be seeing a tokens folder at the root of your project. Inspect tokens/colors.ts : TypeScript output is the default for tokens, but we can change this with either configuration or in the actual command. Now try: Vóila—it's a plain old JavaScript file, perfect for our current tooling! You'll perhaps agree that using Figmagic is—if not magic—then at least is not very hard. It will, however, require a structured approach to how we work inside Figma, something we will look at more in my next post. We're working on a new course, The newline Guide to React Component Design Systems with Figmagic, where we go deep into a design-driven workflow giving you all the pieces—from code to know-how—to implement a design system and make it operational for web-based development. If you're looking to improve your whole team's way of working with releasing and designing continuously with a shared basis in a design system, The newline Guide to React Component Design Systems with Figmagic is the course that puts together the entire picture, from theory, to process, to practical setup.

Working effectively with Figmagic means understanding how and what it actually parses from a document. In this post, we will demystify exactly how a Figmagic-compliant Figma file needs to look for it to work as intended. On a high level, there are three page names that Figmagic looks for: These correspond to what type of thing Figmagic should process them as. You can certainly have any number of pages with other names than those within the same document. However, Figmagic itself will only process pages with the names I just listed. You do not need all of those pages—use the ones you need! Let's recap how we correctly outline our design tokens. Rename the current page to Design tokens . Next, create a frame, and into it, create a rectangle. Rename the frame Colors because we will use this frame to contain our colors. Make the rectangle a solid color, and then rename the rectangle into the name of my color. What we have done is create the basic structure required for Figmagic to create design tokens from our color swatches. Colors are a typical first use-case and are easily demonstrable, but there are many more types of tokens we can use. At the time of making this course, they are: The basic idea is the same for all of these, and they follow the pattern we have used a couple of times now for the colors: Go ahead and open up the Figmagic Design System template so that we can look at some other examples. The approach used in Figmagic is to express values as "uni-dimensional," which in common parlance just means that every item (or design token) expresses only a single detail. The effect of this is that we get a very granular design system, but collecting tokens or details together—for example, assembling a more complex design—is something that we have to do in code from the individual tokens. The opposite approach could be something like a text string that has advanced formatting, with a custom font, some particular size, some font variant, some color, some special kerning setting... and then we would need to either use all of those details together, or we somehow still need to disassemble each detail from this set of details. Some of the token types follow a very straightforward format. For example, Radii will pick up on the assigned Corner radius value. Here, we use 0, 4, 8, and 100 (for a full circle). Border widths is the same story. The stroke width is what gets picked up here: 1, 2, 4, or 8 pixels. For the animation-specific ones, it's a bit different. Instead, these directly specify a value as you can see with 0.15s or the cubic bezier functions. Since these values cannot be represented in another way, these are somewhat unique in the overall scope of how Figmagic works. Z indices also follow that pattern. Spacing and Media queries are specified by using rectangles that express the width of the token value. The exact height of these objects does not affect anything. Then for the typography tokens. This is where we need to remember and understand the uni-dimensional tokens. To chisel out our typography, we need to do it methodically. In the template, we can see Font Weights that correspond to all the allowed weights. In this case, you'll perhaps notice that the Font Families are copies, but that's just how it happens to be in this project. Overall, all of the font token frames specify their own respective aspect: weight, family, size, letter spacings... In practice, then, to get them to work together in a useable way, my recommendation is to add a dedicated Fonts frame and create Figma styles from those so that you have a reusable font style as you design within Figma . That frame will not be caught by Figmagic. Jump over to the Graphics page. Notice how Graphics do not need frames. Instead, they need to be packed into Figma components. Other than that, there's not much to say about graphics. You make them with the provided vector tools, bundle them into a component (with CMD + OPT + K ), and then tell Figmagic—through CLI or configuration—that you also want graphics to be handled. More on that later. Last but not least, open the Elements page. To properly generate elements requires close adherence to how Figmagic will parse groups and layers and their names. This complex topic deserves deeper attention, but I'll give you a brief lightning tour right here! The red lines (courtesy of the Redlines plugin ) are not required. I am using them here as a visual aid and developer guidance. An "element" is the Figmagic term for what could be called components. The rationale for calling them elements is that Figmagic elements should correspond closely to HTML elements, thus being relatively basic and not deeply nested. They should thereby also correspond to HTML primitives that already exist, like button and input . You'll see that the elements are divided into two categories: flat and nested. Flat elements, like the Select , have a shallow model: in this case, it only has a Normal state with its text and layout. Nested elements, like the Button , have one additional level of depth, here using the CSS placeholder syntax to enrich the Normal state with a :disabled level. It also uses more variants ( Warning and Error ). These elements are not generated by default, like the graphics were, so they need to be activated in configuration or in the CLI. Generated elements do not strictly, technically, need to correspond to anything that's set up in the tokens. You would, however, get a warning stating that value so-and-so was hard-coded since it could not be inferred from the tokens. In reality, you'd, of course, want to design these elements from the atomic design tokens as far as possible. Figmagic won't be your blocker, though, if you need to go out of bounds for a bit! By now, you should be able to create a Figma document that can be used together with Figmagic. You've also seen all three types of objects you can generate with it and how you need to approach each one of them. Figmagic makes Figma, an already amazing tool, even better for design-oriented development teams. Use it for simple tokens, or operationalize fully across tokens, graphics output and component generation: it's in your hands. We're working on a new course, The newline Guide to React Component Design Systems with Figmagic, where we go deep into a design-driven workflow giving you all the pieces—from code to know-how—to implement a design system and make it operational for web-based development. If you're looking to improve your whole team's way of working with releasing and designing continuously with a shared basis in a design system, The newline Guide to React Component Design Systems with Figmagic is the course that puts together the entire picture, from theory, to process, to practical setup.

One magic, simple concept (design tokens) and a one-stop shop (Figmagic) to contain our design make one hell of a powerhouse. Let's learn what design tokens are and how you can work with a “structured design” approach using Figmagic, a command-line interface tool that extends what we can do with Figma. Figmagic lets us do three things: pull design tokens, extract graphics, and generate React components. In this post, we will discuss the core concept "design tokens". Tokens offer a form of “contract” between a designer’s intent and its fulfillment by developers. This means that both sides agree to treat the individual parts of a complete design through the tokens that represent those values. As a format, they are super easy to read, understand, and adapt for consumption by many types of systems or applications. That’s very important as you start doing cross-platform apps and anything similarly complex. Tokens ensure that values are not magic numbers or ”just picked at random.” This makes communication precise and effortless. Creating actual code for components, even complex ones also becomes a lot less of a bore since what you are doing is just pointing stuff like padding, Z indices, and anything else to their token representations. For instance, we need to add margins to a box. Let's see what we have available: Given the above, the small spacing is the single spacing you can use for your margins, paddings, or other sizes. For sure, you sometimes need to hardcode new unique values, but that should happen in a very small number of instances. I call this approach "structured design"—no need to make it a big concept—but it's an approach in which we leave as little as possible to chance. As far as possible, we use the tokens instead of hard-coding any values. With a single spacing it does, however, seem reasonable to believe that it's time to add some more to cater to more dynamic, realistic needs, so let's evolve the model a tiny bit: We now have two possibilities, and both are perfectly valid choices. The evolution process should be done in collaboration between the designers and developers. So, where do these tokens come from? The token has to be communicated and stored somewhere and then exported to a useful format—like our example JSON file. The exported token files themselves do not, therefore, usually constitute "the truth" as such but act only as a kind of transport artifact for the truth: Figma. The implication of this is that they only fill the role of moving a value from one system (Figma) to a variety of others (anything that accepts JSON, for example). The designer, in turn, needs to ensure correspondence between Figma styles and design tokens on their end. The rest of the tooling just happens to be things I feel are very good and happen to work well together. It's really smart to work in a structured way by assembling design systems from design tokens. Using tokens, we can shape simple elements, which can then be ordered into components and then into compositions and views from those. Design tokens fairly directly tend to create a form of taxonomy of what things exist and in which relations. So, your color "green" will be a very flat and direct way of saying what they are, but it won't say anything about where they are used. That information can be handled in other ways—though you can also use aliases to set a value like "orange" to an auxiliary value like "color-accent," thus naming by purpose : What makes sense for you to use is often use case-dependent. This can also, given the right tooling, provide the side effect of making updates to token values magically update the actual code. Bigger updates, like changing from a token X to token Y , will still require a code change, but the effort is practically negligible. By their nature, design tokens enforce the standards you have set up. Some advice for the road, as you start using design tokens in actual projects: Using design tokens as a part of your workflow will most likely make it easier to communicate the design, faster to work with coding a design, and less susceptible to breaking between UI expectations and how the design is actually coded. We're working on a new course, The newline Guide to React Component Design Systems with Figmagic, where we go deep into a design-driven workflow giving you all the pieces—from code to know-how—to implement a design system and make it operational for web-based development. If you're looking to improve your whole team's way of working with releasing and designing continuously with a shared basis in a design system, The newline Guide to React Component Design Systems with Figmagic is the course that puts together the entire picture, from theory, to process, to practical setup.