デザイントークンを導入した話
こんにちは！hacomonoプロダクトデザイナーのなつい もえこ（@moeko_n）です。
最近グンと寒くなり、市販の鍋スープの食べ比べにハマっています🍲
だいたい1袋3〜4人前と記載がありますが、夫婦2人で余裕で食べきってしまうのは我が家だけでしょうか。。おすすめの鍋スープあったら是非教えてください〜！🙏
さっそく本題ですが、以前より取り組んでいたデザイントークンの定義が概ね完了しました！
今回はhacomonoでのデザイントークンの定義について、決定までのフローと管理方法をデザイナー視点でご紹介できればと思います。デザインシステム構築を検討している方に、少しでも参考になれば嬉しいです。
デザインシステム導入の経緯・背景については前回の記事や、しまさんの書いてくれた記事にまとまっているので、気になった方は是非ご覧ください。
デザイントークンとは
カラーや余白の値など、UIデザインにおける最小の単位を共通言語として定義したものです。今回詳細の説明は割愛します🙏
参考：
体制と方針
エンジニア4名・デザイナー1名で約3回のMTGを実施し、トークン構造について議論を進めていきました。
hacomonoではデザイントークンやコンポーネントの利用ルールがほぼ無かったため、まずは規則と仕組みを整える方針でトークン構造を検討しました。
1. 構造を決める（トークンタイプ）
以下のようにトークンの種類を分類することにしました。
Global token
Alias・Specificトークンの参照元になるトークン。プロダクトで利用可能なすべてのスタイルが定義される。
blue-800、red-10のように利用可能なカラーをパレットとして用意している。
Alias token
実際にUIに利用するトークン。役割が割り当てられている。
defaut、linkなど、利用箇所と役割が明確になっている。
Specific token
特定のコンポーネントに利用するトークン。
利用箇所が限定的な場合に定義される。（1ページのみで利用する、または、特定のドメインに依存する場合…など）
2. 構造を決める（トークン命名規則）
トークンを読み解いたり、トークンの新規追加を行う際に命名規則も必要です。 MaterialDesignなど他社を参考に、以下のような分類を設けて命名規則を作ることにしました。
① Type
上記のトークンタイプ（例：alias、global、specific）
② Property
定義するトークンの名称（例：font、color、spacingなど）
③ Modifier
globalであれば値そのもの、aliasの場合はサイズ・太さ・状態など…Propertyを修飾する詳細情報。
Specific tokenについては、特定の要素を指す「Object」という概念が①と②の間に表記されます。Figmaバリアブルの管理のしやすさからこのような運用に決定しました。
ちなみに、Figma開発モードのInspectでバリアブルの値がハイフン（-）つなぎで表示されることもあり、これを踏襲して「-」でつなぐ記法ルールとしています。
ちょっと余談
hacomonoでは、Figmaのバリアブル・ローカルスタイルを自社開発のFigmaPluginでGithubにPushする仕組みを想定してトークン構造を検討しています。
（いつか開発担当者がPluginの記事を書いてくれるはず…..🙏）
Tokens Studioなど便利なPluginもあると思いますが、hacomonoでは以下の理由から上記構成を採用しています。
バリアブル運用が軌道に乗ってきていたので運用を変えるのにコストがかかる
Figma Plugin開発に前向きなエンジニアメンバーがいた
サードパーティー製の機能を使うことのリスクが未知…
3. トークン仕様を決める
トークン構造・命名規則が決まった後は、各トークンの仕様定義を行いました。
hacomonoプロダクトはお客様の日々の業務に利用いただいているため、大幅デザインリニューアルとすると社内も顧客もそれなりにコストがかかります。
さらなるUI負債を生まないことを目的に、まずはデザイントークンの運用を開始することに重きを置き、現行で使われているスタイルを整理する方針でトークン仕様を決めていきました。
① 現状調査・他社調査
まず、カラーや余白など…現状プロダクトで利用されているスタイルの洗い出しを行いました。
どこに使えるトークンなのかをわかりやすく命名する必要があったため、それぞれの色や余白の利用箇所を整理したうえで、現状のスタイルのカテゴリ分けをしました。
同時に、現行のUI課題をできるだけ解消したいと考え、課題を洗い出して分析し、UIデザインの改善を踏まえトークン整備を行いました。
② ドキュメント作成
現状調査・他社調査からある程度定義に含めるトークンが明確になったら、ドキュメントに起こしていきます。UIに実際に利用するAlias token（役割が明確化されたトークン）ベースでまとめています。
この際、トークンについてのドキュメントが網羅されていた Spectrum、Atllasian、Primer あたりをかなり参考にさせていただきました。
③ Figmaへのデータ登録
hacomonoではFigmaのバリアブルとローカルスタイルを用いて管理する方針としているため、ライブラリファイルにトークンの登録が必要でした。
トークンの命名ルールに合わせて、画像のように設定しています。
いままではエンジニアとデザイナーで分断してライブラリ管理を行っていましたが、プロダクト共通のトークン構造を意識したバリアブル構成に組み換えました。
この際、Alias token・Specific tokenにはすべてスコープの設定も行っています。
ざっくり以上の流れで、約1ヶ月半程度でトークンの構造と仕様の検討を行いました。並行して、コンポーネントの仕様検討やプロダクトの機能開発等も行っているため、トークンの変更・追加の要望があれば柔軟に調整を行っています。
都度実装も修正いただく必要がありますが、トークン運用が軌道に乗るまでは調整はつきもの…というマインドでゴリゴリ運用を開始してみています。
苦労した点
私自身初めてのデザイントークン検討だったため、壁にぶつかることも多かったですが…特に苦労した点を2つあげてみます。
① エンジニア、デザイナーの知識差の埋め合わせ
Figma→GithubにデータPushする構成を検討していたのですが、「Figmaでは実現出来ないが実装では実現できること」があることに気づき、度々議題をあげることがありました。（現時点でborderのライブラリ管理はFigmaでは管理出来ないが、実装ではできる…など）
自分自身コーディング経験はあってもトークン定義や管理を行った経験は無かったので、実装構造を把握した上でFigmaの機能説明を行うなど、難しいことも多かったです。
回り道だったとしても、実装観点でわからない部分はしっかり伝え、まめにコミュニケーションを取ることが双方納得感のある議論に繋がると感じました。
② 運用中プロダクトのトークン定義
先の文中でも述べたとおり、運用中プロダクトならではの制約があったため、現状のUIパターンの把握と整理が必要でした。
利用されているUIパターンの抽出をエンジニアにお願いすることもありましたが、プロダクトの画面数が多いため現状把握にはかなり時間を要したと感じます。
とはいえ早く定義を進めて運用を回したかったため、時間を決めて調査したり、調査画面を主要画面に絞ったり…など調整を行い、できるだけ作業時間が削減できるよう工夫しました。
デザイントークンを導入してみて…
エンジニアと密にコミュニケーションとりつつ進行するなかで、自身の実装・Figmaの知識がアップデートされ、モチベを維持しつつ楽しくトークン検討を進めることができました！
ただ定義して終わりではなく、より使いやすく品質担保しやすいデザインシステム構築を目指して、日々改善を重ねていけたらと思います。
いまは、デザイントークンを利用してコンポーネントの仕様検討も進めています。コンポーネント仕様決定までのプロセスなどもいつか記事にできたらいいな…💪
さいごに
株式会社hacomonoでは一緒に働く仲間を募集しています。
採用情報やhacomonoプロダクトデザインチームの詳細もぜひご覧ください！