DEV Community: Louis Chenais

Specify VS Style Dictionary

Louis Chenais — Tue, 25 Oct 2022 09:57:15 +0000

I'm often asked: "What's the difference between Specify and Style Dictionary?". My answer is always the same: "Yes, they look alike, and Specify is not meant to replace Style Dictionary: it actually enhances it.".

Let's see why together.

This article helps you understand:

differences between Specify and Style Dictionary
how to couple them to generate design tokens and assets

Style Dictionary and Specify are both design tokens generators, and you can use them to generate design tokens and assets respecting your company standards.

What is Style Dictionary?

Created by Danny Banks in 2017, Style Dictionary is a build system that allows you to generate styles for any platform from static design tokens in an agnostic format (e.g., JSON).

For instance, you can feed Style Dictionary with raw colors in JSON and configure it to generate colors in specific formats for different platforms like Android (e.g., Kotlin), iOS (e.g., Swift), or Web (e.g., Sass).

Style Dictionary is open source and available through a CLI or a node module.

Style Dictionary generates design data

Style Dictionary provides out-of-the-box transforms functions to help you create and transform design tokens. Transforms are functions that range from converting colors to HSL, converting dimension design tokens from rem to dp, or even converting an image in base64.

In short, Style Dictionary helps you transform your design tokens to make them compatible with your company standards.

But Style Dictionary doesn't sync your design data

Keeping design data up-to-date at scale means transforming your design tokens for target platforms every time a design token is updated.

Style Dictionary helps with the transformation part, but you still need to run it every time your design tokens get updated.

See for yourself

First of all, let's install Style Dictionary in our directory: yarn add style-dictionary.

Now, let's generate our design tokens, shall we!

yarn run style-dictionary init basic

This command generates:

A tokens folder containing agnostic colors and sizes
A Style Dictionary configuration file: config.json
Our design tokens in Swift, Objective C, XML, Kotlin and SCSS in a build folder
A README.md file describing us what this configuration is doing

Want to know more about this command?

Check out the official examples projects provided by Style Dictionary. In our case, we just used the basic example 👍

Style Dictionary helps you generate and transform your design tokens. But you still need to run Style Dictionary every time they get updated.

Why Specify and Style Dictionary make the perfect match

Specify is a Design API that helps you collect design data from Figma and distribute it in the right format, in the right project, at the right time, and to top it all: automatically.

Let's focus on the "distribution" part. Like Style Dictionary, Specify helps you generate design data for any target platforms.

By default Specify returns design data in JSON but thanks its open source parsers you can transform your design data in any formats. I repeat, in any formats.

Are you starting to see where I'm going here?

Specify can generate design tokens compatible with Style Dictionary. The same ones you feed Style Dictionary with. And as good things come in pairs, Specify automatically detects updates coming Figma and updates agnostic design tokens consumed by Style Dictionary.

Working example

This example project will help you understand how to use Specify and Style Dictionary together.

Please make sure you already have synchronized design tokens in a Specify repository. Want to learn more about this? Watch this 3min tutorial 🎬

From there, we will:

Pull design data from Specify and generate agnostic design tokens compatible with Style Dictionary
Run Style Dictionary and generate design tokens for iOS, Android, and Web

Specify and Style Dictionary are both flexible and powerful generators. However, we must configure them so they understand what to generate for us.

From Specify to Style Dictionary

Let's start by pulling our design data from Specify in our project. The "project" I'm referring to is a directory called your-project.

We will use the Specify CLI to pull design data programmatically from a local directory.

Let's install it by running in the terminal: yarn add @specify/cli.

If things went well you should have the following help menu displayed after running the following command: specify.

Instead of manually configuring Specify, we will ask Specify to generate a working configuration designed for Style Dictionary.

Under the hood, this configuration is mostly using the to-style-dictionary parser.

Here's a short video showing how Specify can generate design tokens compatible with Style Dictionary:

Let's break down what we just did here:

We created a Specify configuration file tailored for Style Dictionary with the command specify init
We finalized the configuration by updating the Specify repository and our personalAccessToken
We pulled our design tokens and assets with the command specify pull.

Which generated the following files:

🗂 output
├── 🗂 tokens
|   ├── 🗂 color
|   |   └── base.json
|   └── 🗂 asset
|       └── font.json
|       └── icon.json
└── 🗂 assets
    ├── 🗂 fonts
    └── 🗂 vectors

What now? Now we've generated agnostic colors, icons and font files, it's time to transform them with Style Dictionary.

From Style Dictionary to target platforms

Here's the following workflow we want to setup:

Now we have agnostic design tokens at hand let's configure Style Dictionary to transform them.

Remove example tokens and use the ones coming from Specify

