デザインシステムを作る前にデザインのシステムを理解しよう

デザインシステムという名の成果物が抱える問題

デザインツール上で UI コンポーネントを並べただけでも『デザインシステム』と呼ぶくらい言葉が広まった今日。2017年に記事にした頃と比べると随分変わったという印象があるものの、デザインシステムと成果物が密接になり過ぎていると感じることがあります。

デザイン組織の成熟度に合わせて施策を変えるべきだと思いますが、事例を検索をしたり書籍を読むと、Lightning Design System や Carbon Design System のような完成されたものが出てきてしまいます。こうした状況だと「デザインシステムを作る」目的が上記のようなサイトを作ることになってしまう場合あります。つまり、デザインシステムとは完成された何かを作り上げることが目的になっているわけです。

足元を見ないで理想を作り上げようとしていないか

事例で見かけるようなデザインシステムを作ることを目的にしてしまうと、見た目はそれっぽくても誰も使わないものになりますし、コストと時間の浪費になるだけで次へ繋がりません。

こうした問題は、大きな目標だけ掲げてしまって足元にある課題を見ていないときに発生します。チーム内で「良いデザイン」の意味が共有されていない状態でデザインシステムという『型』を作っても意味がないわけです。自分はデザインシステムという言葉と事例に出てくるような成果物を結びつけるのは危険だと思っていて、案件でもそもそもの課題を紐解いて施策を提案・実行するようにしています。

願わくば 5 年後に事例のようなものが作れたら良いよねというくらいの遠い目標にして、まずは足元を固めるための施策をスタートするほうが良いでしょう。そのためにまず、組織におけるデザインのシステムを理解することから始めます。

現存するシステムを理解する

デザインのシステムとは、プロダクトという成果物を作り上げるために関わるあらゆる要素と関係のことを指します。デザイナーがデザインツールと向き合っていれば完成するわけではなく、様々な要素が密接に絡み合ってモノが生まれます。下図はデザイナーが関わるところを中心にシステムを簡潔にまとめたものです。

下記のような質問をすると、それぞれの組織がもつデザインのシステムの理解が深まります。

• 他部署（又は異なる専門家）とどのようにコラボレーションしているか
• プロダクトチーム内の関係性は良好か
• PM やビジネスサイドの方とどのように意思疎通を行なっているか
• プロダクト開発の優先順位はどのようにして決められているか
• どのように意見や視点を合わせているか
• チームが考える『品質』とは何か
• 良いデザインの判断基準は何か
• ドキュメンテーションや共有素材はあるか
• それらはどのように運用・管理されているか
• どのような技術やサービスを使ってプロダクトが作られているか
• 開発フェイズに入るまでにどういうステップがあるか

理想形と言われるデザインシステムは、上記の課題を何かしらの方法で解決しているケースが多い印象があります。組織に根付いているシステムを考慮せずにデザインシステムという成果物を作ることへ大きくジャンプしても落下（失敗）してしまいます。

デザインシステムを「コンポーネントライブラリと詳細度の高いガイドライン」という固定概念を拭い去り、「組織におけるデザインのシステムを改善する取り組み」と捉えるとやり方は大きく変わります。

例えばデザイン原則は作ったけど「良いデザインの判断基準」が人によってあやふやという課題があるとします。原則の解説だけでなく、それを活用したデザインフィードバック会を開くのも良いですし、会議室に原則ポスターを貼るのも手段です。こうした活動が、デザインのシステムの中にある「判断基準」の解決につながります。「どのツールを使って公開したら良いだろうか」を議論するよりずっと生産的ですし、効果も実感しやすいです。

デザインシステムを作る目的はプロダクト開発の貢献であって、カッコいい成果物を作ることではありません（雇用やブランディング目的だと話は別ですが）。素敵な事例は横目に見ながら、解決しなければならない課題に目を向けなければいけません。「一貫性のある UI が作れるようになる」ためにコンポーネントを揃える前に、一貫性がない状態が生まれた要因を見つけ出すことが先決です。それぞれの組織がもつデザインのシステムの中にきっと隠れているはずです。