デザインシステムという単語が、曖昧に、広い意味で使われているように感じるこの頃。
デザインシステムについて見聞きすることが増えてきました。 かくいう自分も、デザインシステムに関してブログを書いたり、参考にしたりしています。 モバイルアプリ業界に、デザインシステム導入や検討の流れが来ているようです。
ただ、デザインシステムの議論には話の筋がとっ散らかっているという印象が拭えません。 「デザインシステムで解決したいこと」や「デザインシステム導入のコスト」、そ「デザインシステムを誰が管理するか」あたりが、特に雑多な印象です。
デザインシステムとはナニで、どう適用されるモノなのか。 そして、特に起きがちなデザインシステムの過度な一般化について、扱ってみます。
デザインシステムの過度な一般化
デザインシステムはどれほど「一般的なシステム」なのでしょう。 言い換えれば、どのような定義のデザインシステムであれば、広く課題を解決できる手段(＝システム)になるのでしょうか？
まず提起したいのは、『デザインシステムの議論は、どこまでが「特定の環境」の上での議論で、どこまでが「一般の」議論』なのかです。
デザインシステムは、「そのシステムを運用することで、サービスやアプリケーションのUI/UXの問題を解決できるもの」と定義されており、それゆえに「導入すれば、広く(アプリケーション開発の)問題を解決できる」と解釈されてしまっているように思います。 しかし、それはあまり正しいとは思えません。 「そのシステムを運用したことで、課題が解決できた」ことは、「ある環境で、あるシステムが、ある問題を解決した」ことを意味するだけで、一般的な解法とはならないためです。
あまり裏付けの取れていない話*1ですが、観測する限り、デザインシステムという言葉は「Webサービス/アプリケーション開発」の中で育った言葉のようです。 そのため「Webというプラットフォームのベストプラクティス」の文脈として、デザインシステムの議論は行われてきたと理解しています。
私はAndroid/iOSのネイティブアプリケーションに関わることが多いので感じる印象なのですが、AndroidとiOSの2つのプラットフォームが異なるように、ネイティブアプリケーションとWebアプリケーションは全く異なるプラットフォームです。 このため「Web/Android/iOSのマルチプラットフォームのベストプラクティス」とするには、デザインシステムの議論はやや不十分な印象があります。*2
試みたいこと
デザインシステムを導入や開発する際に、3つの点について議論することが必要、という共通見解を持つことを目指します。
- どの課題に対応するのか
- どれだけのコストをかけて解決するのか
- どのようにプラットフォームの変化に適応するのか
「システムを利用することで、WebやAppのデザインや印象、体験を統一するモノ」に至るまでの道筋に、幾つかのマイルストーン(Level)を設定していきます。 そして、このLevelという区分けをベースに話を整理することで「マネージャー、デザイナー、エンジニア」が協力し、サービスの開発に取り組めるようにします。
デザインシステムのカバー範囲の分解
下記のように、デザインシステムの成熟度を5段階に分けます。 それぞれは単なる段階であり、より大きい数字を目指すべき、という意図はありません。 ただし、大きな数字はそれ以下のプラットフォームの議論を前提に、発展していると考えています。
| level | description | ex |
|---|---|---|
| 0 | 何も整備されていない状態(画面ごとにルールが異なる、色定義が分散される、etc) | 未整備のアプリ |
| 1 | あるプラットフォームの、あるアプリ内で、統一的なルールが実装される状態 | アプリ内のカラーテーマを定数化した状態 |
| 2 | あるプラットフォームの内で、統一的なルールが実装される状態 | Carbon Design System |
| 3 | プラットフォームを跨ぎ、アプリやサービスで統一的なルールが実装される状態 | |
| 4 | マルチプラットフォームを前提とし、概念からデザインと実装が提供される状態 | Material Design |
| 5 | あるデザインシステムに合わせて、プラットフォームが実装されていく状態 |
なお、これ以後の文章ではLevel 2以上を広義のデザインシステム、Level 4以上を狭義のデザインシステムと書くことがあります。
Level 0
- 状況
- 画面ごと、パーツごとに個別の設計がされている状態
- アプリ全体を通しての統一、サービスを通して体験の統一がない
- 解決された課題
- なし
- 次に解決したい課題
- 新たな画面、パーツの作成の根拠がない
- 新規実装のコストが非常に高い
Level 1
- 状況
- 定数が活用されている状態
- デザインツールと、実装されたアプリケーションが対応した状態
- 解決された課題
- メンテナンス性の低さ
- 旧来の機能、ページの変更が容易になる
- 次に解決したい課題
- 新規開発を容易にしたい
- ベストプラクティスに従い、開発しやすい状態にしたい
Level 2(広義のデザインシステム)
- 状況
- 解決された課題
- 新たな画面、パーツ作成の根拠を持てる
- プラットフォームに適応したUIやUXが実現できる
- 次に解決したい課題
Level 3
- 状況
- 1つのデザインを作成すると、それに合わせた実装を各プラットフォームで行う状態
- ex. 1つのfigmaデザインをもとに、各プラットフォームで実装
- ex. ReactNativeやFlutter、Unityを採用して開発
- 1つのデザインを作成すると、それに合わせた実装を各プラットフォームで行う状態
- 解決された課題
- プラットフォームを跨ぎ、サービスとしてデザインを統一できる
- 次に解決したい課題
- プラットフォームごとの実装負荷を下げたい
- プラットフォーム固有の要望と、独自のシステムの要望の衝突を解消したい
Level 4(狭義のデザインシステム)
- 状況
- デザインを行うための概念を作成し、概念に合わせた実装がされている状態
- デザインツール上で、概念を扱うためのプラグインが作成されている
- 各プラットフォームで、概念を表現するための実装が提供されている
- 開発に関わる人が、共通した用語で概念を操作し、開発ができる状態
- ex. Material Designを導入した状態
- デザインを行うための概念を作成し、概念に合わせた実装がされている状態
- 解決された課題
- プラットフォームごとの実装負荷を削減
- (狭義の)デザインシステムがプラットフォームとの整合性をとることで、プラットフォーム固有の事情と衝突しなくなる
- 次に解決したい課題
- システムそのものの開発効率を上げたい
- システムそのものが、プラットフォームと整合性をとる領域を狭くしたい
Level 5
- 状況
- 解決された課題
- デザインシステム側がプラットフォームとの整合性をとる必要性がなくなる
- 次に解決したい課題
- (デザインシステムを握り、自社の開発を有利にしたい)
デザインシステムのコストについて
分解したデザインシステムの段階に合わせて、3つの視点からコスト感を考えてみます。 私見となりますが、大体下記のような移行コストがかかります。
| step | Designer team | Engineer team | Project Manager |
|---|---|---|---|
| 0-1 | 中 | 中 | 小 |
| 1-2 | 中 | 中 | 小 |
| 2-3 | 小 | 大 | 中 |
| 3-4 | 大 | 小 | 大 |
| 4-5 | 中 | 中 | 大 |
作成コスト
デザインシステムを作る場合、Level 4以上とLevel 3まででは「作る対象」が異なっています。 Level 3以下は「デザインツール上の表現」で、Level 4以上は「デザインをするための概念」です。
多くの場合、デザインシステムはデザインツール(figmaやSkatch、PhotoShopなど)上で構築されます。 例を挙げると、今動いているが何も整備されていないアプリケーションがあった時、まず行うのは「今ある画面の要素をfigma上に整理する」(0-1)ことです。 その後、「figma上で既存や新規画面について再整備」し、「新規機能を作るための、コンポーネント群」などを用意(1-2)します。 もしもマルチプラットフォームの対応が必要であれば、広義のデザインシステムを用意し、それを各プラットフォームで実装する(2-3)手順を踏みます。
この流れは、デザインツール上の資産が育ち「システム」として適用していく流れです。
一方で、「マルチプラットフォームに適用」させていく中で「プラットフォームごとの差異」に対応していくと、デザインツール上では表現できない(既存の表現では対応できない)事態が現れます。 この課題に対応するには、自分たちで、プラットフォームを跨いでも通用するシステムを作り上げる必要があります。 そのためには、「どのような概念が必要なのか」を整理し、それをデザインツール上で表現できるようにし、各プラットフォームごとに実装していく(3-4)必要があります。
Level 4以降においては、デザインツールは「ソース」ではなく「アウトプット」です。 Level 3までの資産は「参考」にするものとなってしまうため、作成のコスト感が跳ね上がります。
適用コスト
実装していく場合、用意されているデザインシステムを利用するケースで、適用コストが低くなります。 つまりシステムを「適用するために作成する」ケースと、「適用するために適用する」ケースの2つの場合分けがあります。
Level 2とLevel 4は「適用するために適用する」ケースです。 プラットフォーム(iOS SDKなど)かコミュニティにより作成されたシステム(Carbon Design Systemなど)を導入すると、そのシステムをアプリに適用する作業が主になります。 プラットフォームの機能(ダークモードや文字の拡大機能など)には、システム側が対応してくれるので、システムの成熟度に合わせてアプリも発展していきます。
一方で、Level 1とLevel 3は「適用するために作成する」ケースです。 特にLevel 3は「デザインツール上で作成されたデザインに、各プラットフォームの事情を考慮して、対応する」こととなるため、大変な労力となります。 例を挙げれば「iOS向けのデザインを作ったので、Androidはそれに合わせて実装する」であったり、「Web向けに設計したトンマナを、iOSアプリに適用する」であったりします。
自分はアプリケーションエンジニアなので、もう少し詳細に分析すると、大体3つの理由で「適用コスト」は分析できます。
- あるプラットフォームをベースにシステムを作った場合、他のプラットフォームで実装が困難になるが、どうするか
- 複数のプラットフォームに対し、システムの調整がされた時に反映させる仕組みの開発が必要になるが、どうするか
- プラットフォーム側で実装するために、担当者がデザインとプラットフォームの両方の用語を学ぶ必要があるが、どうするか
また、適用コストにおいてはマルチプラットフォームを対象としたフレームワークを利用することで、削減を測ることもできます。 つまり「あるプラットフォームのデザインシステムを利用すると、すべてのプラットフォームに適用できる」というフレームワークの採用です。 2021年9月の時点では、React Native/Flutter/Unityが実例としてあがるでしょう。
運用コスト
デザインシステムは、日々進歩することが求められます。 その運用コストにも着目する必要があります。
プラットフォームに新たな機能が入った場合、デザインシステムは「その新たな機能に対応するかどうか」を検討する必要が生じます。 最近の例でいえば、Dark Theme(Dark Mode)です。 プラットフォームに新機能が入った時、デザインシステムの開発者は「新機能に対応するかどうか」を意思決定する必要があります。
Level 2までのデザインシステムでは、この考慮はそこまで大変ではありません。 というのも、Level 2までの広義のデザインシステムは「単一プラットフォーム向け」のシステムであり、「対応する」以外の決定はないためです。 また単一のプラットフォーム向けであるために、プラットフォームごとの差異を考慮する必要がありません。
Level 3以降が、このコストが跳ね上がってくるゾーンです。 システムに関わる人全てに、継続的な学習と対応が求められます。 Level 4も言い換えれば「あるコミュニティがLevel 3として作成したものを、Level 4として公開している状態」であるため、開発者側の運用コストは非常に高くなっています。*3
少し穿った見方をすれば、Level 4のグループにおいて大変なのは「プラットフォームに、デザインシステムを合わせる」ことです。 このため「デザインシステムに合わせて、プラットフォームが作成される」状態になれば、話が変わってきます。
2021年9月の時点では、Level 4に位置しているのはMaterial Designのみだと考えています。 そして、このLevel 5への取り組みをAndroidやfuchsiaで進めている、そう見ています。 *4
デザインシステムを採用すること
まとめです。
ユーザーの体験を向上する、そしてサービスとして体験を統一するために、なんらかのルールや対応が行われます。 それらは「デザインシステム」の利用であったり、「デザインシステムのようなシステム」の導入です。 問題は「システム」をどのように、そしてなぜ利用するのか意識することです。
つまり、デザインシステムの採用は、チーム内のメンバーに期待する事柄を明記することでもあります。
公平のために記すならば、デザインシステムを採用することは、チームやサービスがどの「流れ」に乗るかを決めることでもあります。
例えば、Material Designに乗ることは、Googleが進めるデザインシステムの流れに乗ります。 Human Interface Guidelineに乗ればApple、ReactとReact Nativeをベースに進めればFacebook + Microsoftです。
もしも「自社で、概念から整理したデザインシステムを作る」という決断をすれば、それらと同じ土俵に上がることを意味します。 どこかの「流れ」の中で「ベストな運用」であると支持されるようになると、きっといいことがあるでしょう。しかし、それは「流れ」から外れにくくなります。 *5
本ブログの整理が、あなたの一助となれば幸いです。