Instead of writing our configuration from scratch we'll update the one Style Dictionary generated for us with the init command. We want Style Dictionary to run our config against tokens located in the output/ folder Specify generated.

Update the Style Dictionary config file

Our config.json file becomes:

{
  "source": ["output/**/*.json"],
  "platforms": {
    "scss": {
      "transformGroup": "scss",
      "buildPath": "build/scss/",
      "files": [{
        "destination": "_variables.scss",
        "format": "scss/variables"
      }]
    },
    "android": {
      "transformGroup": "android",
      "buildPath": "build/android/",
      "files": [{
        "destination": "font_dimens.xml",
        "format": "android/fontDimens"
      },{
        "destination": "colors.xml",
        "format": "android/colors"
      }]
    },
    "compose": {
      "transformGroup": "compose",
      "buildPath": "build/compose/",
      "files": [{
        "destination": "StyleDictionaryColor.kt",
        "format": "compose/object",
        "className": "StyleDictionaryColor",
        "packageName": "StyleDictionaryColor",
        "filter": {
          "attributes": {
            "category": "color"
          }
        }
      },{
        "destination": "StyleDictionarySize.kt",
        "format": "compose/object",
        "className": "StyleDictionarySize",
        "packageName": "StyleDictionarySize",
        "type": "float",
        "filter": {
          "attributes": {
            "category": "size"
          }
        }
      }]
    },
    "ios": {
      "transformGroup": "ios",
      "buildPath": "build/ios/",
      "files": [{
        "destination": "StyleDictionaryColor.h",
        "format": "ios/colors.h",
        "className": "StyleDictionaryColor",
        "type": "StyleDictionaryColorName",
        "filter": {
          "attributes": {
            "category": "color"
          }
        }
      },{
        "destination": "StyleDictionaryColor.m",
        "format": "ios/colors.m",
        "className": "StyleDictionaryColor",
        "type": "StyleDictionaryColorName",
        "filter": {
          "attributes": {
            "category": "color"
          }
        }
      },{
        "destination": "StyleDictionarySize.h",
        "format": "ios/static.h",
        "className": "StyleDictionarySize",
        "type": "float",
        "filter": {
          "attributes": {
            "category": "size"
          }
        }
      },{
        "destination": "StyleDictionarySize.m",
        "format": "ios/static.m",
        "className": "StyleDictionarySize",
        "type": "float",
        "filter": {
          "attributes": {
            "category": "size"
          }
        }
      }]
    },
    "ios-swift": {
      "transformGroup": "ios-swift",
      "buildPath": "build/ios-swift/",
      "files": [{
        "destination": "StyleDictionary+Class.swift",
        "format": "ios-swift/class.swift",
        "className": "StyleDictionaryClass",
        "filter": {}
      },{
        "destination": "StyleDictionary+Enum.swift",
        "format": "ios-swift/enum.swift",
        "className": "StyleDictionaryEnum",
        "filter": {}
      },{
        "destination": "StyleDictionary+Struct.swift",
        "format": "ios-swift/any.swift",
        "className": "StyleDictionaryStruct",
        "filter": {},
        "options": {
          "imports": "SwiftUI",
          "objectType": "struct",
          "accessControl": "internal"
        }
      }]
    },
    "ios-swift-separate-enums": {
      "transformGroup": "ios-swift-separate",
      "buildPath": "build/ios-swift/",
      "files": [{
        "destination": "StyleDictionaryColor.swift",
        "format": "ios-swift/enum.swift",
        "className": "StyleDictionaryColor",
        "filter": {
          "attributes": {
            "category": "color"
          }
        }
      },{
        "destination": "StyleDictionarySize.swift",
        "format": "ios-swift/enum.swift",
        "className": "StyleDictionarySize",
        "filter": {
          "attributes": {
            "category": "size"
          }
        }
      }]
    }
  }
}

Generate tokens for target platforms-

Now if we run yarn run style-dictionary build we see our colors, vectors and font files transformed for our target platforms.

Did you see the magic happen here?

The config.json is composed of two main properties:

The source property tells Style Dictionary where to look for design tokens (in our case the output folder)
The platforms property tells Style Dictionary how to transform our design tokens

Let's sum things up

We just saw how Specify generates design tokens for Style Dictionary while keeping them up-to-date.

Specify helps you generate design tokens that are always updated so you can transform them with Style Dictionary. Specify doesn't replace Style Dictionary. It enhances it.

In our working example we used the Specify CLI and executed Style Dictionary in a local directory. However, you could totally set this workflow in a GitHub repository thanks to a GitHub Action. But this is for another blog post.

Cheers ✌️

Introduction to DesignOps

Louis Chenais — Tue, 27 Sep 2022 12:59:31 +0000

