デザインシステムは最優先にはならないです

どちらかというと優先順位は低めです

デザインシステムの必要性を説く時代は終わりましたが、その利用促進や運用継続は容易ではありません。デザインシステムの構築者とプロダクト設計者が同じ人物であるような小規模組織では、ガバナンスの課題は些細なものばかりです。また、コミュニケーションが活発な小さな開発チームなら、メンバーのモチベーションが続く限り、維持・管理は比較的容易です。

組織が大きくなり、様々な体制やプロセスを持つ複数のプロダクトが存在する場合、全員一丸となってデザインシステムを取り組むのは難しくなります。その結果、「作る側」と「使う側」に分かれがちです。この問題を解決するため、各プロダクトから代表者を集めて議論する連邦制のような体制が考えられます。しかし、デザインシステムへのコミットメントを本業と両立させるのは容易ではありません。

プロダクトの開発と改善に集中しているチームにとって、デザインシステムの適用は二の次になります。彼らは限られた時間の中で、ユーザーニーズに応える方法を日々模索しています。一貫性のあるインターフェイスは、開発効率の向上やユーザーの学習コストの軽減に繋がるため、理想的です。しかし、既存のプロダクトを見直し、デザインシステムを適用する時間がないことも珍しくありません。現場のニーズに応えることを優先せずに、一貫性に力を入れる人もいないでしょう。

デザインシステムを通じて、一貫性のある利用体験を提供することは可能です。しかし、その道のりには多くのハードルが存在します。学習コスト、プロセスの改善、技術スタックやツールの見直し、品質管理など、従来の方法を見直し、新しい仕組みを定着させる必要があります。また、デザインシステムが提供するUIのスタンスや保証範囲を周知させることも容易ではありません。プロダクトそのものの改善より優先順位を上げて、こうしたハードルを超えてまでデザインシステムを使いたいと思えるでしょうか。

デザインシステムを作る側が、現場の優先順位や定着に伴うペインを理解せずに進めると、結局のところ「作る側」と「使う側」の溝は深まる一方です。UIライブラリの充実や辞書のようなガイドラインの作成をしても、かえってデザインシステム普及の妨げになります。

あなたの組織にとってのデザインシステムは？

「デザインシステムとは何か？」との問いに対し、多くの人はUIライブラリ、デザイン原則、ガイドライン、実装コンポーネントなどを挙げるでしょう。参考書にもそう記されていますし、私自身、そう説明したこともあります。しかし、このような定義に捉われ過ぎると、実際の成果や効果と結びつかないデザインシステムを作りがちです。その結果、デザインシステムを作りたい人たちが、作りたいものを作っただけになります。

数年前、デザインシステムの構築支援を求められた案件で、私は全く異なるアプローチを取りました。その組織にはデザインのレビュープロセスや、「どうしてその見た目にしたのか」というドキュメンテーションがなかったためです。自分たちにとって良いデザインとは何か明文化できない状態で、UIライブラリやガイドラインを作るだけでは、根本的な問題を解決できないと考えたためです。

デザインシステムを作る前にデザインのシステムを理解したほうが良いのも、コンポーネントを揃えること以外に、効果に繋がる課題領域があるためです。チーム間のコミュニケーションがうまくいっていないなら、デザインシステムチームが繋げ役という位置付けでサポートを充実させるほうが、利用を増やすキッカケにもなります。

デザインシステムを作り始めた当初は高いモチベーションがあっても、利用率が徐々に低下し、プロダクトの改善サイクルについていけなくなる「負のサイクル」に陥ることがあります。この状況は、全員がデザインシステムを優先して使うだろうという誤った想定と、現場にある課題やニーズを見落とし、定義に固執してしまうことが原因で負のサイクルが加速することがあります。このような状況を避けるためには、「私たちにとって本当に必要なデザインシステムとは何か？」という問いを改めて考えることが重要です。