自社のデザインシステムに適したデザイントークンを考えたお話
こんにちは。ていてい（@dbko1991）です。
今は株式会社カミナシでプロダクトデザイナーをしています。
自分は中国出身で、火鍋🥘を食べて冬を楽しんでいます。
では本題です。このnoteでは、カミナシで実施した「自社のデザインシステムに適したデザイントークンの検討」について、検討の背景や運用に至った流れ、試行錯誤したことについてお話します。
これからデザイントークンを検討し始める方に少しでもご参考になれたら嬉しいです。
※ 初歩的なnoteなので、すでにデザイントークンを活用されている方はさらに良い運用方法がありましたら、ぜひお話を聞かせてください。
なぜ私たちはデザイントークンを検討し始めたのか？
デザイントークン導入のメリットとしては、「一貫したデザインを作るため」や、「デザインとコードの統合」などがあるかと思います。
私たちももちろん同じ目的を持っていましたが、検討をし始めた一番の理由はエンジニアのリソースが足りない状況を解決したいからでした。
現在デザインシステムに取り組むチームの構成は、エンジニア1名とデザイナー3名になっており、かつエンジニアの方はフルタイムではありません。
エンジニアが限られた時間の中でコアの業務に集中できるように、極力余白やスタイルなどデザインに関する細かいコミュニケーションを減らすことを目指しました。
デザイントークンを導入した今では、デザイナーが全てのスタイルをデザイントークンにしてGitHubにあげており、スタイル変更がある場合にも基本的にエンジニアが実装変更をする必要がない状態をつくれています。
どのようにデザイントークンを運用しているか？
ここから具体的な定義方法を紹介したいのですが、プロダクトの現状を踏まえてお話しできたらと思います。
「カミナシ」は、現場で働くノンデスクワーカー向けの現場DXプラットフォームです。アプリを使って、現場業務の無駄を省き、アナログだった業務を自動化することができます。アプリの種類は管理者が使う管理用アプリ（Web）と、現場スタッフが使う記録用アプリ（iPadやiPhone）があります。
本来ならパソコンやモバイル、タブレットそれぞれのデバイスに最適なコンポーネントを定義することが理想ですが、限られたリソースの中で最速でデザインシステムを運用し始められることが現段階のゴールでしたので、管理用アプリの「Web」と、記録用アプリの「Touch」、この2種類に分けてコンポーネントを作っています。
1. トークンの種類
私たちは簡単な単語でトークンの種類を分けて、このように定義しています。
Basic Tokens：スタイルを表すために、利用可能なスタイルを網羅する
Common Tokens：利用用途を表すために、全体に利用する
Local Tokens：利用用途を表すために、独自のコンポーネントに利用する
2. トークン名の付け方
肝心なトークン名の付け方を検討するのに3つのことをしました。
2-1. トークン名に必要な要素を洗い出す
まず、上記各種トークンの目的を達成するのにどんな要素を含めば良いかを検討しました。
2-2. 要素の順番を決める
次に、スタイルを識別する時の文脈に合わせて、以下のように要素の順番を決めていきました。
また、各要素は適用箇所によって柔軟に要素を付けたり無くしたりしています。
2-3. 約物のルールを決める
最後に、約物のルールを決めます。トークン名はCSSのクラス名と似ている考え方で、私たちはこのように約物を利用することにしました。
ピリオド（.）：要素の区切り
ハイフン（-）：単語の接続
3. トークンをエンジニアが利用するまでの流れ
決めたトークンをエンジニアが利用できるように、私たちはNotionとTokens Studio（元Figma Tokens）プラグインを使っています。
主な流れとしては以下のようになっています。
Notionでコンポーネントごとにトークン一覧をまとめる
Tokens Studioでトークンをデザインに適用し、簡単にJSONをGitHubにあげる
エンジニアがTokens Studioでトークンを確認して実装する
3-1. Notionでコンポーネントごとにトークン一覧をまとめる
Notionを使ってコンポーネントのドキュメンを書いて、トークンもその中にまとめています。
こうすることで、デザイントークンを追加する際に既存のトークンを一覧でき、使われているコンポーネントの箇所をみて参考にできます。
3-2. Tokens Studioでトークンをデザインに適用し、簡単にJSONをGitHubにあげる
NotionでリストアップしたトークンをTokens Studioを利用して、コードを書かずに簡単にプルリクエストを作ってJSONデータをエンジニアに渡せます。 Tokens Studioの利用方法は公式サイトに書かれているので、こちらでは省略します。
3-3. エンジニアがTokens Studioでトークンを確認して実装する
JSONデータを利用する際、どの箇所にどのトークンが使われているかはTokens StudioのInspect画面で確認できるので、デザイナーといちいち確認するコミュニケーションを省くことができます。
運用するまでにどんな試行錯誤をしたか？
こうして、私たちはデザイントークンを運用するまで至りました。
ただ最初から綺麗に全ての定義と運用方法を考えられたわけではありません。実際に試行錯誤したことをいくつか挙げてみます。
1. Common Tokensの定義とLocal Tokensの定義が曖昧
デザイントークンの関連記事を読んで、この画像のようにトークンを定義する方法をよく見かけます。
私たちは最初に真似してBasic、Common、Local 3種類のトークンを定義をし、種類を明示するために「common.color-text.~~」や「local.spacing.~~」のように、種類もトークン名に入れていました。ただし定義していくうちに、上手くいかない場合がありました。
共通に使われるトークンってどこまで共通でOKなの？InputとSelectが似ているので、この二つを使っていればCommon Tokensとして定義して良いの？そもそも種類を入れる必要がある？
定義が曖昧になって、みなさんが困惑してトークン名のリストアップに手が止まってしまいました。
解決方法
Local Tokensは特定のコンポーネントに利用するという定義は変わらないが、特定の複数コンポーネントの場合も含め、コンポーネント名をトークン名に記載することにしました。
Common Tokensは全体に利用するという定義にし、抽象度の高い用途として丸める単語をトークン名にしています。
2. トークンを追加していくうちに、当初決めたトークン名のルールに不都合が出る
「2-2. 要素の順番を決める」で書いた要素はコンポーネントを解剖して書き出しました。
やりやすいように、最初は簡単なコンポーネントの解剖からスタートし、ある程度トークン名に必要な要素が見えてきた時に、トークンのリストアップに取り組み始めました。
ただ構成が複雑なコンポーネントの場合、細かい箇所はどうしたら良いか困っていました。
解決方法
トークン名の要素を柔軟に添削ができ、必要に応じて「用途・箇所」の要素を複数入れて細かい箇所を指定できるようにしました。
3. トークンが多く、実装時に適用漏れが発生
私たちはすべてのスタイルにトークンをつけて定義しているので、いくらプラグインで確認ができたとしても、実際に実装へ適用する際に漏れが発生することがあります。
解決方法
複数名デザイナーがチームにいるおかげで、全員で実装レビューを行い、適用漏れを極力防ぐように確認します。
また、レビューごとにミーティングを組むと大変になるので、Chromaticを利用して非同期のレビューを行っています。
Chromaticは実装前後の見た目を2枚のスナップショット画像を重ねて表示してくれるので、変化にすぐ気づきます。また、気になる箇所にコメントを残し、コメントが解決された後にレビュワーが承認すれば、GitHubのレビューが自動で通ることになります。
さいごに
デザイントークンの定義や運用には一定の方法論があると思います。ただ細かいところはデザインシステムそれぞれ実際の状況に合わせて考えなければならないと思います。
このnoteに書いた試行錯誤の例はほんの一部であり、私たちはまだまだトライアンドエラーの最中で、デザインシステム作りに力を入れています。
最後に、スキ❤️をポチッと押していただけると嬉しいです！
デザインシステムに取り組んでいるみなさん、ぜひ気軽に Twitter で声をかけてください！
宣伝です！
カミナシはプロダクトデザイナー/フロントエンジニアを絶賛募集しています。
気になった方はぜひカジュアルに話しましょう。