After reading this post, you'll have a clear idea of what DesignOps is and how it can help your team deliver design improvements in the hands of your users as quickly and with as little friction as possible.

Here's what's on our plate:

Origins of DesignOps
What is DesignOps?
DesignOps in practice

Ready? Let's dive in 🤿

ℹ️ In this post, we use the terms "design" and "designer." However, DesignOps embraces anyone using user-centered and design-thinking processes to solve problems.

Origins of DesignOps

In the beginning, there was DevOps…

Software is eating the world. Engineering teams were divided into two types of developers: the ones writing code and the ones maintaining the infrastructure. This gap between them slowly narrowed, as "agile" emerged and continuous deployment became the norm. Multi-disciplined individuals, able to deploy code faster and more efficiently, eventually appeared.

In other words, DevOps was born.

…and then DesignOps

Historically, developers were always more involved in strategic decisions than designers. Luckily, this started to change once organizations took design more seriously, doubling the average number of designers in their teams over the past decade. Designers eventually won the fight to be "at the table" and became part of strategic decisions. Agile made organizations close the gap between design and engineering teams.

This recognition had its drawbacks, though. Designers had an additional workload alongside their "day jobs" of researching and designing. To top it all, decision-making was even more challenging as designers were usually spread across different teams and products. In short, designers stopped working on their own and faced the same set of pressures developers faced years ago.

DesignOps was born.

DesignOps and DevOps have something in common: "Ops," which means "Operations". Behind this term lies all the processes, methods, and tools that help teams work better together.

What is DesignOps?

"What we've learned over time is that when our [designers] are spending more than 50% of their time doing operational work, that's a problem."
— Adrienne Allnutt, Design Operations Leader, LinkedIn

DesignOps is a mentality that helps you innovate how you build your products. To quote Alex Schleifer, former VP of Design at Airbnb: "you can't innovate on products without first innovating the way you build them." — Source

Where is DesignOps?

Andy Budd, co-founder of Clearleft, states that "DesignOps is the practice of reducing operational inefficiencies in the design workflow." — Source

And what is the design workflow? Glad you asked. The design workflow is what happens between the time you make the decision to design something and the time it's available for your users.

DesignOps is all about the interface between designers, developers, and product owners to design and deliver a great user experience.

As you can see, DesignOps isn't just for designers. DesignOps aims to optimize the execution of projects as a whole, with the least possible friction at each stage.

"Design Operations focuses on the how so that design can focus on the what. It's the design discipline that owns the intentional operationalizing, optimizing and scaling of design."
— Rachel Posman, Senior Director of Design Operations, Salesforce

Who does DesignOps?

DesignOps is both a role and a practice. DesignOps as a role may be a single person or an entire team. DesignOps as a practice can and should be embraced by everyone on the team.

There's a good chance you've already set DesignOps practices and processes without knowing it. For instance, you may have defined a naming convention for your design tokens and components, created a component library, or even set up a Design API like Specify for your design system. These efforts are low-hanging fruits, and you'd be right to focus on these first.

ℹ️ We've been talking about design systems several times already in this post. However, keep in mind that design systems are one of the tools you can use to reduce inefficiencies. You can do DesignOps without having a design system.

DesignOps in practice

All organizations differ from each other. Hence, DesignOps is and should be different from your team to another one.

However, even if organizations pick what they need from the DesignOps menu, their respective recipe will differ.

DesignOps menu is all about:

People: "How we work together"
Work: "How we get work done"
Impact: "How our work creates impact"

"DesignOps is all about increasing the impact of design at scale."
— Sean Rice, Senior Product Designer, GoDaddy

You may be eager to start but also wondering where you should start from and you'd be right. What I can tell you is you only need to start somewhere and the rest will follow.

To help you get started, here are some real-world examples from teams at Dropbox, Pinterest, Fitbit, and Pitch.

Dropbox improves feedback loops

Dropbox improves creative reviews by creating "blue boxes" at the top of each document. Those checkboxes state what feedback designers are looking for, from whom, and what types of feedback aren't helpful.

"This approach is a great reminder at each review of roles and responsibilities; while we want everyone to be heard, we also want to clarify who is the ultimate decision maker for different aspects of the creative output."
— Collin Whitehead, Head of Brand, Dropbox

Pinterest keeps its design org up-to-date

Every Monday morning, Pinterest's design org sends out a visual status document that lists what everyone is working on and shows design comps from each team.

"This keeps our design org of 60 people up to date on what other designers are working on, and also serves as a guide for our cross-functional teams to understand what everyone is working on."
— Meredith Black, Head of Design Operations, Pinterest

Fitbit aligns design and business goals

The Fitbit design org meets quarterly to reflect on the previous three to six months, discuss any urgent priorities, and set goals for the coming months.

