Bring style context from a Figma Design library to Make kits (original) (raw)

Before you Start

Who can use this feature

Figma Make is available for Full seats on paid plans.

This feature requires a Full seat with edit access to the library's source file

To create functional prototypes and web apps in Figma Make that look and feel consistent, you can bring style context from an existing Figma library into Make kits. When you do this, Figma Make extracts CSS styles from the library and delivers them in a styles.css file inside your Make kit. To use a library in a Make kit, it must be published.

This article describes specifically how to bring style context from a library via Figma Design. However, the easiest way is to include the library directly when you're assembling the kit.

Bring library styles to a Make kit

To bring style context from a library in Figma Design to a Make kit:

1. In Figma Design, go to the library you want to use in a Make kit.
2. If you haven't yet, publish the library.
3. Click :down arrow: next to the file name, and then Use library in Make.

When you select Use library in Make, Figma Make opens and your library is added to a new Make kit. Then, follow the steps in Get started with Make kits to finish assembling your Make kit.

Guidelines for library styles

When your library styles are added to a Make kit, an empty Guidelines.md file is also added. Guidelines are critically important for ensuring Figma Make uses your library styles in a way that creates high quality, reliable results.

Best practices for guidelines

We recommend the following best practices when you’re writing the guidelines for your library styles.

Explain the quirks of your tokens before anything else

Some use unitless numbers that need px appended. Some have special characters in variable names that require careful escaping. Some mix shorthand and longhand properties in unexpected ways.

These format-level details are the first thing Figma Make needs to understand, because getting them wrong means every subsequent line of code could be subtly broken. If your spacing token --spacer-3 equals 16 and not 16px, that distinction matters enormously and it's easy to overlook. Put this kind of information right at the top of your guidelines, before you get into any specifics about which tokens to use for what.

Organize tokens around decisions, not around the CSS file structure

When someone is building a UI, they're thinking "I need a background color for this card" or "what's the right text color for a secondary label." They are not thinking "let me scan through all 200 variables in alphabetical order." This applies similarly to Figma Make.

Structure your guidelines around those decisions. Group tokens by what they help you do: picking backgrounds, choosing text colors, setting spacing, applying borders. Your guidelines don’t need to mirror the order of your CSS file.

Give typography its own dedicated section

Typography is where inconsistency creeps in fastest. There are so many properties involved (font family, size, weight, line height, letter spacing) that if there isn’t a complete picture of what's available, it’s easy to start improvising.

The most effective approach is a table that lists every typography class alongside its key properties and a short note about when to use it. This lets the Figma Make scan the full landscape of options in one place.

Create a clear priority between semantic tokens and raw color values

Make sure your guidelines describe a clear hierarchy for color tokens. Your design system may have semantic tokens with names like bg-default or text-danger that encode meaning and intent. It may also have raw palette tokens with names like blue/300 or grey/500 that are just colors without context.

Your guidelines should make it obvious how you want your color tokens used. For example, you’d likely want your guidelines to instruct that semantic tokens are the first choice, and raw palette values are a fallback for situations where no semantic token fits.

Tell Figma Make what not to do

Listing available tokens is necessary, but you also need to call out potential mistakes that could occur when working with your styles. For example, things like:

• Don't use the brand color as a page background.
• Don't hardcode pixel values when a spacing token exists.
• Don't pair dark text with dark backgrounds.

These constraints are just as important as the tokens themselves. Without them, it’s like technically having all the right building blocks but no guidance about how not to combine them.

Include code snippets for tokens that require composition

Some design tokens are split across multiple variables that need to be combined to produce a single CSS property. Shadows are the classic example, where you might have separate tokens for offset-x, offset-y, blur, spread, and color that all need to be stitched together into one box-shadow declaration.

For these cases, include a complete code snippet in your guidelines. The snippet removes all ambiguity about ordering, units, and syntax.

Content of the Guidelines.md file

# Patternz Design System Guidelines

## Setup

Import the styles CSS in your application:

