デザインシステムについて考えているシリーズ。
文章整理の都合上、言い切っているような表現をしている箇所だらけになりますが、全て筆者の意見です。 議論はモバイルアプリを前提とします。
抽象へのシステム化
あるアプリが他のアプリと何が違うのかは、アプリがユーザーに「あのアプリ！」と認識されるためには重要です。逆に言えば、全ての機能が同一であるならば(=コピーであるならば)、たとえ別のアプリとしてストアに並んでいても、認識されにくいと言えます。もちろんネットワーク外部性が効いてくるケース、アプリのプロモーションで差別化を図ることもできます。とはいえ、継続的にプロモーションをし続けることや、意図してネットワーク外部性を構築することは(開発チームとしては)難しい部類の話です。
らしさの整理
他と違うことは、言い換えれば特徴があることです。この特徴がアプリやサービスと結びつけば、立派なブランドの成立と言えるのではないでしょうか。 そこで、昨今の流行であるブランドらしさを作り上げるという観点から、話を整理します。
アプリの統一感や、あるアプリが「あるアプリらしい」と感じるためには、その「あるアプリらしい」という感覚を整理する必要があります。 このらしさをコントロール(整理)しようとする試みが、アプリの機能や見た目を整理することであり、システム化だと言えます。流行に乗って言えば、らしさを整理するためのシステムが構築されます。この文脈ではシステムの完成度を高めていく中で、よりらしさが明らかになることが志向されるでしょう。らしさがアプリの機能(ex. フォローできる、創作できるなど)に結びついている場合には、機能の特徴やあり方も、らしさを表現しているかどうかで判断されるでしょう。 このように捉えると、あるアプリのらしさを整理した結果として、そのアプリ用のデザインシステムが作られることとなります。この目的は、繰り返しになりますが、アプリのらしさを追求することです。
では、複数のアプリがあるケースに目を向けてみると、どうでしょうか？ 複数のアプリで同一の機能を実現するメリットは、あまりありません。FacebookとInstagramの両方に個別のメッセージ機能があるという例はありますが、SNSというサービスがネットワーク外部性が影響しやすいという事情による、特殊な事例と言えると思います。通常、同一の機能を複数のアプリで提供しません。このため、先述のらしさを機能で表現することは、難しいと思われます。 結果として、複数のアプリでらしさを共有するためには、機能ではなく体験をシステム化することになります。このらしさをシステム化するためには、アプリを概念的に捉える必要があります。アプリの体験から、アプリのらしさを抽出し、そして複数のアプリで利用できるように定義する必要があるためです。
らしさによる差別化のメリットとデメリット
らしさを軸としたデザインのシステム化は、アプリを概念的に捉え直し、抽象的な概念を取り出します。 結果、出来上がったシステム(デザインシステム)は、らしさを表現するための実態としてルールやコンポーネントを記述します。具体的なアプリから、アプリの抽象的な体験を導き出し、具体的なアプリを再定義する、ということです。
らしさによる差別化は、結果として抽象的な体験として、つまり印象レベルでの差別化を実現します。ユーザーに好まれる印象を作ることができれば、認識されやすく、また信頼されやすいアプリを構築できるようになるはずです。ブランド認知としては、非常に好ましい状況だと言えます。
一方、体験がらしいことを志向すると、他の体験からより独立している方向を目指すことになります。つまり、そのらしさを体験するために、ユーザーがらしさの世界に入門する必要が生じる、ということです。 そのため、新規ユーザーへのハードルが高い状況を作り出すことがあります。程度問題になるはずですが、らしさの提供するためのシステムに、ユーザー側が合わせる必要が生じます。 「この世界観は私向きではない」や「利用するために手間が多く難しい」と感じてしまいかねない、このリスクがデメリットではないかなと、思われます。
利便へのシステム化
ある操作や手続きがかんたんであること、使いやすいと感じる条件はいくつかあります。 今回は、その中の次の2つのかんたんに注目します。
- 慣習的な操作に近いもの
- 工学的に使いやすいことを確かめたもの
かんたんであること
慣習的な操作として想定しているのは、例えばスマホアプリのカメラ操作です。 「カメラアプリを開いた後、どのように撮影をするか？」と聞けば、大抵の場合「スマホの外カメラを対象に向け、画面上の◉をタップする」のような回答が得られます。この動作は、標準的なスマートフォンの標準的なカメラアプリの動作として確立しており、大抵の人が学習しているものになります。このため、新規にカメラアプリを作ったとしても、一般的な撮影手順を踏まえていれば、利用者は(そこまで)負担に感じずに利用することができます。
また、さまざまな調査や研究によって、かんたんであることを確かめる試みもあります。 古くはゼロックスのパロアルト研究所に関するエピソードが有名ですが、最近ではGoogleの時間選択ピッカーの調査が典型例です。
近年ではスマートフォンが増えているので、調査対象にも工夫が見られます。
The Research Study
We conducted two mixed-method research studies to investigate the usability of 24 hour analog clock designs (a single ring and a dual ring design) compared to a digital input clock design. Data was gathered from over 50 people in 6 countries (India, Indonesia, Brazil, Germany, France, UK) to understand perceptions among users who use 24-hour clocks, 12-hour clocks or both. 10% of our participants considered themselves low vision users.
このような調査を踏まえることで、ある根拠からよりかんたんであることが確かめられたシステムを構築することができます。
プラットフォームにおける標準コンポーネント
2023年現在、モバイルアプリが提供されるプラットフォームには、標準的なコンポーネントが存在します。 これらもまた、デザインシステムと一般に呼ばれます。
最も代表的なものは、Appleの提供するコンポーネントです。 Appleが提供するiPhoneは、調査によるばらつきはありますが、世界で30％弱のシェアを確保しています。日本においては、60%強のシェアを確保しているようです。 また、Human Interface Guidelineがモバイルアプリにおける1つの指標になっているように、Appleの思想やコンポーネントはモバイルアプリの基準になっています。このためAppleのらしさを表現するためのシステムは、iPhoneを利用するためのらしさに。そして1社で世界的なシェアを持っていることから、スマートフォンのらしさを構築するに至っています。
他方、GoogleのMaterial Designは、より正しさで特徴づけられます。
Android向けの共通基盤として登場したMaterial Designは、カスタマイズしやすくなるよう改善され、Material Design 2としてリリースされています。IntroductionやImplementing your themeを確認すると、運用する企業やブランドにどのように合わせていくかに着目している印象を受けます。
対して、2021年に登場したM3は、強く「多様なユーザーにとって便利であること」を志向するようになっています。とりわけ顕著なのは、色の扱いです。
Material Design 2のColorでは、 Legibleは強調されている一つの項目でした。しかしM3のColorではMaterial color has accessible contrast by defaultのように、最重要な項目として挙げられています。
M3の色システムについてのブログを読むと、色による読みやすさの確保について、M3というシステムで担保することを選択しているように見えます。これは一見、企業がM3を避ける理由となるように思えます。しかし(ブログの中で強調されているように)適切な色のコンストラクトを確保しなければ、アプリを利用するユーザーにとって不利益を与えることになります。 この論理を支える研究と、論理の強さによって、よりユーザーにとって利便性が高いシステムであることを表現しています。
デザインシステムの方向性
デザインシステムと呼ばれるものは多数ありますが、その分類や、性質の整理はあまり進んでいるように思えません。 今回は「デザインシステムがどのような志向を持っているか」という観点から、自分なりに2軸を整理してみました。 最後のまとめとして、2軸に分ける意味と、整理を踏まえた上で進めたい話を書きます。
抽象か利便か
アプリを開発する際には、誰しもに利用して欲しいと思って開発するはずです。 この意味で、抽象度を高める方向に舵を切ったとしても、利便を下げることを意図して行うことはないはずです。 この2軸を同時に踏まえる必要が生じている理由には、以下の3つがあると思います。
- 良いモノを作る仕組みが、全てそのまま良いアプリを作る仕組みとならない
- スマートフォンが日常品となり、すべての人が利用することを前提にする必要が生じた
- アプリが大量に生み出されたことで、アプリを切り替えるシーンが従来よりも増えた
良いモノを作る仕組みが、全てそのまま良いアプリを作る仕組みとならない
モノにおける体験の違いとは、そのままモノの特徴と言えます。 例えば手帳の差別化であれば、サイズや材質の違い、1ページの扱いややレイアウト、色や香りなどの切り口があります。 これらを(スキューモーフィズム的に)アプリに持ち込むことは、一度試みられましたが、現在では避けられるようになっています。
アプリの体験を抽象化し、その抽象化されたらしさをアプリに持ち込み始めると、この問題が再発することがあります。 強調したを例に出すのであれば、「手帳の手触り感を求めるあまり、画面上を指でなぞるような体験を追求しだす」のような事例です。 らしさを志向するだけでなく、同時にスマートフォンとしてかんたんかどうかという視点は、欠かしてはいけないように思います。
スマートフォンが日常品となり、すべての人が利用することを前提にする必要が生じた
上記のセッションを確認してもらうべきだと思うのですが、アクセシビリティの確保は当たり前のものにするべきです。 しかし、常に完璧なアクセシビリティを考慮した実装や設計を行う技能や工数があるとは、現実的には限りません。 またすべての人としてカバーできる範囲は、日々日々増えていきます。この意味で、アプリのすべての要素は、将来的に改善可能である必要があります。 この意味で、スマートフォンやモバイルアプリにおけるアクセシビリティについては、プラットフォームを提供しているチームの意見をよく確認するべきです。
アプリが大量に生み出されたことで、アプリを切り替えるシーンが従来よりも増えた
Appleを例外として、1つのブランドがスマートフォンのすべての体験をカバーすることはできません。 このため、ユーザーはすべてのアプリを「たくさんあるアプリの一つ」として利用することになります。 操作体系で他のアプリと差別化するためには、この認識の上をいくブランドイメージを構築する必要が生じます。
現状、ゲームアプリの分野では、この問題にぶつかっているように思います。 ゲームアプリでは、アプリ内のすべての要素がオリジナルになりがちです。このため、新規に遊び始めるときには、ゼロから操作を覚え直すことになります。 そこも含めて世界観を作り、熱心なファンを生み出すこともできますが、学習の難しさから脱落してしまうユーザーも多い分野ではないでしょうか。
日々のツールとしてのデザインシステム
結局アプリは開発チームが何らかの理由を持ってリリースしているため、どのように作られるべきかはチームごとの決定となります。 これを大前提とした上で、いくつかの意見を表明して、本ブログをまとめます。
アプリが娯楽のためである場合には、アプリの操作になれること自体が、ユーザーの利益になりえると思われます。 アプリを通して創作がなされるケースにおいても、その操作を覚えることでできるようになることが増えるという意味で、操作体系が独立していることに意味があると言えます。
しかし大半のケースでは、独自のシステムを作ることに慎重になるべきです。
What can you use instead?
We recommend that you follow Apple's Human Interface Guidelines and consider using modern UIKit components or SwiftUI instead. Both offer a high degree of flexibility through which you can express your product's brand while providing a predictable and familiar Apple platforms experience for your users. You'll also benefit from ongoing investments Apple makes in accessibility, ease of use, and deep integrations with OS features.
一つの事実として、コストを払うことのできるであろうMaterial Designチームが、iOS向けのコンポーネント開発を取りやめています。
また、その取りやめを表明する文章の中で You'll also benefit from ongoing investments Apple makes in accessibility, ease of use, and deep integrations with OS features. と記されていることは、重く受け止めるべきだと思います。
デザインシステムは、開発チームが日々利用するものであり、ユーザーが日々利用するシステムです。 このことから、筆者としては、「抽象概念としてのデザインシステムの完成度よりも、日々利用するツールとしてのデザインシステムの完成度」を重視するべきだと考えています。そのためには、標準的に使われる準備がなされたシステムをそのまま使うか、(ほぼ完璧に)理解した上で独自のシステムを作るかの2択になります。後者は学習や維持のコストが高いため、熟慮の上で対応を行う判断をするべきです。
これからはアプリのらしさが色や大胆な独自コンポーネントではなく、体験や標準コンポーネントの細かなカスタマイズになるのでは、と個人的に思っています。 こういった調整に力を発揮できるよう、エンジニアも学ぶ領域を広げていく必要があるのではないかなと。どんどん学んでいきましょう。