"DesignOps can facilitate conversations at the design leadership level to ensure success is being defined based on the company's goals."
— Kate Battles, Manager of Design Operations, Fitbit

Pitch automatically syncs icons from design to code

The product team at Pitch uses a library of 680 icons across 6 products and apps. The team automates its design workflows for continuous integration and delivery (CI/CD) to cut down on manual tasks.

"When we add icons to our library in Figma, Specify automatically triggers a Pull Request in GitHub that adds, removes, or changes icons in our defined output folders, using some custom parsers and settings we've defined."
— Roy van Rooijen, Senior Product Designer, Pitch

Wrapping up

DesignOps is the practice of reducing operational inefficiencies in the design workflow. It involves anyone using user-centered and design-thinking processes to solve problems: designers, developers, and product owners.

DesignOps is about:

How product teams work together
How they get work done
How their work creates impact to optimize the execution of projects as a whole

Specify was born with DesignOps in mind. We started building a Design API to connect design to code and knew it could do even more. That's why we're now experimenting with a design system documentation in Notion that automatically syncs with Figma.

Want to try it out? 👉 Join the Beta Program

Design has never been more essential in organizations than it is now and its impact is stronger than ever. With DesignOps, we're just scratching the surface of design, and the future of design work.

I hope you're as excited as I am.

Introduction to Design Tokens

Louis Chenais — Tue, 09 Aug 2022 09:28:06 +0000

Whether you're a designer, a developer, a manager or a curious executive wanting to scale your company's branding with consistency: this post is for you.

After reading this post, you'll have a clear idea of what design tokens are and how they can help your team manage branding at scale.

However, this article focuses on the why's and the what's of design tokens. I won't share with you how to create, name, transform or distribute them within your design system. These subjects deserve their own article.

Ready? Let's dive in 🤿

The underlying business issue

To present you what design tokens are I'll emphasise first on the business issue they solve.

All organisations in the world share one thing in common: they have a branding. This branding allows them to communicate and differentiate from one to another. To make a long story short, your organisation's branding is the backbone of its communication.

In the past, when print was king, a branding was defined in a graphical charter. Nowadays, this set of graphical rules has evolved to take into account the myriad of screens surrounding us. Your branding must be applied consistently everywhere, whatever the channel you're communicating on. Design systems are the logical evolution of graphical charters. They help everyone involved in the creation, maintain and usage of a branding work together.

Your branding is part of the trust your audience has in your organisation. Cherish it to keep your audience with you.

How would you react if you received an email from your bank with an outdated logo?
How would you feel if your bank website and mobile application didn't share the same branding?
What would you think at night with a full light mode interface burning your tiny eyes?

Let me tell you a story. It's about a simple rebranding of the ACME organisation. We will be in the shoes of a designer trying to apply a design decision at scale.

That's it. You're the new Head of Design at ACME Corp. You're excited and can't wait to start the rebranding you've been hired for. This rebranding consists in replacing the main color of your organisation by a new one. One single color replacement.

Some time goes by and you're finally satisfied with the new branding. It "just" has to be applied in every interface of every product your organisation provides.

Unfortunately for you, your organisation has many interfaces and many platforms to maintain:

A marketing website
A web application
An Android application
An iOS application

You're brave and determined to fulfil your mission. You decide to personally ask every manager of every engineering team to update the color in their codebase with the new value you chose.

You open Slack and start writing:

Hey Steve,

I've updated our main brand color.
The old one is rgb(237, 200, 078).
The new one is rgb(187, 45, 23).

Can you update your codebase with the new value please?

Cheers

You think this will be a no brainer. Spoiler alert: you're wrong.

Steve, the manager in charge of the web platform answers and the conversation looks like this:

Steve: Thanks for the new color value. Do you have the HEX value?
You: This is #EDC840. I think so... 😬
Steve: Are you sure? I'm not really confident about this and have a lot of work to do.

And you didn't even receive the answer from the managers of the Android and iOS teams. And by the way, as you may have guessed, these platforms handle color in different formats.

You start to realise that something is broken between you and the developers you're working with. Communicating design decisions and making sure they are correctly applied is a tedious task. In other words, your organisation doesn't have a "design language" designers and developers can use.

We're human beings. Not machines. Absolute values like a RGB or a HEX color code don't speak for themselves.

To emphasise this, let's butcher this famous quote:

Roses are #ff0000,

Violets are #624de3,

Design tokens are sweet,

And so are you.

Applying a new color on several platforms shouldn't take months...

In 2015, Spotify was rebranded and by extension updated its brand guidelines. It took them several months to propagate the new green color to all of their platforms. Now, thanks to their design system foundation based on design tokens, it would take them only several minutes.

And updating a typeface across many websites shouldn't cost millions

