M

creating themeable design systems を読んだメモ

Published

Creating Themeable Design Systems | Brad Frost を読んで、メモ。

  • Brad Frost氏の2018年のブログ記事。
  • 見た目が全く異なるブランドや体験を1つのデザインシステムによってサポートできるかどうかというと可能。
    • そのニーズの背景に何があるか。
      • 異なる客層やコンテキスト
      • 異なるブランド
      • 異なるプロダクト
  • CSS Zen Garden: The Beauty of CSS Design
  • The truth is that a design system is as rigid or as flexible as you make it to be.

    • デザインシステムの柔軟性は、そのデザインシステム次第で決められる。
      • デザインシステムが一定の制約をもたらすのは事実だけども、それが表現を制限するものではない。
  • 本題のthemeableなデザインシステムをどう実現するか。
    • デザイントークン
    • each brand defines their own design tokens, which then hook into the design system’s codebase.

      • 各ブランドで独自のデザイントークンを定義して、デザインシステムのコードベースにフックする。
      • 氏は、3段階に階層を分けることが多い。
          1. ブランドの核となる定義
          • --color-brand-starbucks-green, --font-family-primary
          • 抽象的な定義で、UIに直接適用するものではない。
          1. 高レベルのアプリケーションの変数定義
          • --primary-action-background-color, --font-family-heading
          • 1層目の値を使ってアプリケーションでどのように利用するかを定義。
          1. コンポーネント固有の変数定義
          • --button-background-color, --button-font-family
          • 2層目の値を使ってコンポーネントでどのように利用するかを定義。
          • コンポーネントレベルでの定義は1度行うと、あとで変更することはほとんどない。対応するブランド数が多いほど、これによって労力が減らせる。
        • 影響範囲が階層によって絞られるので、変更したい内容に応じて該当の階層の値を変更すればいい。
        • このような3層構造にすることは、困難が伴う。システムによっては過剰になるし、開発速度の低下を招く可能性もある。
    • アトミックデザイン
    • 異なるUIを提供するパターンについてはCreating Themeable Design Systems | Brad Frostを参照。
    • 画一的なUIしか提供できないという思い込みは持つべきじゃない。体系的に設計することで異なるUIを提供できるようになる。