バージョン管理されたデザイントークンが標準的な慣行になった

デザイントークンはもはや、書き出してそれで終わりという値ではない。ブランチ、プルリクエスト、レビュー、チェンジログを経て進む、バージョン管理されたプロダクトの変更だ。エンジニアがコードをリリースするのとまったく同じだ。この静かな変化が一気に表面化したのは、デザイナーたちがパレットの編集について本物のプルリクエストを投稿し始めたときだった。カラートークンが変更され、PRでレビューされ、承認され、マージされ、チェンジログのエントリとともにリリースされる。

これが重要な理由は美的なものではなく、機械的なものだ。1つのトークンが変更されると、それを読み込むすべてのプラットフォームとプロダクトに波及しうる。つまり、レビューされていないスウォッチの編集が、今や本番環境への変更になるということだ。話の本質はそれだけで、これ以降はその仕組みと、実際にそれが必要かどうかについての話になる。

「バージョン管理されたトークン」が実際に意味すること

それは、トークンが単なるFigmaファイルではなく、リポジトリの中に存在するということを意味する。色、間隔、タイポグラフィ、角丸、モーションの値は、バージョン管理システムが行単位で追跡できる構造化データとして保存される。

ここでの触媒となったのがTokens Studioだ。Tokens StudioはFigmaの中でトークンを編集し、そのトークンセットをGitHubリポジトリに同期させることを可能にする。トークンがリポジトリに入った瞬間、すべての変更がコミットになり、すべての変更提案がプルリクエストになり、すべてのリリースが読める履歴を持つタグ付きバージョンになる。

つまり「バージョン管理されたトークン」は比喩ではない。デザインの意思決定を、GitHubがエンジニアに提供しているのと同じgitワークフローの下に置き、それに付随する安全策、つまり作業を切り離すブランチ、ミスを見つけるレビュー、そして何が変わったのか誰も推測しなくて済むチェンジログを借用するという、文字通りの実践だ。

この変化、トークンの編集は今や本番環境への変更だ

ここからがすべてを捉え直す部分だ。トークンは定義上、共有されるものだ。color.brand.primary を、画面のあちこちに散らばったヘックス値ではなくトークンにした理由そのものが、1つの変更でそれを参照するすべての箇所が更新されるようにするためだった。

その超能力こそがリスクでもある。そのトークンを編集した瞬間、あなたはweb、iOS、Androidにまたがるすべてのボタン、リンク、バッジ、状態に対して変更を提案したことになる。「この画面だけ」というものは存在しない。ほとんどのチームがトークンと組み合わせているビルドステップであるStyle Dictionaryは、マージされたトークンセットをすべてのプラットフォーム向けにコンパイルする。だからこそ、1つの編集がマルチプラットフォームのリリースになるのだ。

それを何気ない保存のように扱えば、テストされていない本番環境への変更を、自分のプロダクト全体に対してリリースしてしまったことになる。コードのように扱えば、どこかに反映される前にレビューを受けられる。

バージョン管理のプレイブックを、トークンに当てはめる

これは保存しておく価値のある表だ。エンジニアがコードを安全にリリースするために使うあらゆる慣行に、今ではデザイントークン版のきれいな対応物がある。

この対応関係は単なる気の利いた喩えではない。それぞれの行が、実際の失敗モードを解決している。

ブランチは、中途半端なパレットの実験が本番環境に漏れ出すのを防ぐ。レビューは、「ブランドカラーを暗くしたら3つの状態でコントラストが崩れた」という問題を、ユーザーの目に触れる前に捕まえる。セマンティックバージョニングは、アプリチームに対して、金曜日にアップデートを取り込んでも大丈夫なのか、それとも計画を立てて対応する必要があるのかを伝える。

パレットの意味的な差分（セマンティックディフ）とはどういうものか