Matthew Ström is a designer who previously worked at the Wall Street Journal. They had to update the typeface on the main website and all its sub brands. It took them 2 years and 100 people to change it. And even now some pages are still using the old typeface.

As a front-end developer, I assume designers are responsible for taking design decisions. Updating a color, a font-size or any "core style" and seeing the result in whatever platform should be effortless for them. Unfortunately, this is not currently the case.

Wouldn't it be great if designers could make a design decision and see it applied correctly everywhere, automatically?

What are design tokens?

Design tokens are names used to express design decisions in your organisation's design language. Those names are meant to be used and understood by humans like you and me. Design decisions can be a color, a typeface, a border radius, an icon, a font size, a gradient or even an animation duration.

"Design tokens are a language for communicating intent between disparate parts of a system."
Ethan Marcotte, Design-ish systems

The design system is your land, and your design tokens are the language people use to communicate design decisions with each other.

Aside from using design tokens in conversations, you will mostly use them in your products. Design tokens are literally everywhere, this page included.

Let's breakdown a digital product:

A digital product is composed of features
A feature is composed of interfaces
An interface is composed of components
A component is composed of design tokens

At Specify, our primary brand color is called ~~purple~~ "app-base-violet" and its value is #624de3.

Here is the anatomy of our primary brand color:

{
  "name": "app-base-violet",
  "value": "#624de3",
  "type": "color"
}

This color can be transformed and formatted to meet the needs of any platform: Android, iOS, Web, etc…

Design tokens can be stored in code. This makes them only as powerful as the engineers enable them to be. Remember that design tokens are meant to be used across your design system and products. To do so, you will have to transform them so they can be used by many different teams.

By using design tokens you secure your organisation's branding and ease its management.

Design tokens help you reach:

Unique source of truth for your branding
Better translation from design to development
Design consistency across any product UI
Improved management of your design system
Easier management of themes and white-labelling features
Proper methodology to collaborate between teams

For designers

Use design tokens if:

You're tired of seeing that design is sacrificed because developers don't or fail to correctly implement your work
You want the power to handle a design decision from its definition to its deployment
You want every part of the app interface and all the elements to have the same look and feel

For developers

Use design tokens if:

You want to spend more time working on valuable business features and not manually updating design tokens values
You want to improve your experience when using and refactoring your styles
You want to use dark/light themes and/or multi brand products

For managers

Use design tokens if:

You're tired of seeing tickets about styling bugs stacking up
You want designers and developers to find a common ground and collaborate seamlessly
You need to ease the scaling of your teams

Conclusion

Design tokens allow product teams to better collaborate and ensure brand consistency across any platform.

This is truly an exciting time to be designing and building consistent UIs at scale. Design tokens are here to last. Our ecosystem is embracing them and so should you. Let’s make styling fun again. Together.

Thanks for reading!

How to sync design tokens from Figma to SCSS variables

Louis Chenais — Wed, 03 Aug 2022 06:50:00 +0000

At Specify, we want to help you work better as a product team. As a developer, one of your job is to implement design tokens in your codebase. And let's face it, manually updating design data is cumbersome.

Specify helps you collect design data from Figma and distribute it in the right format, in the right project, at the right time, and to top it all: automatically.

Let's see how to sync design tokens and assets from Figma to a web project using SCSS variables.

We'll pull design data from the following Specify repository:

We'll generate the following files:

🗂 output
└── 🗂 styles
│   └── colors.scss
│   └── fonts.scss
│   └── text-styles.scss
├── 🗂 assets
|   ├── 🗂 fonts
└── └── 🗂 vectors

Prerequisites

Before anything else, please make sure you have:

created a Specify account
collected design data from Figma to a Specify repository

Specify is a Design API.

You can pull design data from Specify through:

The Specify REST API
The Specify CLI
Our native GitHub application

Using the CLI

The Specify CLI helps you get design tokens and assets from Specify right from the terminal or even in a CI/CD pipeline.

Here's a short video tutorial to help you use the CLI to generate SCSS variables:

Installation

First of all, let's install the Specify CLI: yarn global add @specifyapp/cli.

Once the Specify CLI is installed, run the specify command. You should get the following menu:

Configuration

Specify is flexible. It was designed to adapt to your needs and not the other way around. However you must configure Specify to get design tokens and assets that fit your needs.

We want:

our design tokens to be pulled and transformed as SCSS variables
our icons and our font files to be pulled, converted and optimized

First, let's create a .specifyrc.json Specify configuration inside our project folder.

Instead of writing our configuration manually, let's use our Configuration Template for SCSS variables.

We could copy the suggested .specifyrc.json (CLI) template inside our config file. However, we could use this template right from the CLI thanks to the specify init command.

This commands help you setup a Specify configuration file right from the CLI:

You either choose to use a dedicated configuration template or start from scratch
You choose your template
You choose your configuration format (.js or .json)

Finalizing the configuration

Our configuration is almost done but we still need to change a couple of things:

We must set the Specify repository we're pulling design data from. In our case we're pulling design data from the all-design-data repository created in the @acme-inc organization.
We must generate a new personal access token and set it in the personalAccessToken property

Our final configuration is:

{
  "repository": "@acme-inc/all-design-data",
  "personalAccessToken": "1518676e8cb6a7d5f909acdaa59a00ae9d1f72263e49d1211a52e6303f7f2ece",
  "rules": [
    {
      "name": "Colors",
      "path": "./output/styles/colors.scss",
      "filter": {
        "types": [
          "color"
        ]
      },
      "parsers": [
        {
          "name": "sort-by",
          "options": {
            "keys": [
              "name"
            ]
          }
        },
        {
          "name": "to-scss-variables",
          "options": {
            "formatName": "camelCase",
            "formatTokens": {
              "color": "hex"
            }
          }
        }
      ]
    },
    {
      "name": "Text Styles",
      "path": "./output/styles/text-styles.scss",
      "filter": {
        "types": [
          "textStyle"
        ]
      },
      "parsers": [
        {
          "name": "kebabcasify",
          "options": {
            "keys": [
              "name"
            ]
          }
        },
        {
          "name": "sort-by",
          "options": {
            "keys": [
              "name"
            ]
          }
        },
        {
          "name": "to-scss-mixin-text-style",
          "options": {
            "exclude": [
              "color",
              "text-indent",
              "vertical-align",
              "text-align"
            ],
            "relativeLineHeight": true,
            "genericFamily": "serif"
          }
        }
      ]
    },
    {
      "name": "Fonts Declaration",
      "path": "./output/styles/fonts.scss",
      "filter": {
        "types": [
          "font"
        ]
      },
      "parsers": [
        {
          "name": "to-css-font-import",
          "options": {
            "formats": [
              "woff",
              "woff2"
            ],
            "genericFamily": "sans-serif",
            "fontsPath": "../assets/fonts"
          }
        }
      ]
    },
    {
      "name": "Fonts Import",
      "path": "./output/assets/fonts",
      "filter": {
        "types": [
          "font"
        ]
      },
      "parsers": [
        {
          "name": "convert-font",
          "options": {
            "formats": [
              "woff",
              "woff2"
            ]
          }
        }
      ]
    },
    {
      "name": "Assets / Vectors",
      "path": "./output/assets/vectors",
      "filter": {
        "types": [
          "vector"
        ]
      },
      "parsers": [
        {
          "name": "kebabcasify"
        },
        {
          "name": "svgo",
          "options": {
            "svgo": {
              "js2svg": {
                "pretty": true
              }
            }
          }
        }
      ]
    }
  ]
}

This configuration is now ready to be executed.

Let's run it by executing: specify pull.

The pull command helps you pull design data from the Specify repository you set in the repository property of your configuration. It tells Specify to read and execute your configuration and so it can generate design tokens and assets in your project.

Using the GitHub app

The Specify GitHub app helps you distribute your design tokens and assets from your Specify to your GitHub repositories. Every changes detected in your Specify repository creates a Pull Request in your GitHub repositories.

How to do this:

Head over to your Specify repository you want to pull design data from
Go to your repository Destinations page
Add a Destination
Select GitHub app
Select your GitHub account and your GitHub repository
Select the "SCSS" template
Create the Pull Request
Merge the Pull Request on GitHub
A new Pull Request containing your design data is created 🎉

Let's sum things up

Thanks for reading!

We've learned how to sync our design tokens and assets from Figma to a web project.

We've used the SCSS Configuration Template in two ways:

with the Specify CLI to pull design data in a local directory
with the Specify GitHub app to pull design data in our GitHub repository

Did enjoy the tutorial? Please do share! Don't see the configuration template you're looking for? Feel free to request a template.

How to sync design tokens from Figma to React Native

Louis Chenais — Tue, 02 Aug 2022 06:55:00 +0000

Specify helps you collect design data from Figma and distribute it in the right format, in the right project, at the right time, and to top it all: automatically.

Let's see how to sync design tokens and assets from Figma to a React Native project.

We'll pull design data from the following Specify repository:

We'll generate the following files:

🗂 output
├── theme.ts
├── 🗂 fonts
└── 🗂 vectors

Prerequisites

Before anything else, please make sure you have:

created a Specify account
collected design data from Figma to a Specify repository

Specify is a Design API. You can pull design data from Specify through:

The Specify REST API
The Specify CLI
Our native GitHub app

Using the CLI

The Specify CLI helps you get design tokens and assets from Specify right from the terminal or even in a CI/CD pipeline.