```tsx
import "../Patternz/styles.css";

Token format quirks you need to know first

Before you use any token, understand these three things about how this stylesheet works. Getting any of them wrong will silently break your styles.

1. Most numeric values are unitless. Spacing, border-radius, font-size, shadow offsets — they're all raw numbers. You must multiply by 1px when using them in CSS. If you write padding: var(--spacer-3) you'll get padding: 16 which is invalid CSS. Always use the calc() pattern:

padding: calc(var(--spacer-3) * 1px);   /* becomes 16px */
gap: calc(var(--spacer-2) * 1px);       /* becomes 8px */
border-radius: calc(var(--radius-medium) * 1px); /* becomes 5px */

2. Many variable names contain special characters. Tokens use ✦, /, and 🎨 in their names. In CSS you reference them with var() using the exact escaped names from the stylesheet (backslash before each /). In inline JSX styles, the escaping looks like this:

tsx <div style={{ color: "var(--✦/_text/text-default)" }} />

3. Color tokens are already complete CSS values. Unlike spacing, colors do not need any transformation. Use them directly:

background: var(--✦/_bg/bg-default);
color: var(--✦/_text/text-secondary);

Choosing backgrounds

When you need a background color, start here. These are the semantic tokens, organized by the decision you're making.

Page and card surfaces:

Interactive states:

Dark surfaces (menus and toolbars):

When using these dark surfaces, pair them with --✦/_text/text-onbrand and --✦/_icon/icon-onbrand for legible text and icons.

Semantic status backgrounds:

Tertiary (tinted) backgrounds for lighter variations:

Choosing text colors

Choosing icon colors

Icons follow the same semantic pattern as text. The tokens are:

--✦/_icon/icon-default, icon-secondary, icon-tertiary, icon-onbrand, icon-brand, icon-danger, icon-warning, icon-success.

Match your icon color to the equivalent text color in most cases.

Choosing border colors

Palette colors (fallback only)

Raw palette colors exist for situations where no semantic token fits. Always prefer the semantic tokens above. If you find yourself reaching for a palette color, pause and check whether a semantic token already covers your use case.

• Blue: --🎨/blue/100 through --🎨/blue/600
• Purple: --🎨/purple/100 through --🎨/purple/900
• Violet: --🎨/violet/100 through --🎨/violet/500
• Grey: --🎨/grey/100 through --🎨/grey/500
• Red: --🎨/red/200 through --🎨/red/400
• Persimmon: --🎨/persimmon/100 through --🎨/persimmon/500
• Orange: --🎨/orange/100, --🎨/orange/400
• Green: --🎨/green/100, --🎨/green/500
• Pink: --🎨/pink/500

Also available: --color-1 through --color-7, --white, --black, --warm-red (#F24E1E).

Spacing

All spacing uses --spacer-* tokens. Remember: values are unitless, so always multiply by 1px.

For pixel-precise sizing, --base/size/* tokens are available from 2 to 128.

      ``` ## Border radius | Token | Effective value | When to reach for it
      | |---|---|---| | `--radius-none` | 0 | Sharp corners | | `--radius-small`
      | 2px | Subtle rounding on small elements | | `--radius-medium` | 5px
      | Default for inputs, cards, containers | | `--radius-large` | 13px |
      Prominent rounding for featured elements | | `--radius-full` | 9999px
      | Pill shapes, circular avatars | Legacy tokens (`--borderradius/small`
      = 3, `--borderradius/medium` = 6, `--borderradius/large` = 12, `--borderradius/full`
      = 9999, `--borderradius/default` = 6) are also available but prefer the
      `--radius-*` set. ## Typography Typography classes are the preferred
      way to style text. Each class sets font-family, font-size, font-weight,
      and line-height together, so you get consistent type with a single class
      name. Do not manually set individual font properties when a class exists
      for what you need. ### All typography classes at a glance #### Headings
      and display | Class | Font | Size | Weight | When to use it | |---|---|---|---|---|
      | `.display-display-large` | Whyte | 64px | 700 | Hero headlines, the
      biggest text on the page | | `.display-display-medium` | Whyte | 36px
      | 700 | Major section headlines | | `.display-display-small` | Whyte
      | 22px | 700 | Sub-headlines within sections | | `.heading-display` |
      Whyte | 48px | 500 | Product display text, lighter weight than display
      classes | | `.heading-heading-large` | Inter | 24px | 550 | Page-level
      titles | | `.heading-heading-medium` | Inter | 15px | 550 | Section titles
      within a page | | `.heading-heading-small` | Inter | 13px | 550 | Subsection
      titles, sidebar headings | | `.h1` | Whyte | 32px | 700 | Semantic H1
      elements | | `.h2` | Whyte | 24px | 700 | Semantic H2 elements | | `.h3`
      | Whyte | 20px | 700 | Semantic H3 elements | #### Body text | Class
      | Font | Size | Weight | When to use it | |---|---|---|---|---| | `.body-body-hero`
      | Whyte | 22px | 400 | Hero body text, large introductory paragraphs
      | | `.body-body-large-2` | Whyte | 22px | 400 | Large body text in marketing
      contexts | | `.body-body-medium-2` | Whyte | 18px | 400 | Medium body
      text in marketing contexts | | `.body-body-medium-bold` | Whyte | 18px
      | 700 | Bold callouts in marketing body | | `.body-body-regular` | Whyte
      | 16px | 400 | Standard body text (Whyte) | | `.body-body-regular-bold`
      | Whyte | 16px | 700 | Bold body text (Whyte) | | `.body-body-eyebrow`
      | Whyte | 14px | 500 | Eyebrow/overline text above headings | | `.paragraph`
      | Whyte | 16px | 400 | General paragraph text | | `.body-body-large`
      | Inter | 13px | 450 | UI body text (large) | | `.body-body-large-strong`
      | Inter | 13px | 550 | UI body text (large, bold) | | `.body-body-medium`
      | Inter | 11px | 450 | UI body text (medium) | | `.body-body-medium-strong`
      | Inter | 11px | 550 | UI body text (medium, bold) | | `.body-body-small`
      | Inter | 9px | 450 | Small labels, fine print | | `.body-body-small-strong`
      | Inter | 9px | 550 | Small labels (bold) | | `.title-small` | SF Pro
      Text | 16px | 600 | Small titles in UI contexts | #### Code and monospace
      | Class | Font | Size | When to use it | |---|---|---|---| | `.codeblock`
      | SF Mono | 13px | Multi-line code blocks | | `.mono-mono-large` | Roboto
      Mono | 13px | Inline code in UI (large) | | `.mono-mono-medium` | Roboto
      Mono | 11px | Inline code in UI (medium) | | `.mono-mono-small` | Roboto
      Mono | 9px | Inline code in UI (small) | | `.codeinline-body-large` |
      SF Mono | ~15px | Inline code within large body text | | `.codeinline-body-medium`
      | SF Mono | ~13px | Inline code within medium body text | | `.codeinline-body-small`
      | SF Mono | ~11px | Inline code within small body text | | `.codeinline-caption`
      | SF Mono | ~11px | Code in captions or footnotes | ### Font families
      - **Whyte** is for display and marketing: headings, hero text, paragraphs
      on landing pages - **Inter** is for UI: app headings, body text in product
      interfaces, labels - **SF Mono / Roboto Mono** are for code: blocks,
      inline snippets, technical values ### Font weight tokens If you need
      to override weight independently (rare — prefer the typography classes):
      | Token | Value | |---|---| | `--font/weight/default` | 450 | | `--font/weight/medium`
      | 450 | | `--font/weight/strong` | 550 | | `--base/text/weight/light`
      | 300 | | `--base/text/weight/normal` | 400 | | `--base/text/weight/medium`
      | 500 | | `--base/text/weight/semibold` | 600 | ## Shadows Shadows are
      composed from multiple tokens. Here are the assembled snippets so you
      don't have to figure out the composition yourself. ### Resting shadow
      (small) For cards, inputs, and static elevated elements: ```css box-shadow:
      calc(var(--shadow\/resting\/small\/1\/offsetx) * 1px) calc(var(--shadow\/resting\/small\/1\/offsety)
      * 1px) calc(var(--shadow\/resting\/small\/1\/blur) * 1px) calc(var(--shadow\/resting\/small\/1\/spread)
      * 1px) var(--shadow\/resting\/small\/1\/color), calc(var(--shadow\/resting\/small\/2\/offsetx)
      * 1px) calc(var(--shadow\/resting\/small\/2\/offsety) * 1px) calc(var(--shadow\/resting\/small\/2\/blur)
      * 1px) calc(var(--shadow\/resting\/small\/2\/spread) * 1px) var(--shadow\/resting\/small\/2\/color);
      ``` ### Floating shadows For overlays, dropdowns, and modals. Available
      in sizes: `small`, `medium`, `large`, `xlarge`. Each size has multiple
      layers. Follow the same composition pattern as the resting shadow, substituting
      `floating` for `resting` and the desired size. ## Breakpoints | Token
      | Value | When to reach for it | |---|---|---| | `--breakpoint/xsmall`
      | 320px | Small phones | | `--breakpoint/small` | 544px | Large phones
      | | `--breakpoint/medium` | 768px | Tablets | | `--breakpoint/large`
      | 1012px | Small desktops | | `--breakpoint/xlarge` | 1280px | Standard
      desktops | | `--breakpoint/xxlarge` | 1400px | Large screens | ## What
      not to do These constraints matter as much as the tokens themselves.
      Violating them is a common source of visual bugs. 1. **Do not use brand
      color as a page background.** `--✦/_bg/bg-brand` and `--✦/_text/text-brand`
      are for buttons, links, and small accents. Large brand-colored areas
      overwhelm the interface. 2. **Do not hardcode pixel values when a spacing
      token exists.** Write `calc(var(--spacer-3) * 1px)`, not `16px`. The
      tokens ensure consistency if the scale ever changes. 3. **Do not manually
      set font properties when a typography class covers your need.** If you
      want 13px Inter at weight 550, use `.body-body-large-strong`. Don't write
      `font-size: 13px; font-weight: 550; font-family: Inter`. 4. **Do not
      repurpose status colors.** Danger, warning, and success tokens are reserved
      for their semantic meanings. Don't use `bg-danger` as a decorative red.
      5. **Do not pair dark text with dark backgrounds.** When using `bg-menu`
      or `bg-toolbar`, switch to `text-onbrand` and `icon-onbrand`. 6. **Do
      not use raw palette colors when a semantic token exists.** Semantic tokens
      update correctly across themes. Palette colors don't. 7. **Do not forget
      the `* 1px` multiplication.** This is the single most common mistake
      with this token system. Spacing, radius, shadow offsets, and font sizes
      are all unitless numbers. 8. **Do not skip `border-selected` for focus
      states.** Use `--✦/_border/border-default` for resting borders, and `--✦/_border/border-selected`
      when an input or element receives focus. 9. **Disabled states** have
      their own tokens: `--✦/bg/disabled/default` for backgrounds and `--✦/text/disabled/default`
      for text. Don't approximate disabled styling with opacity hacks.
    

