デザインシステムとは？内容や作り方、運用方法を解説します

デザインシステムとは？

デザインシステムの定義

デザインシステムとは、企業のビジョンやブランドアイデンティティなどから「良いデザイン」を定義するデザイン原則などのドキュメント、それらを具体的にデザイン・実装するためのUIパターンやコンポーネントなどを備えた一連のリソースのことを指します。

デザインシステムを作る目的としては、複数のデジタルプロダクト・サービスを展開する際にブランドの一貫性やデザイン品質を担保したり、運用を効率化させるという点が挙げられます。

デザインシステムの構成要素

デザインシステムを構成する3つの要素

デザインシステムの構成要素を3つに分けると、以下のようになります。

デザイン原則
原則に基づいたルール(スタイルガイド)
原則に基づいたツール(コンポーネントライブラリ)

それでは、各要素について詳しく解説していきます。

デザイン原則

プロダクトに関わるステークホルダーがプロダクトを作っていく上で大事にすることを言語化したものです。これがあることで、何を優先してデザインを作っていくのかという道標になります。

原則に基づいたルール(スタイルガイド)

デザイン原則に基づいて作られた、UIパターンやタイポグラフィ、カラースケールなどのガイドラインです。

原則に基づいたツール(コンポーネントライブラリ)

リストやボタンなど、再利用可能ですぐ使用できるコンポーネントをコードとセットで置いたライブラリです。エンジニアがコードを書く際にすぐに呼び出すことができます。

具体的なデザインシステムの構成要素

それではそれぞれの要素の具体例を挙げていきます。

原則

デザイン原則

デザイン原則とは、プロダクトに関わるステークホルダーがプロダクトを作っていく上で大事にすることを言語化したものです。これがあることで、何を優先してデザインを作っていくのかという道標になります。

例えば、SmartHRのデザイン原則では、「言葉からはじまるデザイン」という原則があります。SmartHRが扱う人事・労務の領域は様々な要素が関わる複雑なものです。そこで、言葉による定義にこだわることにより、視点を揃えてプロダクトを作成することができ、さらにユーザーにもその使い方を正しく理解してもらうことができます。理念が原則に反映された典型的なモデルと言えるでしょう。

[SmartHRのデザイン原則では、「言葉からはじまるデザイン」という原則が定められている]

ボイスアンドトーン

ボイスアンドトーンとは一貫した言葉遣いのことであり、これを心がけることで、自然とそのプロダクトが持つ性格などをユーザーが認識します。ボイスアンドトーンは、プロダクトが届けたい価値や体験、そのプロダクトらしさを言葉で表現するための指標になります。

Atlassian Design Systemでは、「信頼を築くために情報を提供する」というボイスアンドトーンがあります。ユーザーにはオープンでクリアなその時に必要な情報だけを伝え、それ以上は書かないということです。Atlassianのボイスアンドトーンで興味深いのは、各画面における言葉使いの大胆さの指標をゲージで表示している点です。これにより、デザイナーはその時に適切なトーンを一目で判断することができます。

[**Atlassian Design System Voice and tone principles** では「信頼を築くために情報を提供する」という原則が定められている]

原則に基づいたルール(スタイルガイド)

スタイルガイドでは、色やタイポグラフィ、イラストレーション、マージンなどといったプロダクトのスタイルを統一するための要素について定義されてます。

Atlassian Design Systemのタイポグラフィは使用書体について、クロスブラウザのフォントまで定義されています。

[**Atlassian Design System Typography** ではフォントに関して各OSで使用する際のレギュレーションを定めている]

AmebaのSpindleではアイコンの線幅について情報密度によって変えるように細かく定義しています。

[ **Spindle アイコン** では情報密度に応じた線幅でアイコンを作成するよう定められている]

原則に基づいたツール(コンポーネントライブラリ)

コンポーネントライブラリは、ボタンやアコーディオンなど、すぐに使える再利用可能なコンポーネントのコードそのものです。

OktaのOdysseyでは、ボタンのサイズやバリアントを選択すると、上のプレビューで選択されたタイプのボタンを確認することができます。また、storybook-addon-a11yというアドオンが導入されており、WCAG2.0, WCAG2.1に適合しているかどうかが簡単にわかるため、アクセシビリティについても確認できます。

