最近、デザインシステムの導入をどうするかという話をしてました。 自分はAndroidアプリ開発から入って、iOSアプリ開発をSwiftから始めてFlutterでやっているので、経歴が異なる方と話すと面白かったです。
そんな直近の話を踏まえてのブログ。
これまでのはなし
Material Youを見た時に感じたのは、「デザインシステムの重さを理解していなかったな〜」でした。 デザインシステムを、単なるアプリケーション作成を助けるためのライブラリ程度、としか捉えられていなかったことが悔やまれます。
とりあえず、話を始めるためにデザインシステムの定義から引用していきます。
デザインシステム：デザインの基準やドキュメント、原則に加えて、基準を達成するためのUIパターンやコンポーネントなどのツールキットをすべて備えたもの。
本ブログ内で用いる「デザインシステム」は、引用した内容として扱っていきます。 もしも文中で文意がズレていたり、誤用があった場合には、筆者の理解不足に起因するものと捉えてください。
スマートフォンアプリのデザインシステム
AndroidやiOSのアプリを開発しようとしたとき、参考にするのは次の2つのドキュメントです。
参考にすると言っても、その実態は「従う」とでもいうべきものです。 たとえば「ここはFABにしましょう」と提案があれば、FABのドキュメントの目的から利用方法まで従うことになります。 むしろ「その機能はFABで実装するべきか」を議論し始めるかもしれません。
iOSエンジニアであれば「日付の選択をさせたい」となればピッカーを提案するでしょう。 そのあとは、OSのバージョンに合わて動作が異なることを説明の上、対象OSごとにUIチェック依頼がスクリーンショットとともに来るはずです。
スマートフォンアプリのデザインシステム選択
Material DesignとHIGのどちらに従うか、どう取り入れるかは各チームに任せられています。 2021年5月現在、AndroidでiOSライクなUIを持つアプリを提供することも、iOSでAndroidライクなUIを持つアプリを提供することも禁止されていません。
「AndroidのデザインはiOSと同じで!」と言われる環境が多かったこともあり、2つの環境を比較参照している記事などがあります。 *1 筆者の印象ではHIGをベースに、プロジェクト用の「デザインシステム」を作り開発していた環境が多いのではないでしょうか。
代表的な記事は次のようなもの。
またMaterial Designも近い記事を出しているので、色々な環境で同じ話が起きていると思われます。
Webとスマホのデザインシステムの違い
WebとAndroid/iOSの文脈で語られるデザインシステムには、微妙な差があります。 私見になりますが、大雑把にまとめると下記2点です。
- 支配的なデザインシステムが存在するか
- スマートフォンを前提としたデザインシステムか
支配的なデザインシステム
個人的な見解になりますが、Webの世界には"支配的な"デザインシステムは存在していません。 ここでいう"支配的"の意味は、「そのシステムに従わないことが、到底考えられない」という意味です。
WebにはW3Cの勧告があり、その中にはアクセシビリティなどに対する言及などはあります。 しかし、それはスマートフォン向けのデザインシステムほど"支配的"ではありません。 *2
Webの世界には支配的なデザインがないため、デザインシステムはより"自由"な印象があります。 一例として、iOSのTypographyの制約と見比べてみます。
iOSで標準的に扱うことができるfontなどは、次のドキュメントにまとめられています。
端末設定に応じて、細かくfontサイズが調整されているのが見えます。 端末の設定は端末内の全てのアプリに反映されるもののため、fontをカスタマイズするのであれば、これらの設定分は調整が必要になるでしょう。
このため、例えばIBMのCarbon Design Systemを導入しようとすると、まずfontの設定からつまずくことになってしまいます。
なお、fontをアプリに埋め込むことはAndroid/iOSともに可能です。 OSバージョンや端末の違いを加味すれば、実現できないことはありません。
現実的には、開発とテストの工数を考えた場合に、fontを細かくコントロールするのは厳しいものがあります。 元々もの制約の強さと、細かくカスタマイズした際のコストを考えると、OSが提供したり則っているデザインシステムを採用する方向に力が働きます。
実際にAndroidであれば、Material Designのfontをカスタマイズする手法をとると、fontを独自のものに差し替えることは簡単にできます。 もしもGoogle Fontsに登録されているものであれば、数分で実装は完了します。
このように、本質的にはデザインシステムそのものの力でなくとも、デザインシステムを選択する際に圧を感じる場面は多くあります。
スマートフォンを前提としたデザインシステムか
スマートフォンアプリのデザインシステムに従うと、「Android/iOSが想定するスクリーン上で操作する」ための制約に従うことができます。
例えばWeb向けのページをスマートフォンで開いたときに、「テキストリンク」をタップしようとして、困ったことはないでしょうか? 有名な話になりますが、いわゆる「テキストリンク」は文字サイズ分のタッチ領域しかないため、指でタッチするには向いていません。 スマートフォン向けのデザインシステムでは、このような事情を加味した"最低限保持すべきサイズ"のような概念を提供してくれています。
また、スマートフォンには「右クリック」が存在しません。 このため、オプションを「右クリック」で表示するようなUIは取れないため、リストの要素を左右にスワイプする仕組みなどが導入されます。 このような「動き」を、スマートフォン向けのデザインシステムはサポートしています。
もしもこの項目をサポートしていないと、アプリごとに「動き」を規定することになり、ユーザーを大いに混乱させてしまうことが予想されます。 この項目までカバーしているデザインシステムは、スマートフォン向けOSを開発しているチームに近い、デザインシステムが提供している印象があります。
デザインと実装をどう合わせるか
大変嬉しくも悲しいことに、Android/iOS共に様々なディスプレイサイズのデザインを考慮する時代になりました。 単にディスプレイサイズだけのサイズ違いならまだしも、ノッチのような端末ごとの差異まで考慮しなければなりません。 *3 ディスプレイは、常に長方形ではなくなってしまいました。
2021年のGoogle IOでも言及されていますが、「大画面モニター」を求めている声というものは強いようです。
android-developers.googleblog.com
Users are seeing more value in larger screens, and the benefits of doing more with a single device. Apps designed for large screen devices increase those benefits even further.
The ability to fold a screen offers better ergonomics for large devices. When folded, you can fit a tablet-sized screen in your pocket — unlocking utility that was previously unavailable on a portable device. Thinking about our app ecosystem, we’re excited because this is a hardware shift that is driving new expectations around what you can do from a handheld device. We see the demand for larger screens extending to tablets too, which have greatly increased in popularity, given the similar app experience.
スマートフォン向けのUIデザインと言っても、段々とタブレットやPCのブラウザで表示することを想定せざるをなくなっています。 もしもスマートフォンだけ考えていても、Andoridは折り畳みディスプレイなども登場し、多様性を増しています。
近い将来、日本刀のようなディスプレイも登場するかもしれませんね……。
www.slideshare.net多様な端末は、デザインと実装に負担をかけます。
一部の潤沢なリソースを持つチームでもない限り、全ての端末に合わせたデザインを用意できません。 作成したとしても、端末ごとの実装を行うことになり、実装とテストのコストを引き上げます。
「標準的な」デザインを作成したとしても、それが適切に表示されるようにする必要があります。 画面の横幅が大きければ、横幅いっぱいの画像は大きすぎる、そんな問題が発生します。 端末設定で文字サイズを大きくしたら、ボタンのサイズが倍になり画面をはみ出す、そんな不具合報告が上がってきます。 さらに、画面サイズの多様化の延長として、ユーザー操作により、動的に画面サイズを変更するケースも生じてきました。
AndroidはChromBookの上で動作するケースが真っ先に思い浮かびます。 iOSであれば、iPadのSplit Viewを利用している時でしょうか。
これらは個別の実装の問題です。 画面サイズが異なるケースを実装しなければなりません。
複数のプラットフォームをまとめるデザインシステム
印象論ですが、動画のように手法は紹介されていても、実現には困難が伴います。
既存のViewをベースにした、よくあるAndroidアプリを考えてみます。 既存のAndroidのViewは、JavaやKotlinでActivity/Fragmentの振る舞いを書き、レイアウトをxmlに記述します。 Androidには画面サイズに応じてxmlのリソースファイルを読み替える仕組みがあるため、これまではスマートフォンとタブレット向けの別のxmlファイルを用意できました。
しかしこの仕組みは「段階的に静的な値を設定」するための仕組みです。 そのためbreakpoints systemのような、画面の横幅に応じてbodyのサイズが柔軟に変わるシステムは、既存のxmlの拡張の仕方では対応できません。 おそらく、画面サイズの幅に応じた、複数のxmlファイルを全ての画面に用意する必要があります。
宣言的UIという解決策
Android、iOSともにこの状況への解決策として、宣言的UIライブラリを急ぎ導入している印象があります
宣言的UIは「画面サイズが変更した場合」に与えられる画面サイズをベースに、コードをかけます。 この時、与えられた画面サイズの値に応じたSwitch文を書いたとしても、可読性やパフォーマンスを下げることはほとんどありません。
自分が作成したライブラリになりますが、Flutterでbreakpoints systemに対応するライブラリを挙げておきます。 exampleプロジェクトをみていただければわかる通り、「画面サイズが変更したとき、画面は再描画される」ことを利用することで、breakpoints systemに対応できます。
また、下記ツイートのようなアピールポイントも気になるところです。
twitter.comPreferably you would not use AAC ViewModels nor Hilt within your composables because both couple your composables to your platform/application respectively. Build your widgets with the assumption they will be cross-compiled to other platforms and used in other applications. 😉
— Jim Sproch (@JimSproch) May 23, 2021
宣言的UIは非常にシンプルで、合理的で、強力な仕組みだと感じます。 しかしそれ以上に、既存の描画方法ではAndroidの固定されたディスプレイ向けのアプリという資産を、他の環境に持ち込めなかったから、このタイミングで刷新している気がしています。
オープンなデザインシステム
Material Designをはじめ、デザインシステムの中には公開されているものがいくつもあります。
デザインシステムが 基準を達成するためのUIパターンやコンポーネントなどのツールキットをすべて備えたもの。 であるならば、オープンである必要性はあるのでしょうか?
私は語られやすい話と、語られにくい話があると考えています。
- 語られやすい話
- オープンなデザインシステムを採用することで、低コストで高い品質のアプリケーションを提供できる
- デザインシステムに対するフィードバックが活発になり、デザインシステム自体の成長を助ける
- 利用するユーザーがアプリケーションの操作を覚えるための、学習コストを下げる
- デザイナーやエンジニアの流動性を高めることができる
- 語られにくい話
- デザインシステムを採用しているアプリケーションによる、ネットワークを作ることができる
デザインシステムがオープンであると、当然ながらありとあらゆる人が、そのシステムを利用できます。 そして、たとえばGitHubのIssueやGoogle I/OでのAMAなどを通じて、より多くの視点からフィードバックが発生します。 多くのフィードバックが反映されることで、品質が向上する点は見逃せません。
そして、オープンなデザインシステムを採用しているプロジェクトであれば、メンバーとして参加するのが楽になります。 新たに参加したプロジェクトであっても、デザインシステムの用語が利用でき、運用ルールが適用できる状態になります。
デザインシステムが、オープンであることはデザイナーやエンジニアにとって「得」しかありません。 そのため、特にデザインシステムを独自に組み上げるだけの体力が環境でなければ、既存のシステムを採用しない理由がないと言い切っても良いレベルにあります。
このような環境であるため、オープンなデザインシステムをベースとしたアプリが市場に増えます。 言い換えれば、「共通のデザインシステムを採用しているアプリケーションのグループ」が出来上がります。 そのグループの中では、より「オープンなデザインシステムをカスマイズして使う」方法がグループ内で共有されるようになるでしょう。
このグループは、デザインシステムの勢力図と言い換えることもできます。
開発の標準語、Material Designの強さ
「デザインシステムを公開し、多くの人が利用する」という文脈では、対象とされているのはエンジニアやデザイナーでした。 Material Designはコンポーネントの振る舞いから、その利用シーンまで明確に言語化されたシステムです。 この状態は異なる職種間のコミュニケーションを円滑にし、双方から提案ができる素晴らしい状態を作り出します。
非常に感覚的な表現をすると「デザインシステムという共通語」です。
この共通語があると、コミュニケーションが高速に、そして正確になります。 Material Designを例に出せば、Material DesignのURLを共有すれば事足りるようになります。 口頭で議論をしている場合にも、コンポーネントの名前で共通の認識を得ることができるようになります。 エンジニアとデザイナーの間ではMDCの実装とFigmaのPluginのような、認識がズレない仕組みがあります。
このように、Material Designは開発者から見たときに大変フレンドリーです。 これは実感のある話になりますが、特にAndroidエンジニアの場合には、Material Designに頼りたい気持ちが非常に強くなります。 実装する機能の仕様を聞いている際には、「ここはあのコンポーネントで実現しよう」とか「これはあのページを例示すれば良いな」などと考えるようになっていきます。
スマートフォンアプリの開発者から見ると、Material Designは次の2つの点で非常に便利です。
特にダークモードのような、一から実装をすると大変な作業になるシステムを、調整しつつ実装しなくて良いのは大変なメリットです。 AndroidやiOSは1年ごとに新たな仕組みが登場する状況のため、常に学びながら実装を進める必要があります。 大抵の場合、開発者もデザイナーも理解をしながら開発をするため、複雑な状態を適切に管理するのは困難です。
とは言え、最新のOSでついた機能は「納得のできる」理由があって実装されるものが大半なため、実現はするべきものになります。 このような事情を踏まえた時、デザインシステムが標準でサポートしていることは、開発者にとって重要な項目になります。
Material You
ようやく今回のブログの主題です。 Material Youは半月前にアナウンスされた機能となり、Android 12のBetaでしか利用できないため、多分に想定を含んだ話となります。
Material Youは、Material Designにおいて、初めて「ユーザーがカスタマイズ」できる要素として登場した概念です。 つまりMaterial Designの"利用者"であり"開発者"に、一般ユーザーを追加する取り組みだと感じています。
このことは、以下の2つのケースを起こすのではないか、と思います。
- 「Material Youに対応していること」をユーザーが"当然"だと感じるようになる
- 「Material Youへの対応ぐあい」をユーザーが"Material Designに照らし合わせて"評価するようになる
ユーザーが"当然"だと感じるようになる
Androidは市場で大きなシェアを持つプラットフォームであり、公私のどちらのシーンでも利用することがあるシステムです。 iOSが圧倒的なシェアを持っていた日本であっても、現在では"半数"がAndroidを利用しており、影響は大きいと言えます。
Material YouはAndroid 12から搭載される予定です。 かつてはAndroidの新しいOSが出てから市場に新とするまで、4〜5年はかかっていた印象がありますが、最近ではだいぶ改善してきました。 またAndroid 10からはOSの更新を置き換え始めているので、以前ほどアップデートが遅延する環境も修正されつつあります。
Material Youとその後継機能の普及は、想定よりもずっと早くなるのではないでしょうか? それはMaterial Youの利用者、そして活用者を増やし、Androidアプリの"当たり前"にMaterial Youが入ることを意味するのではないでしょうか?
Android OSのような私で使うシステムに入った機能は、その利用者が開発者になった時、実装を"当たり前"のものとして受け入れやすくなります。 「利用者が開発者、企画者になったときに、Material Youを通じてMaterial Designを当然だと感じる」ことにつながるのではないか、と考えています。
結果を考えると、これは「Material Youを通じてMaterial Designを『(デザインシステムにおける)ドミナントデザインにする』試み」をしているのではないかな、と感じます。
"Material Designに照らし合わせて"評価するようになる
Material Youが入るまでのMaterial Designは、基本的にアプリ開発チームが意識するものです。 定義されたコンポーネントについて、一般のユーザーは意識することはありません。 というよりも、意識せずとも自然と使える*4状態が実現されていたため、意識することはまずありませんでした。
Material Youは、一般のユーザーが端末を「自分のもの」として実感する機能です。 それは(現時点では)アプリの色や一部の形をカスタマイズすることで実現されていきます。 この機能は、ユーザーが「このアプリは対応している、適切に実装されている」かどうかを気づきやすくなっています。
また、Material Designの特徴は「言語化されている」ことです。 一般のユーザーであっても「Material Youはどうあるべきか」を理解することは、困難はあっても不可能ではありません。 おそらく開発者やデザイナー向けに「Material Youへの対応方法」などの日本語記事も作成されるため、ある程度は真実味のある話になるのではないかなと思います。
ユーザーから「Material Youに対応して欲しい」という要望が上がったり、「Material Youへの対応が不十分」といった評価を受け取る日が来るかもしれません。 そのようなことが起きるようになれば、Androidの上で動くアプリは*5Material Youに対応できるようにMaterial Designをベースにする、強い理由が生まれることになります。
デザインシステムと向き合っていく
ブログを書くにあたり、今更調べてみるといわゆるTech Giantはデザインシステムを公開し、Figmaのプラグインを無償で提供していました。 完全に見落としていたなーという気分です。
「あるデザインシステムが選ばれるということは、デザインシステムが導入されている環境が選択されやすくなること」ではなかったか、というのが今の思いです。 考えてみると、国内で大手IT企業がデザインシステムの公開を発表しているの、見たことない気がしますし。
調べてみると、USやUK、カナダなどはデザインシステムを公開していました。 国として作成し公開している、というのは二歩も三歩も先を進んでいるなーと思ってしまいますね。
Material Designは「標準語」を目指しているような気がします。
少し前までのAndroid、iOSアプリエンジニアは「似た概念を互いのシステム上のでよく使われる単語を用いて」会話することが常でした。 デザイナーの方はiOSアプリに親しんでいることが多かったので、結果的にiOSの概念ベースとなることの方が多かったように思います。 これは「多くのAndroidアプリでSegmented ControlライクなViewが存在する」ことからも、どこでも起きていたのではないかなと思います。
Material Designが他のデザインシステムに対し、今一歩先に進んだのは「ユーザーがMaterial Designであることを評価しうる」システムを追加したためです。 これにより、今までアプリケーションの開発チーム内で閉じていた「どのデザインシステムを選ぶか、作るか」という関係性に「ユーザーからの要望」が入るようになります。 一面を見れば、これは「デザインシステムが通じる関係者が増えた」という意味でポジティブな評価ができます。 もう一面を見れば、「あるデザインシステムを採用する以外の選択肢が選びにくくなった」という意味でネガティブな評価ができます。 *6
ステークホルダーが増えれば増えるほど、その間で通じる「共通語」は重要になります。 そして、ある一定以上の人が「これを使う」と決めれば、それは「標準語」とでもいうものになるのではないでしょうか?
最後に、Flutterというライブラリを紹介して終わりたいと思います。 ここまでお付き合いいただき、ありがとうございました。
Flutter is Google's UI toolkit for building beautiful, natively compiled applications for mobile, web, desktop, and embedded devices from a single codebase.
*1:日本においてはiOS端末のシェアが高かったことは多分に影響していると思います
*2:筆者はWebを専門にしていないので、実際は違うかもしれません
*3:とは言え、そろそろ最適化することに諦めつつある気もします
*4:そのための学習が端末の利用を通して行われているだけですが
*5:Webページも未来の対象かもしれません
*6:RNやXamarinのようなマルチプラットフォームはMaterial Designを実現するためのシステムではない、という意味です
