共通言語としてのデザイントークンと Figmaでの運用 フロントエンド開発部 釜堀 友基 2024年12月13日 Friends of Figma Fukuoka Figma Winter Night 2024 〜デザイナーとエンジニアのための協業トークセッション〜

自己紹介 ● 「Chatwork」の開発 ● デザイン部と連携し、UIなどデザイン基盤の整備に従事中 ○ デザイントークンやコンポーネントの整備 ○ UIの利用方針などのドキュメント化 ○ 社内向けUIドキュメントサイトの開発・運用 2 株式会社kubell フロントエンド開発部 釜堀 友基 (@kamy0042)

目次 CONTENTS 01 | デザイントークンの概要 02 | 共通言語としてのデザイントークン 03 | Figmaにおけるデザイントークン運用 04 | Figmaでデザイントークンを扱う時の課題 05 | まとめ

01 | デザイントークンの概要

デザイントークンとは 設計（デザイン）時の意思決定を名前と値のペアで分類した、 唯一の信頼できる情報源（single source of truth ） 5 color-text-primary: #000000; font-size-heading-level-1: 44px; Design Tokens Format Module https://tr.designtokens.org/format/#design-token DTCG Glossary https://www.designtokens.org/glossary/ 参考： デザインツールやプログラミング言語に関係なく利用できるように配布された、 UIの最小単位 W3C Design Tokens Community Group によると...

よく挙げられるメリット 6 ● デザインに対する共通認識をつくりやすい ● それにより、色やタイポグラフィー等 意思決定をシステマティックに行える ● 一箇所 値を更新するだけで、変更をすべて 関連する箇所に適用できる つまりデザインや実装を行う際、より本質的な部分に時間を割 こと で る！ このUIにはどの色を 使えばいいんだろう...？

よく挙げられるメリット 7 ● デザインに対する共通認識をつくりやすい ● それにより、色やタイポグラフィー等 意思決定をシステマティックに行える ● 一か所 値を更新するだけで、変更をすべて 関連する箇所に適用できる つまりデザインや実装を行う際、より本質的な部分に時間を割 こと で る！ このUIにはどの色を 使えばいいんだろう...？ デザイナーとエンジニアが 連携するに これが重要！

02 | 共通言語としてのデザイントークン

職種間の連携に必要なもの 9 ● 同じUIに対して会話しているつもりでも、思い浮かべているも 異なりがち ○ デザイナー：デザインベース 知識や認識に沿って話す ○ エンジニア：コードベース 知識や認識に沿って話す ● そ 状態で議論を進めると、課題感 相違や認識 ズレ等 すれ違いが生じる ○ 手戻り 原因 ○ 認識を擦り合わせるコスト 増加 関係者全員が同じ土俵に立って話すために 、 共通認識を持つため ツール = 共通言語が必要 ※ドメイン駆動開発におけるユビキタス言語 ようなも

ではどのようにUIの共通言語を策定する？

デザイントークンを 共通言語の１つとして位置付ける ● 設計（デザイン）時の意思決定を整理、分類 ● 唯一の信頼できる情報源として存在する ので、異なる職種が共通して参照するものとして最適では！？

03 | Figmaにおけるデザイントークン運用

デザイントークンの管理 13 ● 共通言語として成立させるには、同一性を担保するため１つの元データをFigma／ 実装 双方で用いる必要がある ● そ 場合、下記 ２パターンが考えられる ○ Figma(Variables)で管理→エクスポートしたJSONファイルを実装で利用 ○ JSONで管理→Figma(Variables)にインポート Figma(Variables) ? JSON? or

弊チームの場合 14 決定：JSONで管理し、Figma(Variables)にインポートする 理由 ● 実際にユーザーの手元で動 もの 正であるべ ○ Figmaファイルは完成品ではなく、開発途中のスナップショット的な位置付け ● 運用フロー シンプルになる ○ 更新時に必要な手順が増えるほどオペレーションコストが嵩む ○ メンテが滞っても影響を最小限に抑えられる ● Figmaに依存しす ると万 一の事態でも乗り換え 困難になる ○ (Figmaのイベントで言うのもあれだが)いつか主流となるツールが変わるかも... ○ そもそもFigmaだとDTCGが規定したフォーマットに準拠できない

デザイントークンとFigmaの連携 15 ● 最初はTokens Studioのプラグインを利用してJSONを管理 ● 使っていく内に色々とNot for meな点が見えてくる ○ タイポグラフィーに関わるトークンをVariablesにエクスポートできない ○ こちらもDTCGのフォーマットに沿っていない ○ やりたいことの割には学習曲線が急勾配 ■ チームで運用することを考えると学習コストがやや大きい ■ このプラグインでしか使えない知識... ※ タイポグラフィー系トークンのエクスポートとDTCGのフォーマット問題は 2024/8のRelease 2.0で解決したようです

デザイントークンとFigmaの連携 16 ● 現在はVariables Importを利用中 ● シンプルかつ必要十分 ○ modeを設定しつつJSONをVariablesにエクスポートできればそれで十分 ● 出来合いのプラグインの中では最もDTCGのフォーマットに準拠している（はず） > This Figma plugin allows you to import design tokens in the Design Token Community Group format as Figma Variables. https://github.com/microsoft/figma-variables-import - README

Variables Importの設定 17 ● コレクション名やmodeを設定するにはmanifestファイルを作成する ● 作成したファイルはトークンのJSONファイルと一緒にドラッグ＆ドロップ サンプル：manifest.colors.json { "name": "Colors", "collections": { "colors": { // コレクション名 "modes": { // mode 設定 "light": [ "theme-light.json" ], // デザイントークン JSONファイル "dark": [ "theme-dark.json" ] } } } }

04 | Figmaでデザイントークンを扱う時の課題

直面した課題1：扱えるtypeが限定されている 19 ● DTCGのフォーマットには、「そのトークンがどんな形式か」を表すためのtypeが規定 されている ● VariablesはDTCGにおけるtypeに対応していない

直面した課題1：扱えるtypeが限定されている 20 ● Variablesだとstring / number / boolean / color に対応 ○ string / booleanはDTCGのtypeに存在しない ○ その他、DTCGに存在するtypeがVariablesに存在しない ○ 特にfontFamilyやfontWeightが非対応なのが辛い ● Variables importだとdimensionとdurationはnumberに変換してくれる ○ それ以外はインポート不可 DTCG フォーマットに完全に準拠できないことを考慮に入れておく ※いくつか typeについて DTCG側を修正したいという issueも立っています 具体例

直面した課題2：単位なしのline-heightを設定できない 21 ● Figmaのline-heightはピクセル固定かパーセンテージによる指定しか行えない ● CSSだと単位なしのline-heightを指定するのが推奨されているが、Figmaだとそれが不 可 デザイントークン上で line-heightをpx で保持しておき、 Style Dictionaryで単 位なしに変換する 「デザイントークン上で line-height:1.5と定義しよう！」 Figmaだと1.5pxとして扱われる！ ※トークン名でデザイナーとエンジニアが やりとりできれ コミュニケーション なんとかなる

05 | まとめ

今回話した内容 23 ● 関係者全員が同じ土俵に立って話すために 、共通認識を持つため ツール = 共通言語 が重要 ● デザイントークン UI 共通言語 １つとして位置付けられる ● デザイントークンを共通言語として成立させるに １つ 元データをデザイナー・エンジニア が参照する必要がある ○ Figma(Variables) or JSONファイル どちらかで元データを管理 ● Figma上で デザイントークン 扱いに まだまだ課題あり ○ 今後に期待

働くをもっと楽しく、創造的に 24