セマンティックディフは、どの文字が変わったかだけでなく、トークンの変更が実際に何を意味するのかを示す。生のgit diffは、#ff6b3d が #ff6434 になったことを教えてくれるだけだ。セマンティックディフは、ブランドのプライマリカラーがわずかに彩度を増したこと、それが今や14個のコンポーネントに影響していること、そして新しい値がdisabled状態のコントラストしきい値を下回っていることを教えてくれる。

実際には、プルリクエストがレビューの場になる。古いスウォッチが左側に、新しいスウォッチが右側に並び、変更されたプロパティが一覧表示され、レビュアーが承認するか変更を要求する。儀式と呼べるものはそれだけで、コードレビュアーがすでに持っているのと同じ筋力を使うことになる。

その価値は、色の決定が見えないものではなくなることにある。このワークフロー以前は、パレットの変更はFigmaファイルの中で起こり、書き出されて、誰が何を決めたのかという記録もないまま本番環境に着地していた。今では、その決定には作者がいて、レビュアーがいて、タイムスタンプがあり、理由がある。3週間後に何かおかしいと感じたとき、チームを問い詰める代わりにチェンジログを読めばいい。

なぜ今これが起きているのか

3つの要素が重なった。

• Tokens Studioが、FigmaとGitHubの往復を実用的なものにした。これにより、デザイナーはトークンをリポジトリに入れるためにエンジニアを必要としなくなった。
• Style Dictionaryが、1つのトークンソースをプラットフォーム別の出力に変えるビルド層として成熟した。これによって、マージが実際のリリースになる。
• GitHubは、ブランチ、プルリクエスト、レビュー、リリース、チェンジログがすでに地球上のあらゆるエンジニアリングチームによって実戦で鍛えられた状態で、基盤としてずっとそこに存在していた。

もう1つの推進力は規模だ。Supernovaのようなプラットフォームは、複数のプロダクトにまたがるトークンの管理と配布をプロダクト化した。これは、パレットが2つ以上のアプリに供給されるようになって初めて手を伸ばすタイプのツールだ。あるトークンセットがweb、2つのネイティブアプリ、マーケティングサイトに供給するようになると、「Figmaファイルを編集した」はもはや安全な一言ではなくなる。

つまりこの変化は、発明というよりも衝突に近い。デザイナーはgitを話せるツールを手に入れ、デザインシステムはそれを必要とするほど大きくなり、エンジニアリングの慣行はすでに実証済みだった。バズったプルリクエストは、まだ気づいていなかった人々にこの変化を可視化しただけだ。

正直な反論（デザインオプス・シアターは実在する）

ほとんどのチームは、パレットに対してフルスペックのgit-flowの儀式を必要としない。1つのプロダクトをリリースしている3人体制のスタジオなら、すべての色の微調整をブランチ、プルリクエスト、2回の承認、セマンティックバージョンのバンプで包むのはプロセスのコスプレだ。存在しない影響範囲を守るために、エンジニアリングのオーバーヘッドを支払っていることになる。

デザインオプス・シアターは正真正銘の失敗モードだ。PR、チェンジログ、レビューキュー、ステータスラベルといった成果物を生み出すため、進歩しているように見える。しかし成果物は成果ではない。トークンの変更が、1人が所有する1つのプロダクトにしか影響しないのなら、そのレビューは自分が自分をレビューしているだけであり、チェンジログは読者が自分1人しかいない日記にすぎない。

オーバーヘッドはどちらの側でも現実のものだ。バージョン管理はトークンに本物の安全性をもたらす一方で、それを必要としないほど小さなチームを、プロダクトではなくプロセスをリリースする方向に誘い込む。罠は、厳格に見えるからという理由でその儀式を採用し、その後でなぜ単純な色の変更に2日もかかるようになったのか不思議に思うことだ。

トークンをバージョン管理下に置く方法

ツールではなく、判断から始めよう。複数の場所にリリースされ、変更されると物事を壊しうるトークンをバージョン管理する。それ以外は、本来あるべき場所であるFigmaに残しておく。