[**Okta Odyssey** ではボタンのサイズやバリアントを選択すると、上のプレビューで選択されたタイプのボタンを確認することができる]

AbemaのSpindleでは、リストの種類(リンクリストなのか、アクション付き情報リストかなど)によってどのようなデザインになっているのかが定義されています。

`[ Spindle リンクリストではリストの種類によってどのようなデザインになっているのかが定義されている]`

ここで取り上げているものはあくまで一例に過ぎません。

これら全てを取り入れるわけではなく、チームや組織の規模に応じて柔軟に必要な要素とそうでないものを取捨選択しましょう。また、必要だと思ったら新しい要素を追加することを検討するのも大事です。

デザインシステムの3つのメリット

一定水準かつ、一貫性を損なわないUIデザインができる

同じサイト内でコンテンツごとにビジュアルや操作性が大きく異なっていたら、ユーザーは混乱してしまいます。複数人で(特にガイドラインなどを定めず)闇雲に作業するときにこう言った現象はよく起こり得るものです。

デザインシステムは、非属人化されたプロセスを提供するものであり、これによって上記のような現象はある程度回避することができます。

こうした一貫性を損なわないデザインをユーザーに提供することは、安定したユーザー体験をもたらすという意味でもとても価値があります。

コミュニケーションがスムーズになり、チームや会社全体での連携が高まる

デザインシステムには、プロジェクトメンバー同士のコミュニケーションをスムーズにする効果もあります。

プロジェクトメンバーにはデザイナーやエンジニア、プロジェクトマネージャー、またプロジェクトを依頼しているクライアントなど立場や知識などが異なる人々が混在します。

メンバーの持つ前提知識や認識がバラバラのままで、果たしてそのプロジェクトはうまくいくでしょうか？

デザインシステムを使えばルールが明確になり、意見の食い違いを避けられ、コミュニケーションがスムーズになります。

連携の取れたメンバー同士での作業でプロジェクトはスピーディに進行するでしょう。

開発やデザインが効率化され、コスト削減できる

前述した2点のメリットにより、開発では再利用可能なパーツがコンポーネントライブラリにまとまっている為、エンジニアが重複した余計なコンポーネントを作ってしまう可能性を減らすことができます。また、デザインではルールが明文化されているので、デザイナーが素早く判断することができます。各人の作業が効率化された結果、コスト削減につながるのです。

デザインシステムの事例

ここでは実際に使われているデザインシステムをいくつか紹介します。各デザインシステムによってデザインシステムに取り入れている要素やそうでない要素は様々なので自分たちのデザインシステムにはどのような要素が必要なのか考えてみるのもいいかもしれません。

Material Design

Material Designは、Google社が2014年に提唱したデザインシステムです。

現実世界の物理法則を取り入れる
紙とインクの要素で組み立てる
色の数を少なく配色する
影を活用して立体感を作る
連続性のあるアニメーション

５つの原則のもとに作られたデザインシステムで、デザインや原則について詳細な説明があります。

Material Designは、昨年Android12のリリースとともにMaterial Design 3に更新されています。

ユーザーの壁紙に応じてシステムUIのカラーを変更する「Dynamic Color」が追加されたり、デバイスサイズに応じて動的にフォントサイズを管理できる「Adaptive type scale」が追加されました。

このように、日々アップデートをしていくことでデザインシステムは時代に取り残されない洗練されたものになります。

Poralis

Poralisは、Shopify社が開発したデザインシステムです。

Shopifyのデザイナーとmerchant(商人)に向けて一貫したデザインができるようなガイドラインを作成しています。

Poralisでは通知音(Sound)についての原則が定義されています。

通知音がマーチャントにとってどうあるべきものなのか、各デバイスでの通知音の音量など、細かく定義されています。

このように、プロダクトにとってデザインシステムによって定義されるべきものは様々であり、正解はひとつではないことがわかります。

Odyssey

OdysseyはOkta社が展開するデザインシステムです。storybookというソフトウェアの中でデザインシステムが完結しています。