Here's a short video tutorial to help you use the CLI to generate assets and a theme compatible with React Native:

Installation

First of all, let's install the Specify CLI: yarn global add @specifyapp/cli.

Once the Specify CLI is installed, run the specify command. You should get the following menu:

Configuration

Specify is flexible. It was designed to adapt to your needs and not the other way around. However you must configure Specify to get design tokens and assets that fit your needs.

We want:

our design tokens to be pulled and transformed as CSS Custom Properties
our icons and our font files to be pulled, converted and optimized

First, let's create a .specifyrc.json Specify configuration inside our project folder.

Instead of writing our configuration manually, let's use our Configuration Template for React Native.

We could copy the suggested .specifyrc.json (CLI) template inside our config file. However, we could use this template right from the CLI thanks to the specify init command.

This commands help you setup a Specify configuration file right from the CLI:

You either choose to use a dedicated configuration template or start from scratch
You choose your template
You choose your configuration format (.js or .json)

Finalizing the configuration

Our configuration is almost done but we still need to change a couple of things:

We must set the Specify repository we're pulling design data from. In our case we're pulling design data from the all-design-data repository created in the @acme-inc organization.
We must generate a new personal access token and set it in the personalAccessToken property

Our final configuration is:

{
  "repository": "@acme-inc/all-design-data",
  "personalAccessToken": "1518676e8cb6a7d5f909acdaa59a00ae9d1f72263e49d1211a52e6303f7f2ece",
  "rules": [
    {
      "name": "Design Tokens / Colors",
      "path": "./output/styles/colors.css",
      "filter": {
        "types": [
          "color"
        ]
      },
      "parsers": [
        {
          "name": "sort-by",
          "options": {
            "keys": [
              "name"
            ]
          }
        },
        {
          "name": "to-css-custom-properties",
          "options": {
            "formatName": "kebabCase"
          }
        }
      ]
    },
    {
      "name": "Design Tokens / Text Styles",
      "path": "./output/styles/text-styles.css",
      "filter": {
        "types": [
          "textStyle"
        ]
      },
      "parsers": [
        {
          "name": "to-css-text-style",
          "options": {
            "exclude": [
              "color",
              "text-indent",
              "vertical-align",
              "text-align"
            ],
            "relativeLineHeight": true,
            "genericFamily": "serif"
          }
        }
      ]
    },
    {
      "name": "Design Tokens / Import font files in CSS",
      "path": "./output/styles/fonts.css",
      "filter": {
        "types": [
          "font"
        ]
      },
      "parsers": [
        {
          "name": "to-css-font-import",
          "options": {
            "formats": [
              "woff",
              "woff2"
            ],
            "fontsPath": "../fonts"
          }
        }
      ]
    },
    {
      "name": "Design Tokens / Import font files",
      "path": "./output/fonts",
      "filter": {
        "types": [
          "font"
        ]
      },
      "parsers": [
        {
          "name": "convert-font",
          "options": {
            "formats": [
              "woff",
              "woff2"
            ]
          }
        }
      ]
    },
    {
      "name": "Design Tokens / Vectors",
      "path": "./output/vectors",
      "filter": {
        "types": [
          "vector"
        ]
      },
      "parsers": [
        {
          "name": "svgo",
          "options": {
            "svgo": {
              "js2svg": {
                "pretty": true
              }
            }
          }
        }
      ]
    }
  ]
}

This configuration is now ready to be executed.

Let's run it by executing: specify pull.

Using the GitHub app

The Specify GitHub app helps you distribute your design tokens and assets from your Specify to your GitHub repositories. Every changes detected in your Specify repository will create a Pull Request in your GitHub repositories.

How to do this:

Head over to your Specify repository you want to pull design data from
Go to your repository Destinations page
Add a Destination
Select GitHub app
Select your GitHub account and your GitHub repository
Select the "React Native" template
Create the Pull Request
Merge the Pull Request on GitHub
A new Pull Request containing your design data is created 🎉

Let's sum things up

Thanks for reading!

In this post, we learned how to pull in our React Native project our design tokens tokens and assets with Specify and the React Native Configuration Template.

We learned how to use the configuration template directly within the Specify CLI and the GitHub app.

Did you find this tutorial helpful? Please do share! Don't see the configuration template you're looking for? Feel free to request a template.

How to sync design tokens from Figma to Tailwind

Louis Chenais — Sat, 12 Mar 2022 11:21:00 +0000

Why use an automatic sync tool?

Keeping in sync design decisions coming from design to code helps your branding be consistent at scale. Let me explain you what I mean by "from design to code".

It means your design decisions must go through several steps:

Extract those decisions from your design tool (i.e. Figma)
Make those decisions available to developers so they can use them in a specific platform (i.e. web)