その線を越えるなら、セットアップは短い。

1. トークンセットをFigma内のTokens Studioに移し、値を緩いスタイルではなく構造化データにする。
2. そのセットをGitHubリポジトリに同期させる。これで、すべての変更がコミットになり、すべての提案がプルリクエストになる。
3. ビルドステップとしてStyle Dictionaryを追加し、マージするとトークンがweb、iOS、Android向けに自動的にコンパイルされるようにする。
4. レビュールールを決める。トークンの変更がマージされる前に誰が承認しなければならないのか、何が「破壊的」とみなされるのか。
5. 進めながらチェンジログを書く。1つの変更につき1行、何が変わったか、なぜか、どのプラットフォームかを記す。

自前のやり方では手に負えなくなったら、Supernovaのようなプラットフォームが複数のプロダクトにまたがるトークンの管理と配布を担い、パイプラインを手作業で世話する必要がなくなる。手動配布が苦痛になるのは、デザイナーの数ではなく、トークンを消費するプロダクトの数が増えたときだ。そのタイミングで手を伸ばすといい。

それぞれのトークンがどこに属するかは、この基準を使って判断する。

FAQ

小規模チームにバージョン管理されたトークンは必要か？

通常は不要だ。トークンが1人が所有する1つのプロダクトにしか供給されないなら、レビューは自分の変更を自分で承認しているだけであり、チェンジログは日記にすぎない。トークンの編集がその場にいない誰かの何かを壊しうる場合に採用すればいい。

Tokens StudioとStyle Dictionaryの違いは何か？

Tokens Studioは、トークンを編集し同期させる場所であり、FigmaとGitHubリポジトリをつなぎ、変更をプルリクエストに変える。Style Dictionaryは、マージされたトークンを各プラットフォーム向けにコンパイルするビルドステップだ。一方が作成とレビューを担当し、もう一方が配布を担当する。

GitHubなしでトークンをバージョン管理できるか？

どのバージョン管理ホストを使ってもいい。ただし、ブランチ、プルリクエスト、レビュー、リリース、チェンジログがすでに成熟しているという理由で、GitHubが一般的な基盤になっている。重要なのはブランドそのものよりも、その慣行だ。必要なのは、トークンの変更がレビュー可能で記録されたイベントになる場所だ。

デザイントークンにおけるセマンティックディフとは何か？

それは、どの文字が変わったかではなく、トークンの変更が何を意味するのかを示すビューだ。あるヘックス値が別の値になったことを示すのではなく、古いスウォッチを新しいスウォッチと並べて表示し、どのコンポーネントが影響を受けるか、そしてその変更がコントラストのようなしきい値を超えるかどうかを示す。これによって、色の決定がレビュー可能になる。

これはデザイナーの判断を置き換えるものか？

いいえ。それは判断を見えないままにしておく代わりに、記録しレビューするものだ。このワークフローは新しいブランドカラーが正しいかどうかを決めるわけではない。ただ、すべてのプラットフォームにリリースされる前に、人間がそれを承認し、チェンジログがその理由を説明していることを保証するだけだ。

結論（リリースされるものをバージョン管理する）

この変化は本物だ。Tokens Studio、Style Dictionary、GitHubが一体となって、デザイントークンを静的なエクスポートから、ブランチ、レビュー、セマンティックディフ、チェンジログを備えたバージョン管理されたプロダクトの変更へと変えた。1つの編集がすべてのプラットフォームに同時にリリースされうるなら、エンジニアがすでに使っているのと同じ安全策に値する。

肝心なのは、その境界線がどこにあるかを見極める規律だ。複数のプラットフォームにリリースされ、動くと物事を壊しうるトークンをバージョン管理する。それ以外はFigmaに残し、オーナーが1人しかいない色の微調整を2回承認制のプルリクエストで包みたくなる衝動に抵抗しよう。