UGA Boxxx

つぶやきの延長のつもりで、知ったこと思ったこと書いてます

【Design System】Uber のデザインシステムの進化についての記事

Uber のデザインシステム Base を開発者の一人、Maria Christopher 氏のデザインシステムの進化について説明している記事を読んだのでメモ

blog.designsystemsforfigma.com

Uber のデザインシステムはプラットフォームの成長に伴い、いくつかの問題が発生していた

  1. コンポーネントの過負荷: 当初、Base のチームは、コンポーネントの数が多いことをシステムの成熟の証と捉え、プラットフォームごとに約 60~70 個コンポーネントを作成していたが、コンポーネントの数が増えるにつれて、冗長性やシステムの不整合が発生するようになった
  2. 柔軟性と構造のバランス: Base のチームは、多様なプラットフォームをサポートするという課題に直面し、単一のシームレスなシステムの下でそれらを統合することを目指したが、柔軟性を追求しすぎた結果、カードコンポーネントのように、あまりにも多くのバリエーションに対応しようとして扱いにくいコンポーネントになってしまった
  3. 入力コンポーネントの不整合: Figma では共通のベースを使用しているにもかかわらず、テキストフィールド、セレクト、検索フィールドなど、多くの入力コンポーネントのコードが共有されていなかった

Base のチームはこれらの問題に対処するために、コンポーネントの開発と管理、柔軟性と構造のバランス、そしてシステムのスケーラビリティと健全性のバランスをとるための新しいアプローチを導入した

コンポーネントの再考

初期の Base では、コンポーネント数の多さを成功の指標としていたが、コンポーネントの冗長性やシステムの不整合という問題に直面した

そこで、次のフェーズでは、柔軟性と構造のバランスをどのように取るかに焦点を当てた コンポーネント開発の原則を以下のように定義

  1. 自己完結性: 他のチームが管理するコンポーネントへの強い意見は避ける
  2. コードの保守性: サポート負荷の増加やレガシーフレームワークのリスクを防ぐため、複雑なカスタムソリューションは避ける
  3. 持続可能な採用フロー: 管理可能な移行コストと一貫したユースケースが確信できる場合にのみ、コンポーネントを構築する
  4. システム規模と健全性のバランス: コードベースの保守性を損なう可能性のある、不要な複雑さを避ける

再考されたレイアウト:構成可能性とカスタマイズ

再考されたレイアウトの中心となるのは、構成可能性コンポーネントがさまざまな構造やレイアウトにどれだけ柔軟に対応できるか、コンテンツの表示方法についてどれだけ規範的または柔軟であるか)

コンテンツのバリエーションを処理するために、バリアントカスタムコンテンツスロットオーバーライドという 3 つの主要な方法の使用方法を統一

  1. バリアント: 複数のコンテキストで一貫した機能が必要な場合に有効だが、すぐに複雑になる可能性がある
  2. カスタムコンテンツスロット: 柔軟性が高く、時間の経過とともに進化する必要があるコンポーネントに最適
  3. オーバーライド: 特別な場合にのみ使用し、過剰なカスタマイズを制限することで安定性を維持

再利用可能なレイアウトモデリングの採用

入力コンポーネントのように、Figma では共通のベースを使用しているにもかかわらず、共有コードがないコンポーネントが多数存在するという問題が発生していた

この問題に対する解決策として、再利用可能なレイアウトモデリングが浮上

共有コアプロパティとレイアウトアーキテクチャを持つコンポーネントの設計に焦点を当てることで、コンポーネントの重複に対処し、システムを合理化することができると考えた

当初、コンポーネントレベルのトークがこの課題に対処すると期待していたが、トークンはスタイルの整合性を維持するには効果的ですが、コンポーネントの順序を管理したり、状態マップのニュアンスを伝えたりすることはできなかった

レイアウトモデルの実装

最初のレイアウトモデルの実装では、コンテンツスロットに柔軟性を持たせ、複雑なインジケータ構成に対応できるフレームワークを作成

レイアウトモデルの設計

  1. まず、ラベル + 入力コンテナ(テキストフィールド、セレクト、PINコード、検索、テキストエリアなど)+ ヒントテキストを含む、幅広いコンポーネント構造を設計
  2. 次に、テキストフィールドやセレクトなど、個々の入力タイプのアーキテクチャとロジックを定義することに集中した

レイアウトモデルの統合

基盤となるレイアウトモデルを定義した後、それをコンポーネント全体に実装した

  1. すべての入力コンポーネントのコア構造として機能するルートクラスを定義
  2. このベースから、汎用コンテナクラスを開発。このクラスは、テキストフィールド、セレクト、検索フィールドなど、さまざまなタイプの入力コンポーネントを格納できるラッパーとして機能
  3. 次に、Select Input、PIN Input、Text Input などの特殊なコンポーネントクラスを作成。これらのクラスは、汎用コンテナを拡張して、Select Input や Text Field など、それぞれに固有のプロパティと動作を持つ特定の入力タイプを処理

この新しいアプローチにより、開発の迅速化、アクセシビリティの合理化、マイクロアニメーションの探求などの利点が得られた