デザインシステム：みんなでデザインするための共通言語
じわりじわりではあるものの「デザインはみんなでするもの」という認識が広まりつつあります。
私たちのライフスタイルは多様化し、サービスに対する期待値の高まり、社会の複雑化、未来を予測することがより困難になっていることなど様々な要因により、私たちがサービスを作る上で持つべきマインドセットに大きな変化が求められています。これまではユーザーのことを中心に考えてサービスを作っていればよかったのに、ユーザーを取り巻く環境を理解した上でサービスを作ることが求められるようになったのもその一例でしょう。
上記のような環境に対応するためには、デザイナーだけがデザインに取り組めばよい状況ではなく、様々な知見を持った人々でチームを組み、一丸となってものづくりに挑むことが必要となります。
「みんなでデザインする」ために必要なことは何か？
当たり前かもしれませんがまずは、チームとして同じ言葉を話すことです。私がデンマーク留学時にも指導教官からデザインプロジェクトにおける「use normal language」の重要性を何度も聞かされました。もちろん、ここで述べるlanguageというのは、日本語や英語やデンマーク語などではなく「appleと言えばリンゴのことである」「サッカーでは手を使ってはいけない」のようなサービスを作るための共通認識といった意味です。
ものづくりの共通言語：デザインシステム
ものづくりにおける共通言語として、ここ数年、デザインシステムに対する注目が高まり続けています。例えば先日はFigmaによって作られたデザインシステムをまとめたサイトが話題になっていました。
また、つい数日前には、kiwiによって公開されているOrbit Design systemの新しいバージョンがリリースされたことが話題になっていました。
デザインシステムの定義については明確に定められていないものの、簡単に説明するならば、サービスを作る上で共通して利用できるリソースをまとめることによって、スムーズなサービス開発を促進するためのもの、とでも述べることができます。
デザインシステムの構成要素としては、サービスで使用される色やフォント、レイアウトやUIの部品、あるいはコンテンツガイドラインやデザインプロセス、デザイン原則などがあげられますが、デザインシステムに何が含まれるべきかについても明確に定められたものはありません。
サービスは様々な人々が関わる事によって世に送り出され、運用されています。代表的な役割を挙げるとするならばデザイン、ビジネス、開発に関わる人々でしょう。
これまでデザイナーは開発チームやビジネスチームからのリクエストに応じて、逐一画面をデザインしていました。無理やり図にすると下記のような感じかと思います。
この図はかなり簡略化したものであり、実際には各チーム間のコミュニケーションは何度も往復することもあります。ビジネスチームから「こんな感じのWebサイトのデザインを作って欲しい」とデザインチームに依頼があり、サイトのデザインを作ったとしてもそれがビジネスチームの意図通りであることは稀でしょう。
一方でデザインシステムがあるとこのような形になります。
デザインチームは共通して使いまわせるリソースをまとめておくことによって、簡単な画面であればデザイナーに仕事を依頼しなくても、共通して使い回せるリソースを使ってビジネスチームや開発チームで画面を組み立てることが可能になるわけです。
もちろん個別にデザインする必要の画面やUI部品などが必要になる場合もあるので、デザインシステムがあればデザイナーのリソースが不要になるというわけではありませんが、より効率的にサービス開発を進められる様になります。
デザインシステムと言う言葉から、デザインシステムはデザイナーのためのものというイメージが持たれてしまいがちですが必ずしもそうではなく、サービスに関わるすべての人が良いサービスを作るための共通言語、あるいはフレームワークのようなものだと捉えて頂くのが良いかと思います。
デザインシステムは見た目だけの話ではない
デザインは見た目だけの話ではないという話は、UXデザインやデザイン思考のような概念の普及によって、多くの方によって認識されつつあるところかろ思います。
これらデザインの領域は、うまく使うことで非常に強力な武器となる一方で、人によってそのプロセスがまちまちで、チームとしてコラボレーションする際に課題となる場合も多々あります。
そこで、いくつかのデザインシステムではデザインの原則やデザインのプロセスについても定めることによって、サービスに関わる人が共通のプロセスでサービスをデザインする事ができるようにしています。
クックパッドの場合
クックパッドでは下記のようにFigmaでデザインシステムを公開しており、その中にBrand Identityの項目があります。
詳細については内容を直接確認頂きたいところですが、興味深いのはPersonalityについて定められているところかと思います。このPersonalityというのは、ユーザーから見て、クックパッドという会社や、クックパッドの様々なサービスがどのように認識されたいかを定めたものであり、サービスを企画したりデザインしたりする際には、自分たちのサービスがこの基準を満たしているかを評価することで、ブランドの軸がブレることを防いでいるはずです。
他社ではデザイン原則（Design Principal）として扱う場合もありますが、ほぼ同様のものだと私は捉えています。なお、下記のサイトは様々な企業や政府のデザイン原則を集めて見れるようになっており、大変参考になります。
イギリス政府の場合
例えば、下記はイギリス政府のService Manualです。Service Manualとは、イギリス政府が（主にWebの）サービスを作り、提供する際の手順がまとめられています。
上記Webサイトを見ていただければわかることではあるのですが、下記のような項目について方法が定められています。
- アクセシビリティを確保の仕方
- データを活用してサービスを改善方法
- チームをいかにして作るかについて。どのような人材が必要か、どうやって採用するか。ベンダー選定の方法など。
- （アジャイルでの）プロジェクトの回し方
- サービスの評価の仕方
- ユーザーのニーズの理解の方法
- サービスのデザインの仕方
- 技術の選定方法や開発やテスト、運用などについて
サービスを企画して開発し、公開するまでの一連のプロセスはおおよそ下記のようなものになるかと思いますが、このプロセスのすべてが明確に定められております。
1. どのようにプロジェクトチームを立ち上げて、
2. どのようにプロジェクトを回して、
3. どのようにユーザーを理解して、
4. どのようにデザインして、
5. どのように開発して、
6. どのように評価して改善していけばよいか
イタリア政府の場合
このようなWebサイトは世界各国が公開しており、イタリア政府も下記のようなサイトを公開しています。
内容としてはイギリス政府と共通する部分も多いですが、サービスデザインの概要や、プロジェクト管理の方法、プロトタイピングの方法、コンテンツデザイン、ユーザー調査の方法、ユーザーインターフェースのデザイン方法などがまとめられています。
イタリア政府のサイトで興味深い点は、下記のようにペルソナやカスタマージャーに作成するためのシートが公開されており、具体的なサンプルも用意されていることによって知識の無い人でも比較的とっつきやすい点と言えるかもしれません。
本記事ではイギリス政府とイタリア政府のWebサイトを取り上げ紹介しましたが、どのようにWebサービスを企画してデザインし、開発し運用していけばよいかのガイドラインを世界の様々な国が公開しています。
みんなでデザインして、みんなで改善する
このようなガイドラインがあることによって、デザインやエンジニアリングに関する専門知識がない方であっても、一定のクオリティでWebサービスを作り公開していくことが可能になります。
開発者にとってのメリットとしてわかりやすいところでは開発効率の向上が上げられるでしょう。理想的なデザインシステムにはコードが含まれていますから、デザインシステムに含まれているコンポーネントを用いてサービスを作る場合、少なくとも見た目に関する部分については新たにコードを書く必要はないはずです。このようにコードを使い回すことによって工数を可能な限り削減できます。
また、新しいコードを書かなくて済むということは、新たなバグの混入を可能な限り防ぐことにも繋がりますので、そういった意味でもメリットは大きいと考えられます。
デザインシステムはビジネスサイドにとっても大きな価値を持ちます。新しい画面を作る必要が生じたときに、デザイナーの手を借りなくてもデザインシステムを参照して、パーツを並び替えたりすることで、ある程度のところまで自分自身で画面を組み立てられるということは大きなメリットかと思います。もちろんデザイナーならではのノウハウが必要になるところは依然として残り続けることと思いますが、自分たちで試行錯誤ができるようになるということはものづくりのスピードを飛躍的に向上させるはずです。
職能でわけるのではなく、プロジェクトに携わるチームからデザインシステムを捉えてみると、デザインのプロセスが明確に提示されていることの価値はとても大きいと考えています。みんなが同じプロセスでサービスをデザインするということは、チームメンバーそれぞれが次に何をすればよいかを容易に理解することができます。
サービスづくりではありませんがチームで行うアクティビティのひとつとしてサッカーをイメージしてみてください。現代のサッカーは各プレイヤーがそれぞれ自由にフィールドを動き回るというよりは、様々な戦術があり、各プレーヤーはその戦術の上でプレイします。
有名な戦術としてはポゼッションサッカーが挙げられます。これはボールの支配率を高めることで勝利に近づけるという思想のもと、短いパスを多用しながら味方同士でパスを回しながらゴールを目指すものです。このような共通した戦術があることによって、様々な状況で各プレーヤーが自分がどう動くべきかを判断することができます。
共通のプロセスやガイドラインの存在は、プロセスの改善のために大きく役立ちます。出来上がったサービスが万が一あまり良くないものだったとき、デザインプロセスが明確で無い場合に次にどうすれば良いのか検討することが非常に難しい。
前述したサッカーの例でもそうですが、共通の戦術がなければ、試合の内容について振り返ることが大変難しくなります。一方で、ポゼッションサッカーが正しいものとすれば、その上で各プレーヤーの動きを論じることもできるでしょう。例えば、相手チームがプレッシャーをかけてきたときは、こうするべきだった…など。
プロセスが明文化されていることによって、デザインプロセスそのものを評価してプロセスそのものを改善していくことが可能になります。新しいサービスを立ち上げていくプロジェクトの中では、プロセスに問題がある場合やプロセスが想定していないようなケースも当然あり、プロセスをアップデートすることが次に取るべきアクションとしてベストの選択肢であることも当然あるからです。
おわりに
デザインシステムの考え方は、登場してまだ日が浅いこともあり「デザインシステムはこういうものである」という共通認識が形成されるには至っていないように思われますが、ひとつ言えることは、デザインシステムはただのライブラリではないということです。
デザインシステムは異なる専門性を持つ人々同士との潤滑油や共通言語となるようなもので、言い換えるならばサービス開発を加速させるためのシステムと説明することもできます。様々な立場のステークホルダーみんなでより良いサービスをデザインし、改善していくために必要不可欠なものと言って過言は無いでしょう。
＝＝＝以下、宣伝＝＝＝
私が代表を務めるアンカーデザイン株式会社では、デザインリサーチとプロトタイピングを通してデジタル時代のプロダクト開発に取り組んでおります。興味のある方はお気軽にお問い合わせください。
この記事が気に入ったらサポートをしてみませんか？