Frequently asked questions

FAQ: Prior to Make kits, I previously extracted style context from my libraries. Do I need to use Make kits?

Yes. It's important to know:

• Figma Make files that used extracted style context prior to the release of Make kits will continue to work as expected.
• If you want to use a library in Figma Make that you'd previously extracted, you'll need to add the library to a new Make kit. After you publish the Make kit, Figma Make files will be able to get the library styles from the Make kit.

FAQ: How do I know what the Make kit is using from my library?

After you add your library to a Make kit, head to the code view. In the editor, you'll see a folder that corresponds to the name of your library. The folder contains:

• A guidelines folder. You can edit the guidelines.md file in this folder and add additional guidelines files.
• A styles.css file.

The Make kit also contains a setup.md file that instructs Figma Make to use your library styles.

The guidelines folder at the root of your Make kit will also have several files in it. Overall, your Make kit will look something like this:

├── guidelines/
│   ├── components/
│   ├── Guidelines.md
│   ├── setup.md
│   ├── styles.md
│   └── tokens.md
│
├── src/
│   ├── app/
│      └── [your application code here]
│   └── [your library folder]
│      ├── guidelines/
│         └── Guidelines.md
│      └── styles.css (your library styles)
│ 
├── package.json
├── ATTRIBUTIONS.md
├── postcss.config.mjs
└── vite.config.ts

