「デザインシステムの育て方」を一通り読んだので、読書メモと感想をざっくり記していこうと思います。

なぜ読んだのか

現職でちょうどデザインシステムの立ち上げに取り組んでおり、開始から 1 年弱が経ちました。 Web/App/Design での認識統一を目的に、デザイントークンやコンポーネントの実装を進めていますが、プロダクトへの浸透や実装工数の確保といったよくある課題に直面しています。

そんな最中、今後の計画やいま感じている課題をどう解決するべきか参考にするべく購入しました。

書籍の概要

大掛かりな仕事をもっと効率よく進めたいと考えている、デザイナーやエンジニアやプロダクトマネージャーがターゲット。10 章から構成されていますが、概ね以下の構成となっています。

  • デザインシステムとは (1-3 章)
  • デザインシステム始めるために (4-5 章)
  • 継続的なプロジェクトにするために (6-10 章)

各章の読書メモ

監訳者まえがき

  • デザインシステムをプロダクト(を作るスタートアップ)と同様に考える
    • システムを使うデザイナーや開発者がターゲットとなり、
    • デザイナーや開発者が使いやすいものになるよう改善を続けていくこと ≒ PMF
  • 「憧れ」と「目の前の課題」を切り分ける
  • デザインシステムを成功に導くには、計画段階で「なぜ」を深掘りしてチーム全体で共通認識を醸成することが必要
    • 「なぜデザインシステムが必要か?」→「デザインと実装の連携強化」だけでは一般論すぎる
    • 「デザインと実装の連携」をふかぼると…
      • デザイナーとエンジニアのコミュニケーション不足(体制の問題)
      • 実装後のデザインチェック不足(工程の問題)
    • もしかしたら最適な手段はデザインシステムではないかも
  • 短期計画と長期計画の両立
    • プロジェクト視点(短期): 新しいコンポーネントをいつまでに完成させる?
    • プロダクト視点(長期): デザインシステムの採用率や有用性はどうなっている?
    • プロジェクト視点のみだと、組織のプライオリティとの不一致を招く
  • 効果的なアプローチの一つはパイロットプロジェクトの立ち上げ
    • 小さなスコープで、即座に必要なコンポーネントのみに焦点を当てる
    • 全体との一貫性不足やスケールしない懸念も出てくるが、活用できる道具を提供することが大切

デザインシステムとは (1-3 章)

  • 筆者の考えるデザインシステムとは

    • 「組織がデジタルプロダクトを一貫して効率的かつ楽に作成するために必要な最小限のコンポーネントとガイドラインを含む、パッケージ管理およびバージョン管理されたソフトウェアプロダクト」
    • とはいえ、絶対的な定義を決めるより幅広く包括的に構えた方が良い
  • デジタルプロダクト関連の仕事では、大きく分けて 7 種類位のデザインシステムがある

    • ブランドのアイデンティティ, ツールとテンプレート, デジタルプロダクト…
    • 自分が作りたいデザインシステムを決める
  • デザインシステム・プロダクトに共通の 6 種類の一般的なパーツ

    • UI キット
    • コンポーネントライブラリ
    • ガイドライン
    • レファレンスウェブサイト
    • デザイントークン
    • ウェブサイトやアプリなどのデジタルプロダクト
  • ガイドラインは作業中の場所から離れずに参照できるなどは理想

  • コンポーネントライブラリとデザインシステムは全く別物

    • (Bootstrap と Material UI の例が出ていたが、個人的にはあまり納得いかず…)

始めるための方法 (4-5 章)

お墨付きにまつわる誤解 (4 章)

  • デザインシステムの賛同を得ることは、実態のないソフトウェアを売り込むようなもの
  • 抽象的なシステムは作りにくい
    • 具体的な使い方を想定していないと、システムが肥大化する
  • 新しいツールを導入するように説得するのは至難の業
    • 人間は労力が最も少なくて済むやり方に従う(ジップの法則)

パイロットプロジェクト (5 章)

  • 本格的に構築する時間と資金を注ぎ込む前に、どんなデザインシステムが必要とされるかテストする
  • 最も勢いをつけやすいのが、デザインシステム関連の仕事と現在進行中の仕事を連動させること
  • デザインシステムを浸透させる絶好の出発点
    • リブランディング
    • プラットフォームの変更
    • 組織再編
    • コンテンツの制作または乗り換え
    • 他社との吸収合併
  • 共通するのはどれも会社がすでに幅広く全社で変わろうとしている点
    • これに相乗りして、取り組みの結果を話すべき
    • この段階では「デザインシステム」という言葉を出す必要もない
  • パイロットプロジェクトの種類
    • インディアナ・ジョーンズ(置き換え)型
      • 既存のデザインやユーザー体験を変えずに置き換えていく
    • フェイスリフト(お色直し)型
      • リブランディングの適用手段としてデザインシステムを使う
    • スピードラン(開発期間テスト)
      • デザインシステムのコンポーネントを使った UI 制作の時間を計測する
    • サロゲート(代行)型
      • プロダクトチームとは別で置き換えたプロトタイプを作る
    • ペリミーター(周辺)型
      • 周辺プロダクトから置き換える
  • 3 種類のパイロットプロジェクトに同時に取り組むのが良い
    • 3 はパターンが生じる最小の数
  • パイロットプロジェクトで大事なのは「デザインシステムを使って何を作れるようにする必要があるか」という疑問に答えを出すこと
  • デザインシステムのプロセス「デザインシステムの計量スプーンサイクル」
  • エクソンモービルとシートンヒル大学のデザインシステム事例

