Loading collection...
Overview
Figma TokensとStyle Dictionaryを組み合わせたDesign Token運用を検討した。
けっこうよさげ。
Design Tokensとは
デザインシステムにおける、いわゆるスタイル変数集をもってSource of truthを実現するコンセプト。イケてる海外の会社はみんなやってるっぽい。
- 利用することのメリット
- そのTokenこそが真である(信頼できるデータ)前提で組織内で会話できる
- デザインデータから逐一カラーコード・空き・余白などを取得しなくてもいい
- デザイナーと開発者それぞれが一括置き換えしやすくなる
- デザインに圧倒的なガバナンスを実現できる
- 難所
- Figmaの標準ライブラリ機能はCSSプロパティのカバレッジが低かったり、変数の構造化が出来なかったりする
- 実用的なように構造化されていないと変数あって初見のデザイナーが困惑
- 定義どこに置く問題
- 方策
- プロパティの定義 + 適用 + 同期を担うFigmaプラグイン、その名も Figma Tokens。デザイナー全員いれることになる。
- スタイル定義をデータで書き出しても、利用できるフォーマットは環境によってさまざま(js, scss, swift…)であるから、JSONをもとに中間に変換機構を使用する。そのデファクトがStyle Dictionaryである。
- 結論
- めっちゃデザインのガバナンス聞かせられるので5人以上デザイナーいる環境では ぜひ入れたほうがよさそう。ワンプロダクトな組織ならなおさらである
- (どうやろうとも必要だが)、色々ルールや運用の取り決めは必要。まあまあコスト高い。
- とっつきやすさでいうと、最初ドン引きだがDesign Tokenのコンセプトの王道運用ができるので、そのあたりのリテラシー上がりそう
Figma Tokens

リアルタイムにjsonプレビューできる

メモ
やったこと
- いくつかのプロパティを定義する
- Buttonコンポーネントにあてる
- Githubにあげる
- 一通り理解するまで30分程度
メモ
- いい感じにCSSプロパティが一揃い揃っていて柔軟に設計できる。
- たとえば、Spacingをsm, md, lgときめて、Auto Layoutの余白に適用するとかもできる。ここらへんはFigma標準にはないのでよい。
- Figmaの右側のプロパティのUIは思い切って放棄することになる。
- 変数に更に変数を割り当てとかできる。
- text.black = {black.400}とかできる
- Primitive ColorとかはGlobalのsetにもっといて、Semantic Colorは自社のsetにもつ運用がよさそう
- 値の定義は
colors.text.black
みたいな感じで構造化する
- GithubにPRできる。あげるのもpullするのもPersonal Access Token通す必要あり。
- publicにしとけば誰でもpullできるとかではないらしい残念
- GithubからPullできる(!)
- 逆にいうと、git以外いい置き場がなさそう
- jsonのエディタもついてるので初期はまとめて定義してどばっといれてしまえば1時間ぐらいで準備できそう
- JSONのエディタが同時に使えてそっちでも編集できるので、スプシでまとめるかなんかして初期に大量なプロパティ情報を一括で突っ込むのができてよさそう
- Figmaの標準のスタイルライブラリをちまちまやるのはやばいしすぐ壊せるからしんどい。
- 値
- 何の単位でも入れられるが、そのまま使われるので、border-radiusで1とかいれると、単位足りないよってことでコード側で困る
- オペレーション
- なにか変更あるとデザイナーそれぞれがGithubから最新状態をPullする感じになる
- なので、Design Tokenの同期と、Figma Componentの取り込みと、2つ儀式ある感じになる。ただ、極論機能つくるデザイナーはDesign Tokenなんて知らん、コンポーネントだけ使うんだというのがそもそも理想なのでメンテナーが頑張ればいいかも
コードでの利用
参考記事
2つ目の記事をまるっと参考にした
サンプルコード
仕組み
パッケージ2ついる。
- 前者はビルド前の下ごしらえとしてJSONをFigmaのエイリアスとかをよしなに変換する君、
- 後者はそれをコードで利用できる感じに書き出してくれる君。 config.jsonでwebpackみたいに書き出し設定可能
なので、JSONをリポジトリにあげておわりでなく、
token-transoformer (ry && style-dictionary (ry
みたいなコマンドをビルドプロセスに組み込む必要があるやったこと
- パッケージインストール
- JSONの変換と、定義ファイルJSへのビルド。以下、関係ディレクトリ
- src/tokens
- token.json
- output.json → token-transformerで変換したファイル
- config.json → style-dictionaryの設定。output.jsonをinputとして指定し、src/themesに書き出す
- src/themes
- theme.js
- theme.d.ts
- theme.scss
- Emotion/ReactのStyled記法のなかでのimport
メモ
- 上記の変換機構がPR後のビルドとして組み込まれているような設計の場合、デザイナーが大枠の健気にスキーマ名変更してmergeされるとCIこけるだろう
- TypeScriptでいい感じに変数使えた
- いちいち末尾に
.value
つけないと値が呼べないので冗長感否めない

theme.text.color
としたいのにtheme.blackみたいなサジェストがフラットにでてきてしまう。設定かFigma Tokensの設定悪い?
どういう構造にするといいか
- 参考記事
- Spectrumでは色は3段階・他は2段階
More Notes
デザインとデザイナーの原則
23時間前
アジャイルとデザイン
1日前
よく見るサイト集
2日前
フィードバックと主体性
2週間前
視座について
1ヶ月前
知識は経験を豊かにする
1ヶ月前
パラドクスの一覧
1年前
UXフレームワークとモデルの一覧
1年前
Overview of Design Maturity Models
1年前
仕事において価値のある発言、記述
1年前
効果的に説明する技術
1年前
命名と用語法
1年前
成長とフィードバック
1年前
認知バイアスの一覧
2年前
一定時間ごとに自動的にスクリーンショットを保存する仕組みをつくる
2年前
cscreenコマンドでmacの解像度を限界まで上げる
2年前
Google Meet / Zoomを会議時間になったら自動起動する方法
2年前
デザインシステムに関連するツールまとめ
2年前
2023年時点でイケてるタスク管理・スケジュール管理・タイムトラッキングのツールをまとめてみる
2年前