Keep in mind, the extracted CSS is a simplified version of your full library. It won’t capture every design detail. To ensure consistency and clarity, it's important that you add more context and rules in the guidelines.md file.

FAQ: Will variable syntax from my library be preserved in a Make kit?

Make kits currently don't support full extraction of design tokens. Instead, it pulls a subset of your variables and uses them to generate a global CSS file with raw values. This means variable syntax won’t be preserved exactly as defined. Rather than a 1:1 mapping, you’ll get a simplified view of your variables reflected in a single .css file. This helps ensure that generated code aligns with your foundational styles.

If you have additional rules or parameters for variables—especially those related to states—we recommend documenting them in your guidelines.md file to maintain consistency across your system.

FAQ: My organization’s design system is managed in multiple libraries. Which library should I choose to export to Figma Make?

When you click Use library in Make, your library is automatically selected for the Make kit when Figma Make opens. This method essentially acts as an entry point for creating a Make kit. Once you're in Figma Make, you can add additional libraries to your Make kit.

FAQ: I updated the design library since I first added it to a Make kit. How do I update my kit?

1. In the code editor for your Make kit, find the folder for your library.
2. If you’ve previously modified the guidelines.md file, copy your changes out of the file.
3. After refreshing, click Edit items in your kit at the bottom of the file explorer in the code editor.
4. Find your library and re-add it to the Make kit.
5. Add your guidelines back to the guidelines.md file.
6. In the upper-right corner of your Make kit, click Update kit.

FAQ: Do any CSS updates or guidelines within Figma Make affect the Figma Design library?

No. Any updates to the CSS styles or guidelines only affect the Make kit.