コロナ禍で加速している印象がありますが、ウェブやモバイルアプリケーションは、日々の生活に欠かせないものになりました。 スマートフォンの普及率は、調査による差はありますが95%を超えているようです。*1
スマートフォンの上で利用できる、ウェブやモバイルアプリケーションは、あらゆる人が使う時代になっています。
ウェブやモバイルアプリケーションは、UIが重要な役割を果たします。どれだけ素晴らしい応答性や安定性、機能を誇っていても、ユーザーが操作できなければ価値が伝わりません。
近年、このUIの構築にデザインシステムを活用する事例が増えています。特にfigmaを活用するケースが主流となり、さまざまな事例を参考にできます。
そんなデザインシステムについて、いくつかの思いつきがあったので、文章にまとめます。
書き上げてみたら、結構長い文章となりました。 前半はアプリケーションの品質とデザインシステムの関係について、後半はだれでも使えるアプリケーションとデザインシステムについて、それぞれ意見をまとめています。
デザインシステムと品質
主観になりますが、デザインシステムに関連する意見の多くは、どのように構築するかといったものです。 ただ、筆者の関心はデザインシステムという仕組みにそのものにあります。このため、本ブログでは、デザインシステムの構築については触れず、デザインシステムの仕組み部分に関して考えていきます。
となると、まずデザインシステムという概念についての定義が必要です。 厳密に扱うわけではないのですが、ざっと調べた印象として、英語版のwikipediaがお手軽に言語化された概念を紹介しているように思います。
特に面白いなと思うのは Advantages に記載されている箇所です。引用します。*2
- Streamlined design to production workflow.
- Creates a unified language between and within the cross-functional teams.
- Faster builds, through reusable components and shared rationale.
- Better products, through more cohesive user experiences and a consistent design language.
- Improved maintenance and scalability, through the reduction of design and technical debt.
- Stronger focus for product teams, through tackling common problems so teams can concentrate on solving user needs.
ざっくり訳します。*3
- デザインから製品までのワークフローを合理化する。
- 部門横断チーム間およびチーム内で統一された言語を作成する。
- 再利用可能なコンポーネントと共有された理論的根拠により、開発を高速化する。
- より一貫性のあるユーザー体験と一貫したデザイン言語による、より良い製品の提供する。
- デザイン負債と技術負債を削減し、保守性と拡張性を向上する。
- (デザインシステムが)一般的な問題に取り組むことで、開発チームがユーザーニーズの解決に集中する。
デザインシステムが達成することを考えてみると、この内容に違和感はないと思います。一方で、この文章はより一般的な事柄、つまりアプリケーション開発そのものについて述べているようにも思えてきます。
振り返って考えてみると、デザインシステムは、アプリケーションの開発を助けるものです。また、アプリケーションの魅力を高めるための活動をするものでもあります。 これは、アプリケーションの品質に関する活動、つまりデザインシステムがアプリケーションの品質(QCD)をコントロールする、1つの手段と言えるのでないかなと。*4
Quality、Cost、Delivery (QCD)
一般的な議論としてはwikipediaを、ソフトウェア産業における議論はSHIFTさんの紹介が良さそうに思います。
QCDは工場における製造の文脈からスタートしています。しかし、本質的には製品の価値の話をしていることもあり、ソフトウェア産業においてもQCDの議論は有効だと思います。 日々の開発や開発計画の中でも、QCDの優先度やバランスを取る話題は、頻出しているはずです。
デザインシステムの利点に話を戻します。
記載されている項目をみると、これはデザインシステムを作るというコストを払うことで、再利用可能なコンポーネントと共有された理論的根拠により、開発を高速化すると言えそうです。 また、より一貫性のあるユーザー体験と一貫したデザイン言語による、より良い製品の提供するはQの高め方の話と読めます。
まとめると、デザインシステムの利点は
- Qをどのように定義するか、高めるか
- Dをどのように早めるか
- QとDを高めるためのCはいかほどか、どのように削減するか
を述べているのではないか、というのが筆者の意見です。
そして、この立場になると、デザインシステムの重要性がよりますように感じます。 デザインシステムをどのように作成し運用するかは、アプリケーションそのものへの働きかけです。そして、アプリケーションの品質に対して、直接的にアプローチできる試みでもあります。アプリケーションに関わる、すべての人が関心を持つべき話題なのではないでしょうか。
デザインシステムとQuality
品質に関しては、多く議論があります。 今回は、顧客満足に焦点を当てた狩野モデルを参照します。顧客満足に焦点が当たっているというのが、モデルを選択した主な理由です。顧客満足、みんな大好きですよね。
狩野モデルでは、製品の品質を5つに分解します。 詳細は、SHIFTさんの解説ページをご覧ください。*5
筆者の理解では、デザインシステムが提供する品質は、魅力的品質と一元的品質、当たり前品質をカバーします。 ユーザーにとってあってもなくても良い無関心品質、あると逆に満足度が下がる逆品質は、デザインシステムとして提供するべき項目ではありません。*6
デザインシステムと一元的品質
一元的品質は、あると嬉しく、ないと不満に感じるものです。
ウェブやモバイルアプリケーションであれば、製品の信頼性や安定性、使いやすさなどが含まれます。 おそらく、製品が提供しているサービスの価値そのものも、この一元的品質に該当するはずです。
デザインシステムとの関連を考えてみると、多くの要素が該当するはずです。というのも、デザインシステムはサービスを成立させるために存在するので、一元的要素に関連しない要素ありません。 とはいえ、一元的品質に当てはまるものを考えていると、全てが一元的品質に思えてきてしまうのも事実です。
このため魅力的品質と当たり前品質に含められないものや、魅力的品質と当たり前品質の双方に含まれてしまうものを、一元的品質として扱います。例えば、デザインシステムが提供するコンポーネントの網羅性や安定性、といったものは一元的品質と言えるのではないでしょうか。
デザインシステムと魅力的品質
魅力的品質は、なくても構わないが、あると嬉しいものです。
改めて筆者の意見であることを明記しますが、デザインシステムのデザイン要素は魅力的品質に該当すると考えています。 ブランディング、印象的なアニメーションやスタイルガイドによる統一感などを、ここでは想定しています。
筆者がこれらを魅力的品質と考えるのは、ない場合にユーザーが気づくことができない、という特徴があるためです。 例えば、コーポーレトブランディングの一環で、特徴的な色を定めていたとします。しかし、それがアプリケーションで利用されていなくとも、ユーザーは何がないのかに気づくことができません。あると満足感が高まるが、ない場合に気づかれず下がらないという意味で、魅力的品質に合致すると考えています。
デザインシステムと当たり前品質
当たり前品質は、ないと不満に感じ、あっても満足度を上げないものです。
こちらも改めて筆者の意見であることを明記しますが、デザインシステムのアクセシビリティ要素は当たり前品質に該当すると考えています。 筆者がアクセシビリティを当たり前品質と考えるのは、ない場合にユーザーが製品を使えなかったり使いにくいと感じるためです。
すこし、解説を加えます。
WCAG 2.1で定義されている4つの原則は、次のとおりです。
- 知覚可能 - 情報及びユーザインタフェースコンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
- これは、利用者が提示されている情報を知覚できなければならないことを意味する (利用者の感覚すべてに対して知覚できないものであってはならない)。
- 操作可能 - ユーザインタフェースコンポーネント及びナビゲーションは操作可能でなければならない。
- これは、利用者がインタフェースを操作できなければならないことを意味する (インタフェースが、利用者の実行できないインタラクションを要求してはならない)。
- 理解可能 - 情報及びユーザインタフェースの操作は理解可能でなければならない。
- これは、利用者がユーザインタフェースの操作と情報とを理解できなければならないことを意味する (コンテンツ又は操作が、理解できないものであってはならない)。
- 堅牢 (robust) - コンテンツは、支援技術を含む様々なユーザエージェントが確実に解釈できるように十分に堅牢でなければならない。
- これは、利用者が技術の進歩に応じてコンテンツにアクセスできなければならないことを意味する (技術やユーザエージェントの進化していったとしても、コンテンツはアクセシブルなままであるべきである)。
この4つの原則を気にするべき、という意見に異論はないと思われます。 難しいのは、人によって不足してると感じるレベルが異なってしまう点です。
例えば、自分のようにアプリケーション開発に従事している場合、操作ガイドが不足していても理解できてしまうことがあります。もしもアプリケーションエンジニアが利用することを想定するサービスであれば、操作ガイドはほぼなくとも、誰も困らずに利用できてしまうかもしれません。
一方で、例えば色の微妙な違いが、ユーザー状態を表現しているような場合、アプリケーションを期待通りに操舵することができなくなる、かもしれません。筆者は軽度の色弱をもっているので、本当に微妙な色の違いで表現された場合には、困ってしまうかもなと思っています。*7
先述の通り、利用者が特殊な理由で限られている場合には、検討するべき項目は少なくなるかもしれません。しかし、より多くの人がアプリケーションを利用する現在では、より多くの人を想定したアプリケーションの開発が必要になります。 この意味で、アプリケーションの品質として、アクセシビリティが当たり前品質に該当すると、筆者は考えています。
魅力的品質と当たり前品質
ウェブやモバイルアプリケーションにおいては、まず機能性が求められます。その上で、他のサービスとの差別化が重視されます。 というのも、大抵の場合、あるサービスは他のアプリケーションと比較されます。この時に、自らのアプリケーションを選択されるために、特徴や独自色に関心が集まります。
とすると、製品における一元的品質や魅力的品質に関して注目が集まることとなります。
魅力的品質と当たり前品質のバランス
色の選択は魅力的品質と当たり前品質、つまり製品の特徴とアクセシビリティが最も衝突しやすい領域です。
理解しやすいことや操作しやすいことは、大抵の場合両立します。むしろ、独自のコンポーネントを解決することで、問題が解決するのがアプリケーションのあり方の一つです。 支援技術を含むユーザーエージェントと独自性については、後ほど別の文脈で扱うので、一旦避けます。
2024年現在、アプリケーションで利用する色については、いくつかの観点からコントラストを検討する必要があります。
このような事情を踏まえると、表現が難しいのですが、アクセシビリティの確保のために、ブランディングで定めた色が利用できないケースが生じます。ブランディングの一環で定めた色の組み合わせでは、十分なコントラストが確保できないことがある、ということです。
言い換えると、魅力的品質としての色のコントロールと、当たり前品質としての色のコントールの間で、調整を行うケースがあるということです。
個人の開発や公的な活動であれば、このバランスは当たり前品質を優先するという判断がしやすいでしょう。特に公的機関で言えば、当たり前品質を優先しない理由がありません。
一方、商業的な文脈では、非常に難しい判断が迫られます。 どちらも優先するべき項目であり、可能な限り両立させたいはずです。*8
複数の選択肢
筆者は、複数の選択肢を提供することが当たり前になることで、この状況が改善しないかなと思っています。 バランスをとった1つの解を見つけるのが難しいのであれば、重視するものに応じた、複数の選択肢を用意する必要があると考えています。
現在のデザインシステムには、デザイントークンの概念があります。このデザイントークンは色指定のコミュニケーションコストを下げる仕組みであると同時に、複数の色のパターンを、アプリケーションに適用できる仕組みです。
身近な例としては、VSCodeやGitHubのテーマ選択機能が思い浮かびます。 表現したい配色とアクセシビリティを考慮した配色、そのどちらも選べることで、より多くのユーザーが快適に利用できる状況が作られています。
大前提としては、アクセシビリティを考慮した開発を行うこと。そして、何らかの葛藤が生まれる箇所においては、複数の選択肢をサポートすること。これらが、魅力的品質と当たり前品質のバランスを獲るためには、必要なのではないでしょうか。 そして、それらを実現できるのが、ウェブやモバイルアプリケーションです。そして、サポートするのが、システムとしてのデザインシステムだと感じています。
システムとしてのデザインシステム
デザインシステムは、アプリケーションに一貫性を与えます。 このため、デザインシステムがアクセシビリティを考慮している場合、そのデザインシステムにより構築されたアプリケーションは、アクセシビリティが考慮されたものに。 逆に、デザインシステムがアクセシビリティを考慮していない場合、デザインシステムと衝突を起こしながらアクセシビリティを考慮する事態に陥ります。
システムとしてのデザインシステム、そのデザインシステムを採用することで(苦労なく)ある目的が達成されるモノとしてのデザインシステム、そのものを考えていきます。 あるデザインシステムを採用することで、QCDをある方向性持ってコントロールできるようになる、そんなシステムについて後半では考えていきます。
デザインシステムが利用できる状態であること
政府組織のデザインシステムは、それぞれが目指している地点も似通っているため、違いが明確です。 細かな違い、例えばUSAの場合は法案が元になっているなどあるのですが、ここでは詳細は省きます。 重要なのは、どのデザインシステムもあらゆる人が利用できることを目指している、という点です。
3つのシステムを見比べた時、最も違うのは、コンポーネントが即座に利用可能であるかどうかです。 USAとUKのデザインシステムは、所定の準備をすれば、そのままWebページに適用できる状態になっています。
Japanのデザインシステムは、figma上でデザインデータを配布しています。 コンポーネントは配布されておらず、動作は確認できません。*9
なお、figmaのデザインデータはUSAのデザインシステムでも提供されています。UKにおいては、筆者がページを確認する限り見当たりませんでした。
コンポーネントが提供されている最大に魅力は、デザインシステムを紹介するページの中で、動いているコンポーネントを触れる点です。 次の2つのページを開き、コンポーネントを操作してみてください。
コンポーネントのページと、figmaの上にあるデザインデータのページの間には、小さくて大きな違いがあります。
コンポーネントのページは、実際に動かして理解できます。 このため、デザインシステムに関わる人全てに働きかけやすいでしょう。 ウェブページの開発に習熟していなくとも、採用のイメージがしやすいと思われます。*10
さらに、アクセシビリティの点でも大きな違いがあります。 ブラウザ上で動作するということは、アクセシビリティの補助機能を確認できます。 このため、デザインシステムの導入前後で利用者の体験がどう変わるかを確認しやすくなり、なぜ必要なのかを理解しやすくなります。
そしてコンポーネントがnpmなどで提供されている場合、デザインシステムが更新された時に、その更新を取り込むことが容易になります。 USAとUKのデザインシステムのページを読み進めていくと、デザインシステムが変化することが前提となっています。USWDSの場合には、すでにバージョンが3.0になっていることからも、明らかです。
コンポーネントの提供がなされることは、デザインシステムが目的を実現する上で、非常に大きな意味を持ちます。
ターゲットとなるプラットフォーム
デザインシステムがコンポーネントを提供するためには、どのプラットフォームをターゲットにするかを決める必要があります。 理想的には、ユーザーが利用するプラットフォーム全てに対応することが望ましいところですが、この対応は非常に困難です。
広く世に出回っているデザインシステムを見ると、コンポーネントを提供しているものは、大抵の場合ウェブをターゲットにしています。 これはユーザーが利用するOSなどの環境を(ある意味で)問わず、広く利用されるためです。 古い端末、古いOSであっても、ウェブブラウザが動作すればウェブページは表示することができます。*11
ウェブ以外のターゲットとして、WindowsとiOS、そしてAndroidのネイティブアプリケーションがあげられます。 これらのプラットフォームに対応するアプリケーションを作る、つまりOSが提供しているデザインシステムの上で成立するデザインシステムを作るケースを確認します。 なお、大抵の企業は、ウェブ向けのデザインシステムを公開していることをここに添えておきます。いくつかの理由はあると思われますが、大抵の場合、オープンになるのはウェブ向けのみです。
Apple
Appleは、自社製品に対応するデザインシステムを提供しています。
Human Interface GuidelinesはApple製デバイス向けアプリケーションのガイドラインです。*12 コンポーネントとして、UIKitとAppKit、そしてSwiftUIが提供されています。(watchOSは一旦スキップして話を進めます。) ちなみに、ウェブ向けのコンポーネントは提供されていません。Appleのデザインシステムは、Appleの世界の中でアプリケーションを作るためのものです。Apppleではない開発者が、ウェブ向けにApple製のデザインシステムを使うことは想定されていないのでしょう。
Appleのケースは、そもそもプラットフォームを提供する大変さを示しています。 現在、AppleはmacOSとiOS、そしてvisionOS(とwatchOS)を提供しています。このため複数のコンポーネントを、Appleのためにも構築する必要があります。 さらに、これらを構築するだけではなく、自社製のXcodeで利用できるようにし続けなければなりません。
この状況を俯瞰すると、SwiftUIがApple製プラットフォームのどこでも利用できるという特徴は、示唆的です。
デザインシステムの更新を各プラットフォームに対して適用するためには、プラットフォームに対応するコンポーネントを整理する必要が生じている、ということなのではないでしょうか。 それぞれのプラットフォームに特化したコンポーネントを作ること、並びにそれらのコンポーネントを運用し続けることは、プラットフォームが増えれば増えるほどコストがかかるようになります。 HIGがApple製デバイス向けアプリケーションのデザインシステムであることに呼応した、Apple製デバイス向けのコンポーネントとしてのSwiftUIが存在する、そのように見做せると筆者は考えています。
Googleは、広く利用できるデザインシステムを提供しています。
Material Designは、対象を利用者とした広いターゲットを持つデザインシステムです。 コンポーネントとしては、Android向け、Flutter向け、そしてWeb向けが提供されています。
iOS向けのコンポーネントは、かつて提供されていましたが、現在ではメンテナンスモードになっています。 実装内容を見てみると、Material Designに従ってUIKitを拡張しているものになっています。いくつかPRを眺めてみると、大変さがわかりやすいです。
時期的にMaterial Deisng 3(M3)の発表前後であり、iOSの開発がSwiftUIへ移行する流れもあったため、開発リソースが確保しきれなくなったのではないかと思います。 READMEには、Material DesignをiOSで利用する方法としてFlutterが紹介されています。
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.
Alternatively, Flutter enables you to get a Material look and feel across all platforms.
Material Designは、リリース時から複数のプラットフォームを想定したデザインシステムです。 最初のリリースである、Material Design 1(M1)から、次のような複数のプラットフォームを想定した紹介が存在します。
また、Material DesignはMaterial Designをベースに、独自のデザインシステムを構築することを想定しています。 特にMaterial Design 2(M2)からは、Material Themingという機能が提供されるようになりました。 この仕組みは、GoogleもMaterial Designを採用する1つのユーザーであること、つまりGoogleのデザインシステムをMaterial Designを使って構築することを想定しています。
コンポーネントの提供について。 M1ではAndroidのみでしたが、M2からはiOSとWeb向けのコンポーネントも提供されました。FlutterもM2をサポートしていたので、都合4つのプラットフォームをサポートしていたこととなります。
この試みにより、Material Designは複数のプラットフォームをサポートするために必要な知見を蓄積してきたと言えるでしょう。 iOSのコンポーネント開発をメンテナンスモードにする判断は、この知見の上に成り立っていると考えるべきではないでしょうか。 つまりHIG準拠のコンポーネントの上に、Material Designを載せて提供することは、コストが見合わないと判断されたのではないでしょうか。 実のところ、iOS向けのGmailアプリケーションのライセンスを見ると、Material Coponents for iOSを利用しています。このため、iOS向けのMateril Design ComponentsはGoogle社内用のツールになったのではないかなと。*13
複数のプラットフォームに適応するデザインシステムは、プラットフォームが標準的に定めているデザインシステムの影響を受ける、ということがGoogleのデザインシステムからわかります。
Microsoft
Microsoftは、Fluent 2を公開しています。 このデザインシステムは、複数のプラットフォームをターゲットにしており、開発はオープンに進められています。
対応しているプラットフォームは、Start developing](https://fluent2.microsoft.design/get-started/develop)にある通りWeb、iOS、Android、Windowsです。 iOSのリポジトリを見た感じ、iOSと言いつつmacOSもサポートしている様です。 MicrosoftのGitHubリポジトリを確認すると、WebやAndroid、そしてblazor向けの実装が公開されています。おそらく、Windows向けの実装だけはPrivateな環境で開発されているようです。
面白いのは、iOSとそれ以外(Web向け)で一部の設定が異なる点です。 次のサイトにある、図をご覧ください。
To streamline our complex system of assets and keep each file as useful as possible, each platform-specific UI kit contains styles specific to that platform. For example, the San Francisco type ramp is only in the iOS UI kit.
Values and ramps shared across platforms, like shadows and shared colors, are linked to each UI kit through the Fluent 2 design language.
以上の様にFluent 2は、多大な努力でもって複数のプラットフォームをサポートしています。 もちろん、figmaのプラグインも提供されています。上記の通り、iOSとそれ以外(Web向け)の2つのテンプレートがあります。
開発の徹底ぶりは、コードからも伺えます。
例えば、次のクラスはAndroid用のButtonクラスです。
import文を眺めてみると、極力androidx.compose.materialを利用せず、androidx.compose.foundationやandroidx.compose.uiを利用しています。
これはMaterial Designの影響を極力抑えながら、Fluent 2のコンポーネントを実装していると言えます。
なお、iOSの場合にはUIKitのUIButtonを利用しています。
以上を眺めてみると、Microsoftがかけている労力の多さが伺えます。 非常に雑なことを言ってしまえば、React Native向けのコンポーネントを作っているため、AndroidやiOS専用のコンポーネントを作る必要性は薄そうです。 macOS向けも、Electronを使ってReact用のコンポーネントを使い回せそうに思えます。
一方で、この労力の割には、一般の開発者がFluent 2を使うことを後押しするような仕組みがない様に思います。 MediumやMicrosoft DesignにはFluent 2の紹介はありません。リリースに伴う動画はありますが、開発者向けのチャンネルで公開されています。*14
すこし、不思議なデザインシステムです。
複数のプラットフォームをサポートするコスト
各社のデザインシステムを確認すると、複数のプラットフォームをサポートするコストの高さが見えてきます。
第1に、デザインシステムを複数のプラットフォーム上で成立するように構築しなければなりません。 この対応には、Material Designのようなデザイン言語を0から作り上げるか、Fluent 2のようにプラットフォームに合わせたカスタマイズを行う必要があります。 複数のプラットフォームに精通する必要あるため、非常に難度が高い作業になります。
第2に、複数のプラットフォーム向けのコンポーネントを作成する必要があります。 各社、オープンに開発しているものもそうでないものもありますが、どちらにせよ、対応するべきプラットフォーム用のコンポーネントが必要です。 このコンポーネントは、プラットフォームの発展に応じてメンテナンスを行う必要もあります。専任のメンバーが必須になるでしょう。
そして、第3に利用を促すための教育、ドキュメントが必要です。 デザインシステムを利用するためには、そのデザインシステムの使い方を理解する必要があります。 またコンポーネントを活用するためには、デザインシステムの目指す方向性を把握できる環境が必要です。 デザインシステムは、利用される期間が長くなればなるほど、より多くの人が利用するようになるものです。このことを踏まえた準備が、デザインシステムの運用に求められます。
以上のように、複数のプラットフォームをサポートするデザインシステムは、非常に高いコストがかかるものです。 このため、筆者は独自のデザインシステムを組む場合は、Webのみをターゲットにするべきだと考えています。*15 というよりも、大企業でなければ、複数のプラットフォームをサポートするデザインシステムは運用できません。 独自のデザインシステムを展開する場合には、React NatievやIonicのようなフレームワークを検討するべきだと思います。 もしもプロダクトがWindowsやAndroid、iOSやmacOSに特化している場合には、そのプラットフォーム向けのデザインシステムを採用するべきだと言えます。
例外的なのは、FlutterとMaterial Designの組み合わせです。 FlutterはMaterial Designをベースにしたフレームワークです。*16
Flutterによるアプリケーションを開発すると、複数のプラットフォームに向けた開発の課題をFlutterが吸収してくれます。 Material DesignがMaterial Designを採用しやすい環境を作ることを目指しているため、このような状況になっていると、筆者は捉えています。*17
ただ、大抵の企業はFlutterを作り出せないため、非常に特殊な例として観察するべきです。
独自のデザインシステムとアクセシビリティ
もしも、コストをかけずに複数のプラットフォームに対応するデザインシステムを作ったとすれば、何が起こるのでしょうか？ 筆者は、先述の当たり前品質が犠牲になる、つまりアクセシビリティが犠牲になると考えています。
大抵の場合、プラットフォームが提供するアクセシビリティの機能と、プラットフォームがベースとするデザインシステムの親和性が高くなっています。 これはベースとなるデザインシステムをガイド通りに利用していれば、ある程度のアクセシビリティが確保されるということです。 逆に言うと、ガイド通りに利用されない場合には、アクセシビリティを考慮した実装を行わなければならないことがあります。
例えば、Fluent 2のButtonコンポーネントは、内部で.semanticsの設定をしています。
十分な時間やリソースがあれば、こういった実装を適切に行う余裕はあります。しかし、コストをかけずに動くものを作った場合には、これらの実装が犠牲になる恐れがあります。
アプリケーションの品質としてアクセシビリティを考慮するのであれば、安易に複数のプラットフォームをサポートするデザインシステムを作ることは、避けるべきです。 もしも複数のプラットフォームをサポートするのであれば、それぞれのプラットフォームごとのデザインシステムを適度にカスタマイズするか、単一のデザインシステムを無理なく複数のプラットフォームに展開できるツールを採用するべきだと思います。*18
デザインシステムとだれでも使えるアプリケーション
まとめです。
本ブログでは、デザインシステムをアプリケーションのQCDをコントロールする手段として位置付けました。 また狩野モデルにおける魅力的品質と当たり前品質を、それぞれデザインシステムのデザインとアクセシビリティに当て嵌め、そのバランスについて議論しています。 特に色の選択においては、この2つの品質が衝突するのではないか、という危惧を抱いています。とはいえ、複数の選択肢を持つことで、このバランスを取る道はあるはずです。
次に、デザインシステムが対応するプラットフォームの数について、特にOSを提供している企業のデザインシステムから検討しました。 筆者は、複数のプラットフォームに真の意味で対応することは難しく、またコストを削るとアクセシビリティが犠牲になる恐れがあると考えています。 このため、複数のプラットフォームをサポートするデザインシステムを作るのは避けるべきです。
もしも複数のプラットフォームに対して、デザインシステムやコンポーネントを共通で扱いたい場合には、React NativeやFlutterといった選択肢があります。 それぞれにメリットとデメリットがあるので、適切に選択し、ユーザーに対して誠実なアプリケーションを作ることが重要です。
*1:https://www.moba-ken.jp/project/mobile/20230410.html
*2:https://en.wikipedia.org/wiki/Design_system#Advantages
*3:誤訳でないといいのですが。
*4:このように捉えると、デザインシステムを広く考えられるのではとふと思いついた、というのがブログを書くに至った経緯です。
*5:参照しやすいページがSHIFTさんのサイトになるのも、ちょっと示唆的だなと思っています。
*6:概念的な話をしています。
*7:今のところ、日常生活で困ったことはありません。
*8:筆者としては、この対立構造をより重んじる/軽んじるのような軸では語りたくありません。
*9:開発を進めているところなのかもしれません。
*10:実際には、デザインシステムで導入までのステップが示されています。
*11:セキュリティを考えると、最新の環境で利用して欲しいのですが、ここではその話はしません！
*12:The HIG contains guidance and best practices that can help you design a great experience for any Apple platform.
*13:iOS向けのGoogle製アプリは、Javaのライブラリなんかも入っていて不思議なんですよね。
*14:動画の再生回数も、決して多いとは言えません
*15:デジタル庁もこの方向で進んでくれたらいいなと思っています。
*16:Flutterのコンポーネントを作るにあたり、Material Designをlanguageとして採用している点を指しています。
*17:"Material Design is an adaptable system of guidelines, components, and tools that support the best practices of user interface design. "より。
*18:なおFluent 2をベースにすることで展開は可能です。
