デザインシステムへの取っ掛かりに関するメモ

プロダクト開発の初期フェーズで、デザイナーが1人しかいない場合は良いものの、複数のデザイナーが関わるようになると、一定の決まり事が必要とされる。

もし、それらを定めずに無秩序にグロースを進めた場合、一貫性のない見た目や動作が蔓延し、ユーザーにとっても、開発者側にとっても不利益が生じる。

一貫性のないプロダクトは、ユーザーに不要な学習コストを強いる。目的のコンテンツへのアクセスに時間がかかったり、スムーズにタスクをこなすことができなくなる。開発者に対しては、余分な判断コストを強いる。ひとつの機能を追加する度に、どのようにアプローチすれば良いのか悩み続けることになる。

これらの課題に対するアプローチとして、デザインシステムへの取り組みが業界内で巻き起こっている。重要なのは、前述したような「そもそもの課題」の文脈が失われ、「デザインシステムを作ろう」とすり変わる手段の目的化に陥らないことだろう。

デザインシステムという言葉の取り扱いは、ひと昔前の「UX」と同じくらい、注意しなければならない。一時的なプロダクトの使い勝手（ほぼユーザビリティと同義）を指してそう呼ぶ人もいれば、プロダクトに限らないサービス全体のタッチポイントから得られる体験を指してそう呼ぶ人もいる。

故に、デザインシステムを作ろうとするのではなく、どんな課題を解決したいのか、そのためにどんなアプローチを取るのか。このように考える中で、世間で言われるデザインシステムへの取り組みを事例としてどう参考にするか、と捉えた方が良いだろう。

次に、デザインシステムの構成について考える際には、会社として目指す方向性がヒントになる。例えば、業界や性質の異なるプロダクトを並行して立ち上げるのか、シナジーを持たせながらひとつのブランドの中で展開させていくのか。

前者であれば、ある程度の裁量を個別のプロダクトに委ねる形になるかもしれない。後者であれば、中央集権的な構造になるかもしれない。もちろん、ゼロかイチかという極端な話ではなく、このレイヤーまで（例えば思想的なところ）は全てのプロダクトに共通するが、表層のスタイリングは個別のプロダクト毎に定める、といったハイブリッドな形もあり得るだろう。

決まった正解のあるものではないので、他社の事例をそれっぽくなぞるだけではなく、当事者が現場の状況に応じて導き出すことになるだろう。

どこから手をつけるか、という観点では、トップダウンとボトムアップの2つのアプローチが考えられる。
トップダウンの場合、最も抽象度の高い原則等を定め、そこから具体に落としていく。ボトムアップの場合、コンポーネントをまとめたり、具体から積み上げていき、徐々に抽象度を上げていく。

何となく、あるべき姿から全体像を作っていくような、つまりトップダウンのアプローチの方が理想的であるように見えるかもしれない。しかし、結論から言えば、ボトムアップのアプローチの方が失敗はしづらい。

デザインシステムをプロダクトと同じように考えてみると、まずは解決したい課題を、最もミニマムな形で解決できるMVPを作ってみると良いだろう。初めの内は、ただのコンポーネントのリストに過ぎないかもしれない。しかし、最小限でリリースすることで、運用上の課題を早く検出して、使い勝手を改善していくことができる。

一方で、トップダウンのアプローチを採用すると、それこそ手段の目的化に陥りやすい。例えば、ミーティングを開催し、多くの時間を費やしてデザイン原則を定めたものの、ステークホルダーに説明できるような分かりやすいアウトプットはその時点ではまだ完成していない。プロジェクトに持続性を持たせる上では、アカウンタビリティの観点でもやや難易度は高まってしまうだろう。

世間で言われるところの、綺麗なデザインシステムを作ろうとしなくていい。まずデザイン原則がなければならない。コンポーネントが綺麗にまとまっていなければならない。トークンはこのように定義しなければならない。そうした「こうでなければならない」は、実は手段の目的化に陥るシグナルでもあるのだ。

まずは、どんなに小さくてもいい。課題を解決する何かを作り、リリースして運用してみよう。そこから徐々に、理想に近づけていけばいい。

ちいさくはじめるデザインシステム