デザインシステムについて考えているシリーズ。
文章整理の都合上、言い切っているような表現をしている箇所だらけになりますが、全て筆者の意見です。 議論はモバイルアプリを前提とします。
抽象へのシステム化
あるアプリが他のアプリと何が違うのかは、アプリがユーザーに「あのアプリ！」と認識されるためには重要です。 アプリの名前であったり、仕組みであったり。あらゆる面で、アプリを運用する上で、アプリの認知は大事な要素になります。 一方、他のアプリと自分のアプリの間に違いがない場合には、「あのアプリ！」と認知されにくくなります。場合によっては、別のものと思われていないことすらあるでしょう。
この違いは、様々なパターンがあります。アプリの機能以外にも、違いを生み出す要因があります。例えば、SNSのようなネットワーク外部性が効いてくるケースであれば、見た目が近くとも別のアプリになるかもしれません。アプリのプロモーション、もしかしたらイメージキャラクターの強さで差別化がなされることもあります。
とはいえ、アプリの開発者としては、機能に着目して議論を進めるべきでしょう。 機能以外にも道があることを頭に置きつつ、以後、機能についてを軸に話を進めます。
らしさの整理
アプリの特徴とは、言い換えれば、そのアプリが他のアプリとどう違うかです。どう違うかをアプリの開発や運用、プロモーションを通して、ユーザーに伝えていきます。 これは他と違ってより良い、他と違ってより信頼できる、そういったブランド育成の文脈と見なすことができます。
あるブランドに対するイメージ、つまり「あのアプリらしい」と感じられる状態を作るためには、「あのアプリらしい」という感覚を言語化する必要があります。 意図的にブランドのイメージを作り上げたケースは別として、大抵の場合、ブランドのイメージは開発者とユーザーの相互作用の中で形成されます。アプリがユーザーに受け入れられていく中で、当初の計画にはなかった機能、アプリの特徴が磨かれていきます。この結果として、開発者はブランドのイメージを、アプリの中から見つけ直す必要が生じます。
こうして見つけられたアプリのらしさを、言語化し整理すること。つまりアプリの中かららしさを抽出し、それらを開発に利用できるようにすること。 この取り組みによって、アプリのらしさを運用するシステムが構築されます。 一度システムを作れば、あとはその純度と精度を高めていく作業に取り組むことができます。
この文脈では、システムの完成度を高めていく中で、よりらしさが明らかになることが志向されます。 らしさがアプリの機能(ex. フォローできる、創作できるなど)に結びついている場合には、機能の特徴やあり方も、らしさを表現するために整理されます。 つまり、アプリは機能によって構築されますが、機能を構築する概念としてのらしさが発見される、ということです。
こうして、らしさを軸としたシステムが作られ、そのシステムの一部としてデザインシステムが生み出されます。 らしさをベースとしたデザインシステムの目的は、アプリのらしさを表現することです。
では、1つのチームが複数のアプリを提供している場合には、どのように考えられるでしょうか？ 例外のケースがあるものの、通常では、同一の機能を複数のアプリで提供しません。と言うのも、同一の機能を持つアプリをリリースしてしまうと、市場で食い合ってしまうためです。 結果として、先述のらしさを機能が搭載されていることや、機能の実現方法で表現することは、困難なものとなります。
複数のアプリでらしさを共有するためには、機能ではなく体験から、らしさのシステム化に取り組む必要があります。 複数のアプリ利用できる、そしてブランドとして軸になるようならしさを抽出すること。抽出したらしさを実現するような、システムを構築すること。 これらが、複数のアプリを跨いで利用できるらしさを軸としたシステムにおいて、重要な観点です。
らしさによる差別化のメリットとデメリット
らしさを軸としたデザインのシステム化は、アプリを概念的に捉え直し、抽象的な概念を取り出します。 出来上がったシステムは諦念であるため、らしさを表現するための実態として、実装のルールや利用可能なコンポーネントを記述します。 アプリから抽象的な体験を導き出し、具体的なアプリを再定義する、というフローです。
らしさによる差別化は、抽象的な体験、つまり印象レベルでの差別化を実現します。 ユーザーに好まれる印象を作ることができれば、認識されやすく、また信頼されやすいアプリを構築できます。ブランド認知としては、非常に好ましい状況です。
一方で、体験がらしいことを志向すると、他の体験からより独立することを志向していくことになります。 独立していると、他のアプリで学んだ知識を利用できません。つまり、ユーザーがアプリに合わせる必要が生じます。 別の言い方をすれば、ユーザーがアプリらしさの世界に入る必要が生じてくる、ということです。
この傾向は、新規ユーザーに対して、高いハードルを生み出すことがあります。 程度問題ではありますが、ユーザーがアプリに合わせるための学習になる。利用に際して必要な、マインドセットの構築が必要になる。こういった事例が発生します。
「この世界観は私向きではない」や「利用するために手間が多く難しい」といった感想を持ったユーザーは、アプリを利用することを諦めるかもしれません。 このようなユーザーの脱落は、アプリの成長にとってマイナスになりうります。
利便へのシステム化
ある操作や手続きがかんたんであること、使いやすいと感じる条件はいくつかあります。 今回は、その中の次の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択になります。後者は学習や維持のコストが高いため、熟慮の上で対応を行う判断をするべきです。
これからはアプリのらしさが色や大胆な独自コンポーネントではなく、体験や標準コンポーネントの細かなカスタマイズになるのでは、と個人的に思っています。 こういった調整に力を発揮できるよう、エンジニアも学ぶ領域を広げていく必要があるのではないかなと。どんどん学んでいきましょう。