Developers are not the only one to use those design decisions. Other parties like designers and business stakeholders will need them too.

Hence, your design decisions must be extracted from design and synchronised into your organization's design system.

Let's go back on developers. More precisely, web developers who are using design tokens thanks to the Tailwind framework. How can they ensure to always use the latest design tokens in their Tailwind configuration? Manually updating is a way to go but it's error-prone and surely not the most efficient.

What if you could have your Tailwind theme always in sync with the latest design decisions — automatically?

Thanks to Specify and the to-tailwind parser, it's now possible.

What is this parser?

From your Specify repository, you can easily extract all your design decisions using the to-tailwind parser. It helps you format design tokens to create a theme compatible with the TailwindCSS specification. By the way, the theme is also compatible with WindiCSS.

This parser creates a file containing the whole theme. It can then be used in your tailwind.config.js file. To use this parser head into your Specify configuration file.

Setting up the automatic sync

Let's setup a simple config to sync our colors coming from a Specify repository.

From this repository, we will extract all the colors using this configuration.

{
  "repository": "@my_organization/my-repository",
  "personalAccessToken": "my_personal_access_token",
  "rules": [
    {
      "name": "Design Tokens / Colors",
      "path": "tailwind-theme.js",
      "filter": {
        "types": ["colors"]
      },
      "parsers": [
        {
          "name": "to-tailwind"
        }
      ]
    }
  ]
}

The personal access token can be extracted from our application in your personal settings.

This configuration will generate a file named tailwind-theme.js in your root directory containing:

const theme = {
  colors: {
    accent: "#6650ef",
    black: "#1e212b",
    green: "#58cd52",
    grey: "#ccd5e1",
    orange: "#ff8e05",
    red: "#f5483f",
    white: "#ffffff",
  },
};

module.exports = theme;

You can now use the freshly extracted colors in your tailwind.config.js:

const { colors } = require('./tailwind-theme');

module.exports = {
  // ... your Tailwind config
  theme: {
    extend: {
      colors,
    },
  },
};

And you're all set. You can now use the class .text-accent in your HTML document.

A more advanced setup

Colors are easily synced but sometimes you will:

Need more than just colors
Need to be able to override values
Need to extract design tokens from another source

For example, let's say you are currently transitioning from a CSS-in-JS to a Tailwind style implementation.

You want to extract your colors, text styles, fonts and shadows from your Specify repository but you still want to keep some of the old shadow values until you have completely migrated.

You can easily extract all the information from your Specify repository using this configuration:

{
  "repository": "@my_organization/my-repository",
  "personalAccessToken": "my_personal_access_token",
  "rules": [
    {
      "name": "Design Tokens / Colors - Shadows - Text Styles",
      "path": "tailwind-theme.js",
      "filter": {
        "types": ["color", "shadow", "textStyle"]
      },
      "parsers": [
        {
          "name": "to-tailwind",
          "options": {
            "formatName": "kebabCase",
            "formatConfig": {
              "module": "commonjs"
            }
          }
        }
      ]
    },
    // Rule to extract the fonts assets in the `.woff2` format
    {
      "name": "Assets / Font files",
      "path": "public/fonts",
      "filter": {
        "types": ["font"]
      },
      "parsers": [
        {
          "name": "convert-font",
          "options": {
            "formats": ["woff2"]
          }
        }
      ]
    },
    // Rule to create a css file that import the correct
    // `@font-face` in a `fonts.css` file
    {
      "name": "Design Tokens / Font face",
      "path": "public/fonts/fonts.css",
      "filter": {
        "types": ["font"]
      },
      "parsers": [
        {
          "name": "to-css-font-import",
          "options": {
            "formats": ["woff2"]
          }
        }
      ]
    }
  ]
}

This configuration allows you to extract every design tokens you need.

Now, let's say you have some old shadows coming from a style file like this one:

const shadows = {
    elevation1: 'box-shadow: 0 1px 2px 0 rgba(0, 0, 0, 0.05);'
};

module.exports = shadows;
To use them in your config file, you would use it like this:

const { colors, boxShadow, fontSize, fontFamily } = require('./tailwind-theme');
const { shadows as oldShadows } = require('./style/shadows');

module.exports = {
  // your Tailwind config
  theme: {
    extend: {
      colors,
            boxShadow: {
                ...boxShadow,
                ...oldShadows, // this way, oldShadows will override the new ones
            },
      fontSize,
      fontFamily,
    },
  },
};

You can find more examples on our GitHub configuration examples repository.

Conclusion

Figma → Specify → Tailwind = 🔥

By using Specify and its to-tailwind parser you can easily extract design tokens from Figma to Specify and then from your Specify repository to your codebase.