Storybookとは、UIのコンポーネントを管理してくれるツールです。Reactなどで設計するコンポーネントをカタログ化して、一覧で閲覧できます。アプリケーションを開発する時にUIコンポーネントのみを切り離してStorybook側で構築・管理をするという使い方ができます。アプリのリポジトリからStorybookのリポジトリを参照し、UIコンポーネントをインポートして使うことで、アプリケーション側が必要な時だけ、コンポーネントを取り込んで使うこともできます。

Storybookに全ての要素をまとめることで、十分に成立しうるデザインシステムを必要最低限のコストで作ることもできます。

デザインシステムを作る前に考えるべき4つのこと

新規サービスにデザインシステムは必要か

新規サービスをリリースする段階で最初からデザインシステムを導入するべきでしょうか？

新規サービスは成長段階にあり、今後も大きな変化が見込まれます。

その段階で、デザインシステムを導入するとどういうことになるでしょうか？デザインシステムとは一定水準かつ一貫性のあるデザインを提供する仕組みです。サービスの成長に応じて最初想定していたユーザー層が変わることなど、様々なギャップが出てくることでしょう。折角決めたルールが、それらが変化する度に使われなくなったり、変更されてしまうことが予測できます。

こういった事態を避けるためにデザインシステムはある程度サービスが安定してきてから導入する方が労力やコストを削減する観点からも良いと言えます。

導入する目的は明確か

デザインシステムはそれ自体を作ることが目的ではなく、プロジェクトやプロダクトをより良くするための手段です。

導入する目的が不明瞭なまま作ってしまうと、活用されずに無駄になってしまうことがあります。そこで、デザインシステムを導入して実現したいことを目的としてまず設定しましょう。

そしてその目的が達成されるようなデザインシステムを作っていくことで、ただデザインシステムを作って満足した、という状態から抜け出すことができます。

プロジェクトの規模に合っているか

デザインシステムを必要とするプロダクトとはどれくらいの規模感でしょうか？

デザインシステムはそもそも内製できる状態にないと、啓蒙や管理・運用ができません。また、デザイナーが二人以上いないとデザインシステムを作っても使う人間がいないのでそこまで大きな結果を得ることはできません。前提として何らかのデジタルプロダクトを保有しており、それが複数存在するか、二つ目の製品をローンチする時にこそデザインシステムは真価を発揮します。

ネイティブアプリのデザインシステムは作るべきか

iOSやAndroidなどのネイティブアプリのデザインシステムは作るべきでしょうか？

これらには既にHuman Interface Guidelineや、Material Designなどといったデザインシステムが既に存在しており、それに沿ったアプリ制作が求められています。

よって、既存のシステムと矛盾しない一貫したデザインシステムを新たに作るのはかなり難しいため、慎重になる必要があります。

デザインシステムの作り方

1. 原則を決める

まず企業のビジョンやブランドガイド、現状のプロダクトデザインからデザイン原則を作成します。デザイン原則を作る目的として、第一にデザインシステムにおいて重要な「らしさ」が何であるかをステークホルダー全員が納得することにあります。

2. スタイルガイドを作る

デザイン原則に基づいたデザインルールを策定します。まず以下のような要素を固めましょう。

カラー
タイポグラフィ
レイアウト
アイコン

などは、既存プロダクトで定義されている箇所を参考に決めましょう。これらはムードボードを使うと、プロダクトの雰囲気が一目でわかるのでよりわかりやすく作成できます。スタイルガイドを作ることで、「らしさ」が表現されたUIを実現することができます。

3. コンポーネントライブラリを作る

コンポーネントライブラリは定義が必要なコンポーネント要素をまず洗い出し、それを実装するコードとビジュアルのセットにして作成します。そしてコンポーネントの名称を確定しましょう。

実装効率が意識されたものでないと、エンジニアが実装する際に実現できないものが作られてしまう恐れがあります。原則やスタイルガイドに基づいた見た目になっているかというデザイナー的視点とエンジニア的視点の双方を考慮して作る必要があります。

順序は1パターンでなくても良い

デザインシステムはどう作るべきでしょうか。前述した順序での作り方が理想的ではありますが、必ずしもそうできないこともあるでしょう。スタイルガイドが先に存在する場合などもあります。必ずしも原則からかっちり作っていかなくとも、きちんとデザインシステムを作る目的を明確にすれば自分たちのプロダクトにはどのような要素が必要なのか、またどのように作っていくべきかは自ずと理解できるはずです。