デザインシステムの未来は複雑化への対応

Googleが2014年にマテリアルデザインシステムを発表したとき、紙に例えて説明しました。デジタル要素は、デスクの上の書類のように積み上げられ、ユーザーは視覚を頼りにして直感的に情報を精査、選別できました。「マテリアルデザインには物理的な表面や縁があり、つなぎ目や影は、手で触れられるかのように視覚化されています」とデザイン担当VP、Matías Duarte氏は当時説明していました。マテリアルは、2010年代前半に出現した、多数の改良されたデジタルデザインシステムの1つにすぎませんでした。これらのシステムは、ユーザー視点でビジュアルとテクノロジーが洗練されており、スキューモーフィックなユーザーエクスペリエンスは使われなくなっていました。ユーザーは、見るだけで理解することができたのです。

ほぼ10年後、Googleは、コンピューティング環境の拡大を変化の理由に挙げて、紙の例えを捨てました。言い換えると、ユーザーには視覚的な例えが不要になったということです。デジタルエクスペリエンスの導線に対する人々の理解と期待は拡大し、それに伴い、デザインシステムが対応すべきエクスペリエンスの複雑さも増大しています。例えば、新しいフォームファクター、アフォーダンス、アクセシビリティ標準、パフォーマンスの期待などです。さらに、見た目の新鮮さやわくわく感もある程度維持する必要があります。

Appleがスキューモーフィズムと決別してから2年後、Instagramは3Dのカメラアイコンをカラフルなグラデーションの平面アイコンに変えました。この見た目の変化は、同社の優先事項が変わったことでもありました。Instagramは写真を共有するアプリ以上のものとなったのです。その数年後、Instagramはディスカバリー、スポンサードコンテンツやパートナーシップの機能を導入して、アクセシビリティが向上し、ショッピングもできるようになりました。このようなユースケースの拡大は当たり前のことであり、1つのことしかできないアプリを見ることはまれです(WeChatを見れば明らかです)。アプリは、多機能化と高性能化を期待されます。同様に、そのユーザー(とそれぞれのニーズ)はますます洗練され、複雑化すると考えられています。

「現在のデザインは複雑化しており、複数の相互接続されたシステムで、複数の大規模チームが共同で作業することも珍しくありません」とJacob Miller (Figmaプロダクトマネージャー)は自身のエッセイ『Taking cues from code』(コードから手がかりを得る)で述べています。「共同作業には、すべてを整理して理解できるようなソリューションが必要です」。デザインチームと開発チームは、並行して業務を遂行しながら、ユーザーの大きな期待に応える新しい方法を探る必要があると言えるでしょう。

構造化でカオスを抑える

Millerの考えでは、構造主導のソリューションを採用してカオス化を抑える傾向が高まっているとのことです。設計チームがコードから借用したプロセスとフレームワークを、デザインチームが適用するというものです。開発者コミュニティで広く使われているシステム主導ワークフロー、分岐・結合は、デザインシステムで人気が高まっています。この方法では、コントリビューターがプライマリシステムに影響を与えずに、独立したブランチで作業でき、チームがコミュニティとともに構築できます。コントリビューターが、修正を送信し、新しいコンポーネントを提案して、システムマネージャーが変更をレビューしてから、システムで採用します。

SpotifyのEncoreは、サブチームが分岐して、ローカルシステムと呼んでいたシステムの上に自分たちのシステムを構築するのを奨励しました。広告チームから強力なビデオプレーヤーが集まることになり、ビデオへの効率的なアプローチ方法が周知され、デザインシステムチームによる貢献分野を効率的に拡大できました。他の企業や起業家たちが公開した独自システムでは、誰でもデザイン業務に参加し、デザイン全体を複製できるようになりました。「オープンソースシステムは、幅広いユーザーからフィードバックのループを得るのに優れています」と、Googleのマテリアルデザインチームの元デザインアドボケート、Louise Macfadyen氏は述べています。「製品自体の不明点をなくし、企業の知名度を上げる一方、知識を共有することで、業界全体の信頼を高めることができます」

成約は最小限に

