デザインシステムに失敗する方法
デザインシステムを導入、運用する上で失敗しがちな例とその対策について。いくつかの現場で実際に起きたことを元にして書いています。Abnbの記事を読み直していて思い出したことのメモです。
ここでのデザインシステムとはwebやアプリケーションなどのプロダクトを中心にデザインに用いるパターンや要素を再利用可能な形で標準化したもの、くらいの意味です。ブランディング、タイポグラフィ、色、コンポーネント、写真、イラストや装飾、ライティング、レイアウトやナビゲーションなどデザインパターン、その他諸々を対象とし、ガイドラインやアセット（Sketch ファイルとか）、実装（CSSやコンポーネント）などを通じて運用されるものです。
パッと見、正義にしか見えないデザインシステムですが、実際に運用するとなると色々と大変です。制作や管理にかかる工数を冷静に見積もることはもちろんですが、それ以外にもチーム間のコミュニケーションなどで人間関係や心理的な困難に突き当たることもよくあります。思い出せる限りでいくつか失敗パターンを思い出してみます。
上流vs下流
デザインシステムを作る時にはどうしてもシステムを作る側が上流工程で、それを適用する側が下流工程に見えてしまいがちです。ある程度その通りなのですが、適用する側のデザイナーから見ると自由度を制限されているように感じたり、自分がただ工程に添って作業をするだけのポジションにいるように感じられてしまい、それを上下関係、一軍と二軍のような関係として捉えてしまうというパターンを何度となく目にしたことがあります。
最悪の場合デザインシステムがどこか手の届かないところで作られて、自分のところに来た時にはもう直せない、上から与えられたもののように感じられてしまいます。
これはよく考えると逆で、デザインシステムは個々のチームから余計な仕事を取り除き本質的な問題に注力できるようにする、後方支援的な役割です。具体的なプロダクトに集中することと、プロダクトを横断して見ることは単に異なる機能であり、どちらが上ということはありません。あとデザインシステムはなくても死なないけど、プロダクトは出さないと会社が死んでしまいます。
個々のチームにとってはそれが上から降ってくるものではなく、自分たちのニーズを踏まえて手伝ってくれるパートナーと一緒に作り上げたものと感じられるのが理想です。
システムが役に立たない
身も蓋もないですがたまにある話です。システムを作るときに実際に使うプロダクトの実態を把握できていなかったり、検証とフィードバックのプロセスがうまく設定できていないと実際の現場で扱いに困るものになりがちです。後述しますがパイロットとなるプロジェクトをいくつか決めて開発を進めると現実に起こる問題を的確に抑えるのに役に立ちます。
デザインだけで実装のリファレンスがない、というのもよくある罠です。これはプロジェクトによるかもしれませんが、デザインシステムはコードレベルでライブラリとして実装されているべきだと思います。Sketchファイルを元に個々のエンジニアが実装しているような状態だと変更やメンテナンスが崩壊します。また、ドキュメントだけのコミュニケーションには正確さに限界があります。実装者や個々のデザイナーの解釈がブレる余地を残さないためにも、コンポーネント類は実装を最も信頼できるリファレンスとするのがお勧めです。GoogleのMaterial Designなど規模の大きいシステムではデザイナーの数よりもエンジニアの方が多いことも多々あります。
導入の仕方を合意していない
既存のデザインや実装を新しいシステムに置き換えるには時間と労力がかかります。実際のビジネスを担うチームは他にもリリースしたい機能や改善したいUX案件を多数抱えています。デザインシステムの導入にどれくらいのコストが必要なのか、部分的に乗り換えられるのか、スケジュール的にいつが適当なのか等々がうまく合意できていないとプロダクトチームのPMに煙たがられりします。
解決策
実際の解決策は臨機応変になることも多いのですが、やっておいたほうが思うことを挙げておきます。
プロダクトチームとのパイプを作る
当たり前ですが実際にシステムを使う人を仲間に入れることが大事です。
1. 最初にヒアリングを行う。既存のプロダクトについてのブリーフィングとデザイン資料の共有をお願いする。
2. 進捗確認と共有の意思決定の仕方などプロセスについて大まかに合意しておく。
3. 可能なら各チームからシステムのデザインに参加してもらう。長期には難しくても1週間くらいのスプリントなら大抵協力が得られます。
テストケースとパイロットにするプロジェクトを決める
システムをデザインする際にテストケースにする画面などを決めておきます。各プロダクトからそれぞれ重要な画面と特徴的なUXなどを選び、デザインシステムの検証に用いるようにします。
また、一度の複数のプロダクトにシステムを適応するのではなく、何か一つパイロットにするプロダクトを決めて、そのチームと一緒にシステムとプロダクトを一緒に作るというのも一つの手です。システムを作って上から落とすのではなく、プロダクトチームと一緒に作り上げる。そこでの結果や実装を整理してリファレンスとしてまとめて他のチームにも順に適用する。現実に基づいた実用的なデザインができ、現場での導入や運用などの知見も得られるのでお勧めの方法です。そのプロダクトに変に最適化してしまわないよう、レビューなどのプロセスで気をつける必要はあります。
システムチームからプロダクトチームに人を出す
導入時にはシステムチームからプロダクトチームに人を出すのも良いアイデアです。使ってもらえるようお願いするだけではなくて、実際に人を出して手伝いながら導入する。上記のパイロットプロジェクト同様にシステムチーム側に現場ベースの深い知見がたまるのもメリットです。
モジュール化する
デザインシステムはできるだけモジュール化して、必要なところだけを取り出しても機能するようにしておくべきです。システムとしての全体的な生合成や統一感も重要なのですが、100%乗り換えるかそれとも元のデザインにするかの二択になってしまうと多くのプロダクトで導入のハードルが高すぎることになります。
最初から完璧を目指さない
どんなデザインシステムでも必ず定期的な調整が必要になります。80%を100%にする努力よりも、早期に導入することとメンテナンスしやすい仕組みを作ることに力を注いだ方が吉です。ただし、多くの場合は導入時のインパクトや話題性なども重要なことが多いので、作り込むべきところは作り込んでおくことも大事です。取捨選択。
以上
ざっと殴り書きでした。