もう去年の話ですが、Airbnbが Building a Visual Language という記事を出しています。デザインシステムの管理に興味があったり、デザインの現場で役立つ英語を学びたい方はぜひ読んでみましょう。

デザインをシステムとして管理するという発想は新しいものではありません。グラフィックデザイナーであればNASAなどNew York City Transit Authorityのスタイルガイドを手に取ったことがある方も多いのではないでしょうか。ブランディングの仕事をすれば大抵はタイポグラフィや画像の使い方、印刷物や様々な媒体のテンプレートなど運用マニュアルをセットで納品することになります。

マテリアルデザインに代表されるようにソフトウェアの分野でもデザインシステムは重要なトピックです。

Working in software development and design, we are often required to ship one-off solutions（略）These one-off solutions aren’t inherently bad, but if they aren’t built upon a solid foundation, we eventually find ourselves having to pay back accrued technical and design debts.

ソフトウェアの開発やデザインでは一回限りの解決策（one-off solution）を公開（ship – 出荷する、外に向けて送り出す、という意味で使います）しなくてはならないことがよくあります。これは本質的に（inherently）悪いという訳ではありませんが、確かな基盤（solid foundation）に基づいていないとあとで負債（debt）となってツケを払う羽目になります。

Visual language is like any other language. Misunderstandings arise if the language is not shared and understood by everyone using it.

ビジュアル言語も他の言語と同じです。言葉が皆に共有されて理解されていないと誤解が生じます。

Design has always been largely about systems, and how to create products in a scalable and repeatable way. From Pantone colors to Philips screws, these systems enable us to manage the chaos and create better products. Digital products are perhaps the most fertile ground for implementing these systems and yet it’s not often considered a priority.

デザインは常に、システムの問題、製品をどのように拡張性を持って（scalable）繰り返し可能な（repeatable）やり方で作れるかという問題に大きく関わってきました。ここではパントーンやフィリップスのねじを例にあげる一方で、デジタルの世界ではあまり優先と見なされない（not often considered a priority）ことが指摘されています。

デザインシステムが必要な理由

デザインシステムが必要な理由はいくつかあります。この記事で挙げられている理由をみてみましょう。

Too few constraints　ソフトウェアには他の分野（discipline）に比べて制限（constraints）が少ない。色々できてしまう分バラバラになる（disjointed）こともあるので、自分たちで制限を設けなくてはならない。

Multiple designers and stakeholders　ステークホルダーが増えるほど一貫した（coherent）UXを作るのが難しくなる。小さなチームではまとまりがあった（consistent）ものが、違う人が新しいソリューションを加えるたびに枝分かれ（diverge）していく。coherentとconsistentは両方とも一貫性があるという意味で使われる頻出単語です。前者は筋が通ってまとまった、後者は全体に均質なイメージで微妙に違うニュアンスを感じます。（ググったらcoherent は logical and consistent と定義されていました）。

Multitude of platforms　数多くの（multitude of）プラットフォームとデバイスに向けて作るには機能やデザインを揃えるために多大な努力が必要で、繰り返し同じ作業が必要になることがよくある。

Software as a continuum　ソフトウェアは物理的に使い古されて（wear out）置き換えられるのではなく、何年も前からのコードやデザインが残り続ける。そのため絶えずメンテナンスとアップグレードが必要になる。

自分がデザインシステムについて説明する場合には、品質（quality）、一貫性（coherency/consistency）、効率（efficiency）、コスト（cost）などの軸について考えます。よく吟味された（＝品質の保証された）ソリューションを一貫して、アップデートしやすい形で使うことでデザインと開発を効率化し、浮いた分をそれぞれのプロダクトや機能に固有の（unique）問題に集中できるようにする。こうしたメリットと、システムの開発やメンテナンス、コミュニケーションにかかるコストのバランスをとる。といった感じです。

後半へ続く

続きはこちら。記事の後半では具体的なデザインシステムとプロセスについて触れています。