同一プロダクトでtoCとtoBを両立させたいときのFigmaデータ構成

この記事の概要

私はよくFigmaのバリアブルやファイル、ライブラリーの構成について相談を受けます。
その中でも結構難しい部類と思われるのが以下の条件のときです。

• 1つのプロダクト（ブランド）
• toCとtoBどちらも存在する
  • 例えばメディアサイトとその記事を入稿・管理するための画面、のようなイメージ
• 両者を同じテイストで提供したい

なんとなくで作り始めるとすぐに辛くなる構成だと思うのですが、最近は自分の中ではブラッシュアップされてきました。
ということでそれを記事にしました。

外部のツールを使えば良いとか、テイストを揃える必要は無いんじゃないかとか、色々な意見があるような気もしますが、こういう要件も聞きはするので、その前提で読んでください。

これがベストプラクティスだと思って書いている記事でもありません。こういう考えにしたら以前よりはだいぶ良くなった、という程度です。

結論

（1つのクラス=1つのFigmaファイルです）

• Global Tokens
  • プロダクト・ブランド全体の色やサイズなどを定義する
  • ここに無いものは使わない心構え
• Alias Tokens
  • toCとtoBで定義に必要なものが違うことも多いので分ける
  • 例
    • toCでは余白を多めにとる必要があるが、toBは若干キツキツで良いから一画面あたりの情報量が欲しい
    • toCではジャンプ率を高めに表現したい（等比数列的）、toBではそこまでは不要（等差数列的）
    • toCではinfo, success, warn, errorに対応する色を定義すれば良いが、toBではそれらのvariantやinverseなど細かいバリエーションが必要
• Components
  • toCとtoBで定義に必要なものが違うことも多いので分ける
  • 例
    • 同じようなボタンと見せかけて、toCでは無料や○月まで限定といったマーケティング的な要素が欲しいが、toBでは不要
    • 請求関連のインターフェースはtoBでは多用されるがtoCではまったく使わない
• Graphics
  • グラフィック系の要素をすべてAlias Tokensで作ろうとすると大抵破綻が生じるので、Global Tokensを直接使う
  • （グラフィックの単位にも寄る気はしつつ）個別のイラストやエフェクト類はtoCとtoBで分けるメリットはそこまでなさそう
• Mockups
  • それぞれのモックアップ（デザインデータ）
  • Global Tokensを直接インポートしないで済むのであれば、しない方が良いと思う

この構成に至った背景

よく聞く辛さは以下のようなものでした。

• toCとtoBを横断して同一の世界観を出したかった
• なのでデザイントークンやコンポーネントを共通にした
• 最初のうちは良かったが、徐々に条件分岐やバリエーションが増えていった
• 1つのコンポーネントの中にtoCだけ・toBだけのvariantが増え、片方での使用の際もう片方のものは邪魔になるばかり
• 命名規則でsharedなものとspecificなものを区分しているが、ルールが統一できているわけでもない
  • 「これはtoCって接頭辞がついているけど例外的にtoBでも使うよ」のようなイメージ

こういった事象が起こる多くの理由は「世界観やルック＆フィールの統一」と「トークンやコンポーネントの共用」が一緒になってしまっていることのようです。

あくまで対象を使用する人間の弁別する（できる）単位が重要であり、見た目やコードが似ていたとしても、使用者の認知が違うならそれは別のトークンやコンポーネントで表されるべきです。

その前提に立つと、真にグローバルなもの以外は共通化せず、ほぼすべてを個別に作った方が良いと言えるのではないか？という考えになりました。
というわけで冒頭に示した図（Global TokensとGraphicsしか共用でない）のように整理しています。

まとめ

• 見た目やブランドを統一することと、トークンやコンポーネントを共通化することは別
• 源流だけを一緒にして、あとは個別に考えるつもりでいた方が良い