構造が大規模に適用されると、新しい問題が起きます。システムの制限がきつすぎると、デザインそのものに影響が出るのです。デザインシステムに制約が多すぎると感じるデザイナーは、自由と実験の機会が奪われていると不満を訴えます。「やはり、デザインシステムの創造的表現に対する壁は低くすべきです。厳しすぎるのは良くありません」とMillerは語っています。

ShopifyのデザイナーのJosé Torre氏は、あるソリューションを提唱しています。「デザインシステムは、建築ではなく、ガーデニングのようなアプローチをすべきです」。細部を検討し、構築し、完成させる建築とは違い、「庭師は種を植え、世話をします。何を植えたかは知っているものの、庭がどのようなものになるのかは正確にはわかりません。彼らは植物が成長するにつれて庭の状況を知り、雑草を見つけたり、変更を加えたいと思ったときに処置を施します」。植物が予期せぬ広がり方をすることがあるように、慎重に計画されたデザインシステム内から予期しないボタンやメニューが出現する可能性もあります。そのコンポーネントもまた広がり、庭園を完全に覆いつくす可能性があります。あるいは、球根がまったく開花しなかったり、苗木がもっと多くの日光を必要とする場合もあります。そんなとき、庭師(デザインシステムマネージャー)は、必要に応じて調整を行えばいいのです。

サブコンポーネントまたはネストしたコンポーネントのモジュラーユニットは、ユーザーがニーズに合わせてカスタマイズできるだけでなく、有限原子モデルにもう1つの代替案を提供します。Stripeのプロダクトマネージャー、Matthew Ström氏は、これをデザインシステムの「機能的モデル」へのパラダイムシフトの一環と見ています。このモデルでは、サブコンポーネントがアクション、またはこれらの要素が実際に実行すること(クリック、入力、検索など)に、密接に関連付けされます。「サブコンポーネントにより、過去10年間に構築してきたオブジェクト指向のデザインシステムを超えるスケーラビリティと新しいレベルの効率性が可能になります」とStröm氏は述べています。プロダクトチームは、まだ見ぬ未来に向けて計画することも可能になります。「3年後に必要になるスーパーメガメニューを予測する必要はありません。すべてのサブコンポーネントがあれば、その機会が訪れたとき、システムのルールに従って組み合わせるだけです。この方法で、問題なく機能するのです」

ネストされたコンポーネントには、入力が増えるというメリットもあります。変数が増えれば、メタデータが増えるため、デザインシステムマネージャーは、コンポーネントがどのように使用されているかなどの多くの情報を得られます。そのデータは、将来的に新しいアプリケーションの開発に役立つ可能性があります(既存のパターンに基づいて新しいコンポーネントを生成するAIなど)。もっと近い将来の話としては、チームが自分たちのシステムの長所と短所を測定するための手段になります。これらのシステムが進化を続けるに伴い、チームは新たな方法で目標を確実に達成する必要があるため、指標は大きなメリットになります。

バランスを見つける

システム内で構造を増やすか減らすかを判断するのは困難です。制約があるからこそ、新しいアイデアが生み出される可能性もあります。確かに、優れた構造のデザインシステムは、デザインを効率化できます。一方でシステムのさまざまな面をコード化したいという要望も強く、すべてのことが討議の対象になる場合には、どのようにデザインするのが良いのでしょうか。デザイナーと開発者は、常に流動的なシステムを本当に信頼できるでしょうか。将来を見据えたとき、チームは自由と効率をどのように最適化できるでしょうか。

定期的にレビューと評価を行えば、予測不可能な複雑な事態が発生しても、チームは妥当性を検証しながら未来に向けて構築することができます。優れた製品がみなそうであるように、デザインシステムは、問題を解決し、明確な目標に向かって進む必要があります。参加者がアイデア、フィードバック、コンポーネントにさえも貢献できるカルチャーやプロセスがあれば、デザインシステムチームが継続的に向上し、対応範囲を広げることができます。Millerは、デザインシステムチームが自分たちのシステムを製品のように扱い、ユーザーのニーズに応えるべきと力説しています。答えはユーザーとともにあるのです。

デザインシステムに関するその他の記事については、DesignSystems.comをご覧ください。