こんにちは、フロントエンド開発部の釜堀（@kamy0042）です。
この記事はChatwork Advent Calendar 2023の23日目...ではなく、デザインシステム Advent Calendar 2023の23日目です。
Chatworkでは職種横断的にチームを組んでデザイン基盤の整備を進めており、その活動にフロントエンドエンジニアとして関わっています。
現在、その一環としてデザイントークンの整備が進行中です。
そこで直面した課題と、それをどのように乗り越えたのかをお伝えできればと思います。
※同チームの守谷による記事も Chatwork Advent Calendar 2023にて本日公開予定です。そちらもよろしくお願いします！
デザイントークンとは
まずはデザイントークンの概要について軽く触れておきます。
W3CのDesign Tokens Community Groupでは、デザイントークンについて下記のように説明しています。
Design Tokens Glossary | Design Tokens Community Group
The single source of truth to name and store a design decision, distributed so teams can use it across design tools and coding languages.
A (Design) Token is an information associated with a name, at minimum a name/value pair.
For example:
・color-text-primary: #000000;
・font-size-heading-level-1: 44px;
要約すると、
- 設計上の意思決定に名前を付けてまとめた、唯一の信頼できる情報源であり、
color-text-primary: #000000;のように名前と値のペアで表したもの
がデザイントークンである、と言えそうです。
デザイントークンを整備する目的
意思決定をデザイントークンとして構造化するメリットとして「ユーザーに対する一貫性の向上」と「チーム内での共通認識の形成」の２つがよく挙げられます。私たちはその中でも特に、「チーム内での共通認識の形成」について大きな期待を寄せていました。
Chatworkは10年以上に渡って運用され続けてきたプロダクトであり、その間に諸々のUI改修も積み重なっています。
そのため過去のプロジェクトにおいては、色の利用方針についてのコミュニケーションコストが嵩むこともありました。
共通認識の形成によってその問題を解決し、デザインや実装を行う際、より本質的な部分に時間を割けるようにしたい...というのが今回の取り組みの目的です。
整備中に直面した課題
本題に移る前に、まずは着手前の状況について説明しておきます。
前提：着手前の状況
すでにカラーパレットが存在しており、そこで定義されている色を利用してデザインや実装を行っていました。
そこで、このカラーパレットをグローバルトークンと位置付けた上で、「グローバルトークンを参照し意味のある名前を持つトークン（セマンティックトークンやエイリアストークンと呼ばれるもの）」を新たに設計することにしました。
また、できるだけ素早く価値提供するために、「理想的なデザイントークンを設計する」のではなく「今の色の利用方針をトークンとしてまとめる」という方向性を定めた上で作業を開始しました。
どんな問題が起こったのか
デザイントークンを整備するプロセスとしては、現状のUIの把握と共通項の抽出が一般的です。
そのため、まずはUIから色使いの規則性を読み解いて意味合いを探ろうとしましたが、すぐに一筋縄ではいかないと判明しました。
課題１：規則性を読み解くのが難しい
いざ画面上の要素から規則性を読み解こうとすると、
- 背景色に複数のトーンが存在しており、何らかの基準でそれが変化している
- テキスト色が複数パターン存在し、何らかの方針に沿って使い分けられている
といった複雑性に直面しました。
デザイン時にはしっかりとした色設計が存在していたのですが、前提となるその内容を完全には把握しきれていなかったため、UI自体から規則性を探るのは非常に困難でした。
課題２：イレギュラーな利用箇所の存在
長年の改修が積み重なった結果、
- ボーダー用の色が特定のUIでのみ背景色として用いられている
- 特定のUIのみバックドロップの色が異なる
というように、当初の想定と異なる使われ方だと思わしき箇所が存在していました。
しかし、これらをイレギュラーとして切り分けるためには、そもそもの規則性を正しく把握する必要があります。
前述の通りそれが困難だったため、「間違っているように見えるけど、本当にそうなのか？」を判断できませんでした。
直面した課題をまとめると...
これらの課題をまとめると、色の意味合いを正しく抽出するためには
- 「現状の各UIにどの色を当てるべきなのか」を紐解き、
- その上でイレギュラーな色使いをミスなく判断し、除外する
必要がありました。
とてもじゃありませんが、一人のエンジニアだけで解決できる問題ではありません。
どのように解決したのか
Design Tokens Community Groupが
The single source of truth to name and store a design decision,
と定義しているように、デザイントークンとは「設計（デザイン）上の意思決定に名前をつけて保存するための唯一の信頼できる情報源」です。
要するに、デザイントークンは「UIに関する設計者の意図を構造化したもの」だと言えるでしょう。
つまり、正しく構造化を行うためには、デザイナーを交えた設計意図の議論も必要だということです。
今回行った「現状のUIの把握＆共通項の抽出」は、あくまでも意図を構造化するための手法の１つです。
構造化を進めるための重要なプロセスではありますが、 私たちが置かれた状況を考えると、デザイナーを交えた議論に比重を置くべきでした。
にも関わらずプロセスそのものに捉われたため、本来やるべきだったことに対して少し遠回りとなってしまいました。
最終的に行ったこと
最終的に行った施策を一言でいうならば、地道なヒアリング作業です。
- 色の利用箇所を洗い出す
- 洗い出した結果を元に、ミーティングの議題として下記をまとめる
- どんな方針でその色が使われていそうか
- イレギュラーな色使いだと思われる箇所
- チーム内のデザイナーへのヒアリングを行い、まとめた内容が妥当か、考慮漏れが無いか等を一緒に考え、色の利用方針を言語化する
という泥臭い作業を、カラーパレットに存在する色ごとに１色ずつ実施していきました。
その分工数はかかりましたが、デザイナーとエンジニアが共同で設計意図を明確にするというのは、「チーム内での共通認識の形成」という目的において欠かすことのできない工程であったと思います。
最後に
今回は手法に捉われて「設計者の意図を構造化する」という基本を失念していましたが、結果的にはデザイナーを交えた議論によって設計意図や色の利用方針を言語化することができました。
プロダクト開発においては、デザイナーやエンジニア、マーケティングといった職種間の認識が揃わないことがよくあります。
その分断を埋めて同じ認識のもとでプロダクトを見るためには、今回の事例の様に職種間での密接なコミュニケーションが必要となります。
そこで得られた「なぜその設計になっているのか」という意図を参照可能な形で残し、開発時に活用する流れを作れば、全ての職種間で認識を揃えるためのガイドラインとして活かすことができるでしょう。
このように、
- 設計意図やデザイン言語といったデザインの基盤をまとめ、
- それを開発に活用できるように組織＆運用体制を構築する
ことが、デザインシステムを作るということではないでしょうか。
デザインシステムという概念はデザイントークンやコンポーネントライブラリとしての側面に着目されがちです。
しかし、それらのアウトプットに捉われると本来の目的や意味を見失うことになります。
デザインシステムが持つ「皆が設計を理解し、同じ目線でデザインを見る=認識を揃えるための仕組み」という役割を忘れないようにしたいです。
