この記事は弁護士ドットコムAdvent Calendar 2022の10日目の記事です。 昨日は@mmorinoさんでした。
デザインリニューアルのその後
弊社ではtoC向けのサービスサイトを2018年から漸進的にリニューアルしてきました。
いまもまさにサービスを提供し続けている「生きたプロダクト」に手を入れていくプロセスというのはなかなか難しいものでして、見た目やコードが綺麗になったからといって、それで仕事が終わったことにはならないものです。
リニューアルという仕事自体はよく行われることですが、サイトのリニューアルをすると一口にいっても、見た目も含めて一気に刷新するのか、それとも改善を積み重ねていくようなやり方をするかの判断で迷ったことがあるという制作担当の方は割と多いのではないでしょうか。
2018年にスタートした弊社のリニューアルは、ページ単位で部分的に手を入れる形を取りつつも、見た目については一気に刷新する方針を取りました。その方法のむずかしさを予見していたからこそ、ユーザビリティやアクセシビリティを事前に慎重に検討したうえで、何度も何度も社内でレビューを重ねてリニューアルを進めました。その結果、一部のページで大きな成果を出すリニューアルを達成できたのでした。
ところが、リニューアルを進めていくうちに当初想定したデザインでは対応が難しいページも出てくるようになってきました。それもそのはずで、一つのサイトといっても読み物的な役割のページもあれば、検索などの機能を提供するページも存在します。
さらに仮定を広げるならば、ユーザーが求める体験自体が変わったり、そもそもサービスを使う対象ユーザーが変化することだってあり得ます。常に最適解は一つではないのです。
こうして、リニューアルの道半ばにして、ユーザーが快適にサイトを使うためのUI/UXの最適解をさらに模索するため、デザインのアップデートをもう一段階行うという機運が持ち上がったのでした。
機動性と安定してスケールすることの両方を満たせるか
UIをアップデートしたいという要望は出てきたものの、UIのどこに具体的な課題があるのかは当初は漠然としていました。
それもそのはずで、リニューアルしたUIはユーザビリティ上の要求は一定以上のクオリティを満たしていて、これといって大きな欠点はありません。どこをどう軌道修正するかはUXとセットで緻密に検討する必要がありそうでした。
そこでまずはインターフェースインベントリを実施し、「機能」と「役割」にポイントをおいてUIを整理し直しました。
そして、ユーザーが最適な体験をするためには、どれくらいの段階の見た目の強弱の変化や見せ方のバリエーションが必要かなどを総合的に再検討し、カラースケールやフォントサイズのスケールまで立ち戻って見直しを計りました。
こうしたプロセスで一定の方向性は出したものの、今回デザインのアップデートを検討することになった背景を考えると、デザインの軌道修正というものは「そもそもあるものだ」という前提にしておきたいのが人情というものです。
そこで、これを期に「いつか導入したい」と考えていたデザイントークンをデザインシステムに組み込むことにしたのでした。
デザイントークンに取り組む意義
頻繁な軌道修正を見越して、デザイントークンを導入しようとした理由はいくつかあります。一つはAdobe Blogのデザイントークンの記事でも触れられている「変更のしやすさ」です。
スタイルを扱う際、デザイナーは数値を直接指定することも、デザイントークンを使うこともできます。全体のスタイルが時間の経過と共に変化したり進化したとき、数値を直接指示していた場合は、デザインを修正するたびに個々の値を人手で変更することになります。
一か所の値を更新するだけなら楽かもしれませんが、現実のプロジェクトでは、ブランドのカラーやタイポグラフィはさまざまな異なるパーツに使用されています。それらをすべて人手で調整するのは時間のかかる作業ですし、とある要素への変更を忘れたために、デザインに一貫性が無くなることも起きがちです。トークンはこうした問題を解決してくれる手段です。
※出典：デザイナーと開発者の連携を効率化するデザイントークンとは何か？ | アドビUX道場 #UXDojo
しかし、これだけだと変数の運用との違いがあまりわかりませんね。
私は、この「変更のしやすさ」と掛け合わせることで価値が最大化するデザイントークンのもう一つの特性こそに大きな意味があると考えています。
それは、デザイントークンに「デザイン上の意思決定を伝達する機能」を持たせるという側面です。
では、「デザイン上の意思決定を伝達する機能」とは具体的にはどんなものなのかを考えていきたいと思います。
「デザイントークンって変数と何が違うの？」と言われつつ
前節でも触れましたが、デザイントークンに取り組みたい、となったときによく上がってくる疑問が「デザイントークンって変数と何が違うの？」というものです。
「デザイントークン≠変数」である、そこを理解するのはそう難しいことではないと思います。しかし、「なぜ『≠』なのか」を咀嚼するのは少し難しいかもしれません（少なくとも私はそうでした）
デザインシステムの海外事例としてお馴染みのLightning Design Systemをはじめとして、誰もが知ってる企業のデザインシステムに携わってきたJina Anneさんのこのツイートはとても示唆的でした。
「Design Tokens are a methodology（デザイントークンは方法論）」というのは本当にそうで、うまく作ると設計やプロセスにいい変革をもたらしてくれます。
けれど、あくまで方法論なのです。自分達のプロダクトの特性に合わないトークンを乱暴に持ち込んでも、あまりいい結果は望めません。
それをやっと実感できたのは、トークンのアーキテクチャを構成する段階でした。その段階に進むまでは「デザイン上の意思決定を伝達する機能」については、自分の中でほとんど見えてきていないというのが正直なところでした。
そもそもトークンってなんなのか？
「デザイントークン≠変数」。それはつまり、デザイントークンは変数と違う機能を持ってるということです。では、変数にはなくて、デザイントークンにはある機能とはなんでしょうか。
私は、今日までの取り組みの中で、一旦デザイントークンは「特定の文脈におけるデザイン上の意思決定を表現したもの」だという風に理解しました（「一旦」というのは、今後もデザイントークンを使っていくことで自分の理解が発展していく予感がしているためです）。
変数だって意思決定が現れているじゃないか、という場合もあるでしょう。そうしたケースもあると思います。想像ですが、その場合は必要性があって変数名にトークン的な役割をつけたのだと思います。デザイントークンとして作った訳じゃないけれど、そうした機能性を求めていたからこそ、変数がそのような形で運用されたのではないでしょうか。
その実態がトークンと変数の境界を曖昧にしてしまう正体なのではないかと…勝手に考えています。
ちなみに、そもそものトークンとは
（まだ文字が使われているという証拠のない時代）から、文字が日常使われるようになる時代まで、最初メソポタミアで、その後様々な地域で使われていた、農産物など、生産されたアイテムを数え記録する時に使われた一種の道具のこと
※出典・参考：JT生命誌研究館 – Token:文字誕生の原点
といった背景があるものだそうです。
語源を辿るとその本質は「道具」としての機能に根ざしているものですが、私たちは「文字」や「言葉」を使い慣れてしまっていて、トークンを「文字」を使って容易く表現できてしまうので、トークンの持つシンプルな本質の部分がぼやけてしまうのかもしれませんね。
つまり、「何か」を文字を使って「定義する」こと自体はトークンの本質ではなく、「何か」をトークンを使って表現することで「道具として用いる」ことが本質なのではないでしょうか。
デザイントークンならば「デザイン上の意思決定を伝達する機能を表現したもの」を「用いる」ことが本質、と言えるかもしれません。
さて、このあたりで言葉の定義は横におき、どのようにトークンを整備していったかの具体的な事例をご紹介します。そう、トークンはなんと言っても「道具」なのですから。
なぜ何種類もトークンを作るのか
最初の方で述べた「機動性と安定的にスケールすることの両方を満たせるか」は、今回のアップデートにおいて外せない要件です。そして、弊社のプロダクトの特性としては、下記のような特徴が挙げられます。
- サイトの規模が大きい（そのうえさらにさまざまな機能要求を包摂している）
- 機能改修を高頻度で行いたい
これらの特性を満たすためには、「安定」と「拡張性・機動性」の両面に対応できるデザイントークンの設計が必要です。
先行して実装したCSS設計の際にはFLOCSSをベースに一部ITCSSのアイデアも持ち込んで、基盤となる層（広範囲に利用できる普遍的なパーツ群）と試作的な層（命名ルールでカプセル化して限定的に用いるパーツ群）の両方を担保できるような構造化を行いました。
デザイントークンについても、これに近しい構造を設定しました。プロダクトの特性を理解して構造化することで、普遍的な抽象度のレイヤーは開発の安定を担保し、個別のコンポーネント向けのレイヤーは開発の拡張性と機動性を担保することに寄与してくれました。
こちらは実際に作成したグローバルトークンとエイリアストークンです。
エイリアストークンはその命名の中に使用の文脈を包摂していますが、それでいて汎用的なコンポーネントに広く利用できる抽象度にしてあります。この抽象レベルがトークンの汎用性を大きく左右します。
エイリアストークンについてはある程度の汎用性を確保したかったので、個別の指定をしたい場合はコンポーネントトークンで…という風に責務を分割しました。そのおかげで、開発の柔軟性は担保しつつも、汎用化したい部分についてはちょうどいい抽象レベルを保つことができました。
なお、弁護士ドットコムのデザインシステムではFigmaのプラグイン Figma Token （※）を使ってトークンを定義しているため、グローバルトークンの値をエイリアストークンが参照する形になっていて、グローバルトークンを更新するとエイリアストークンも更新されます。おかげでFigma上のトークンの管理も構造を踏まえた形で担保することができました。
※今のところはとても快適にFigma Tokenを使っていますが、W3Cの「Design Token Community Group」がデザイントークンのフォーマットについての仕様を標準化する動きを進めているため、今後はその標準化に沿ったプロダクトを選択し直すことになるかもしれません。Figma Tokenが標準化に準じてアップデートされることを願っています。
デザイントークンがもたらした世界
喫緊の課題に対処すべく導入したデザイントークンですが、その汎用性の高さゆえにほかのプロジェクトの立ち上げに使われたり、他部署で参照されたりすることになったりと、思いがけない収穫が生まれつつあります。
ここまでは「そもそもデザイントークンとは？」といった抽象的な話題が中心になってしまいましたが、実際にデザイントークンを導入する際には、機動性を重視するためにできる限り運用の負荷を下げる実務的な工夫をしました。
具体的にはFigma TokensとStyle Dictionaryの連携、そして、GitLab連携やStorybook連携を推し進めて、1つのソースでデザインファイル・コード・ドキュメントを一括管理すること目指したのですが、それらの利便性もデザイントークンのチームを越えたスケールに大きく貢献してくれています。
その実務面のお話は13日の@_shellmeさんの記事でさらに具体的にご紹介させていただきたいと思いますので、ぜひそちらもあわせて読んでいただけるとうれしいです。
最後までお読みいただき、ありがとうございました。明日は@talogさんです。