継続的なプロジェクトにするために (6-10 章)

ガバナンスと貢献 (6 章)

  • 全チームがシステムを使い、貢献もしてくれるのは現実的ではない
    • 例えば、WordPress に貢献し返しているユーザーは 0.01%
    • これを当てはめると、100 人組織なら貢献し返すのは 2 人ほど
  • デザインシステムに貢献するのはデザインシステムチームの仕事であって、プロダクトチームの仕事ではない
  • 誰もが自分のやるべき仕事をこなすだけで、デザインシステムに自動的に貢献できるようになるサイクルを作る
  • ドキュメント作成や周知は後回しにしがちな作業だが、最初から時間をかけて取り組むべき

役割と職責 (7 章)

  • ドキュメント作成より動くコードの方が大事
  • ロールの枠を具体的に決めすぎない
  • デザインシステムが成熟して行った時の組織が大きくなる事例
    • 組織がニーズに応じて有機的に成長していくことが大事

デザインシステムのプロセスとワークフロー (8 章)

  • ホットポテト型のプロセス
    • デザイナーとエンジニアが協力して働く手法

デザインシステムの成功の指標 (9 章)

  • デザインシステムの有望度を測る指標として一般的な 2 つ
    • 効率
      • フィーチャーチームがデザインやエンジニアリングに要する時間の短縮
      • リリーススピードの上昇
      • QA(品質保証)に要する時間の短縮
      • 機能制作中に報告されるバグ数の減少
    • 一貫性
      • 冗長な CSS が簡潔になっているか?を CSS Stats で測るなど
      • ユーザーからの不満の減少や、ユーザーがタスクをこなすのにかかる時間の減少
  • デザインシステム成功の究極の目標は採用度の上昇
    • 採用度を測るのは難しいが、独自のツールを運用している会社も
  • デザインシステムの組織への影響を本当の意味で理解するには、組織固有の目標ともっと直接的に結びついた、自分たちだけの成功の指標を見つける必要がある
  • 採用ゼロを 1 にするのが最も難しいので、1 コンポーネントが複数プロダクトで採用されることから始めても良い
  • システムより人に着目した目標を立てる
    • 🙅「フォームコンポーネントの採用率を 15 パーセント上げる」
    • 🙆「ランディングページチーム(フォームを使うチーム)がこれまでよりも 1 週間早く仕事を終えられるようにする」
  • デザインシステムチームの目的はプロダクトチームの目的と結びつける必要がある

伝道に終わりは無い (10 章)

  • レファレンスサイトはコンポーネント単体よりも、作れるものの実例を見せるべき

得られた学び

デザインシステムをプロダクトと捉える

  • デザインシステムをデザイナーや開発者がターゲットのプロダクトとして考える
    • 何を一番必要としている?使われるためには?という思考もここをベースにする
  • デザインシステムに限らず、社内ツールや OSS でも同様に捉えられそう

デザインシステムを構築する上での思考が学べた

  • 抽象で考えすぎず、具体で考える
    • 理想のカードコンポーネントを考えようとしない
    • 「まずはプロダクトを作ってヘッダーを抽出し、使いそうな人のためにデザインシステムに組み込むべきなのだ。パイロットはコンポーネントに使用する状況を与える。」
  • ベストプラクティスを生み出すのではなく、収集して浸透させる
    • 入力ボックス 1 つ作るにしても、既存のプロダクトで 5 個バリエーションがあった時に、全く新たな 6 個目を作るのではなく、なるべく既存と特徴が重なるように共通項を見出す
  • コンポーネントが多いほど良いなんてことはなく、最低限の数でもプロダクト開発の時間を節約できればその価値がある
    • 「デザインシステムとは、“最小限の数”の便利なコンポーネントのセットだ」

おわりに

デザインシステムには既に取り組んでいたので、4-6 章の軌道に乗せるポイントや 9 章の成功を測る方法が特に印象的でした。

抱えていた課題がまさしく書籍にあって共感しながら読み進められ、同時に自分たちがこれまでやってきたことはパイロットプロジェクトであり、ここからさらに広げていくために振り返りできそうだなという気づきも得られました。

デザインシステムを始めよう・始めてみたがどう進めようという方はぜひ読んでみてください。