見出し画像

デザインシステムはデザイン現場にどのように浸透しているのか

日本でも2年半前にデザインシステムの書籍が発売され、一時期アトミックデザインと共に様々なところで話題にされました。

私もちょうど体系的にシステム全体のデザインをする方法について模索中でしたので直ぐに書籍を購入し、プロダクトデザインのためのアトミックデザインを拡張して、システムデザインのための「コズミックデザイン」という概念をnoteの記事にしました。

・・・

あれから実際のデザイン現場ではどのような変化があったのでしょうか。今回はその後の流れについて振り返りをしながら、今後の展開について考えてみたいと思います。


デザインシステムとは

多くの記事で説明されているので簡単に触れておきます。企業にとってデザインシステムとは「価値の高い製品を効率的に作り続ける仕組み」であり、デザイン組織の運営も含めた有形無形の資産(リソース)を管理(マネジメント)しまた生み出(クリエイト)していくことであると言えます。

・・と言うような抽象的な概念ではなくもっと地に足がついたものです。細かいデザインリソースを事前に準備しておくことで、プロダクトデザインのフェーズでは製品の主要な価値や他社との差別化部分に注力することができるものです。

そのため、基本コンポーネントやカラーセット、フォントセットやレイアウトグリッドなどのデザインアセットを準備し、それを正しく活用するためのルールや思想をまとめたものになります。

実際デザインの現場では、従来のデザインガイドラインに実際に使えるアセットが組み合わされたものをデザインシステムと呼んでいる感じだと思います。


大企業だからこそデザインシステムが必要

ベンチャー企業から大企業までさまざまな規模の会社が製品を生み出していますが、デザインシステムが使われる状況として次の4つのパターンに分けることができます。①②は規模の小さい企業に多く③④は規模が大きい企業に多くあるパターンです。

① 1つのプロダクトを改良し続ける
② 1つのプロダクトを拡張する
③ 複数のプロダクトを作る
④ 連携する複数のプロダクトを作る

企業の規模が問題になるのは、情報の共有やコミュニケーションに大きく影響するからです。小さな規模で始めたベンチャーも第2世代、第3世代のメンバーが加わるようになると、初期のメンバーが共有していたい前提となる情報や暗黙のルールが引き継がれなくなり、②の拡張をやろうとすると思わぬ落とし穴にはまってしまうことになります。

当然それ以上の人数がいる大企業では、ちゃんと情報が共有されない状況になってしまうためデザインシステムがより重要になってきます。

特に④のパターンでは、デザインシステムを作ることがプロダクト開発の主要な業務と考える必要があります。システム全体の目的を明確にして、それを実現するための各機器/アプリの役割を定義し、実際の連携部分の振る舞いをデザインしていかなければなりません。


実際のところは・・・
大企業の開発ではウォーターフォール型の開発が主流で、組織の上位者による会議によって大きな目標だけ決めて、後は各部門に持ち帰りそれぞれ開発を進め、後半で他の製品との連携で問題が出てくると「すり合わせ」と称してその場限りの辻褄合わせをし、モノ作りは現場が重要だと言った人がまた出世するという、デザインシステムとは程遠い状況である場合も多いのです。


「システム」の3つの定義 UXは大きいシステムで考える

デザインシステムを考える前に、デザインの対象としての「システム」について考えてみたいと思います。

1つのプロダクトをシステムとする考え方と、複数のプロダクトが連携したりユーザーや環境を含めた全体をシステムとする考え方があります。前の章で書いた①②は1つのプロダクトをシステムと考えても差し支えありませんが、④の場合には複数プロダクトをシステムとしておいたほうが都合が良くなります。

さらに後者の大きなシステムの考え方に「人間中心設計」のユーザーと利用環境の把握というところを組み込んでいくことが、企業の提供価値をUXに置くデザイン経営では必要なシステムの定義になってきています。

画像 1


UIデザインツールの進化とコンポーネント

AdobeXDやFigmaのようなデジタルプロダクトのUIデザインツールでは、UI要素をステータスをもったコンポーネントとして扱う特別なオブジェクトの考え方が採用されています。

これまでのようにIllustratorやPhotoshopを使って単に見た目の状態をデザインするのではなくデザインシステムの「実際に使えるアセットを準備する」ということを具現化しています。

1つのデザインパーツが状況の変化で複数の状態(ステータス)を持つだけでなく、必要なパラメータをオーバーライドすることでサブクラスを作ることもできるようになっています。この仕組みは複雑に見えますが一度複雑なものを作れば、後は上位階層からは一つのオブジェクトとしてシンプルに扱うことができるようになるというメリットがあります。

・・・

このようなコンポーネントやカラーセット、フォントなどに名前を付けてデザインアセットとしてチームで共有することができますので、タイトルの付け方でデザインルールを伝えることができるので、デザインシステムのプラットフォームになっています。

また共同作業もクラウドサービスを使うことで標準的なものになりつつあることもデザインシステムを実践していくための重要な要素になってきています。


UXデザインツールとUXオブジェクト

ハードウェア開発には3D-CAD、電気回路ならE-CAD、ソフトウェア開発ならIDEがあり、アプリ/Web開発ではUIデザインツールによってデザイン現場に定着しつつあります。それぞれオブジェクト指向で階層的に情報を扱うことができるようになっています。

一方でUXデザインでもデザインシステムを展開するためのデザインツールが必要だと考えていますが、いまのところこれといったメジャーなツールが見当たりません。

UXデザインでは、これまでシナリオ/ペルソナ手法、ジャーニーマップなどによって、複数の登場人物/アイテムの役割や関係を記述し、体験価値を扱ってきました。

miroやStrapのようなチャート作成ツールを使うことでドキュメントとして作成しやすくなっていますが、UIコンポーネントのようにオブジェクト構造をもったりするところまではきていません。


ハード/ソフト/サービスなど各システム要素を一元的に結び付けUXの視点からユーザー要求(User Requirements)としてまとめられ、それを実現するための各プロダクトやシステム要素への要求仕様(Product Specifications)へと落とし込まれていきます。

それらを書類としてまとめるためのツールでは無く、UXデザイン活動としてアイデア出しからプロトタイピングまでをサポートすることができ、さらに実際の設計データ(CAD、UIデザインデータ等)へのリンクをオブジェクト管理構造の中で扱えるツールの登場が望まれます。



この記事が気に入ったらサポートをしてみませんか?