『ちいさくはじめるデザインシステム』

先日こちらの本が出版されたので早速買いました。

www.amazon.co.jp

SmartHRが公開しているSmartHR Design Systemを立ち上げた背景やその構築・運用までどのように考えて作られたのかがまとめられている1冊です。

現在在籍しているチームでもUIコンポーネントをまとめたリポジトリを作成・運用しているので参考になることが多そうだと思い買いました。

内容についてまとめてみたいと思います。

デザインシステムとは

まずデザインシステムは一般的に

「デザインの再現性を高め、一貫した製品体験を効率よく表現すること」を目的に導入される「ドキュメントやリソース群のこと」

大塚亜周他 著『ちいさくはじめるデザインシステム』 p.4

とされています。

デザインシステムの構成要素としては以下の通り大別できます。

デザインシステムは社会インフラ等と同じく、様々なものが組み合わさって仕組み化されています。

そこには目的に応じて必要な仕組みも変える柔軟な対応が必要です。「これがあれば正解」というものはありません。

なのでデザインシステムには「何らかの目的」が必要です。目的があって初めてデザインシステムの構想が始まります。

またデザインシステムは組織の問題を解決したり目的を果たすためのものであるのでデザイナーやデザイン組織だけのものではありません。

組織全体で取り組んでいくものであり、職能の垣根を超えて巻き込んで多様な観点を取り入れることが大事です。

デザインシステムを作ることだけでなく、「使うこと」も身近な貢献なのでまずは使ってくれる人を増やして小さな貢献がたくさん生まれる状況を作ることを目指すのが良いと本書には書かれています。

デザインシステムの構築のステップ

第2章では実際にデザインシステムを構築する上でのステップが解説されています。その内容を見ていきましょう。

デザインシステムをはじめる3つのステップ

便利なコンテンツから作る

  • いきなり多様なコンテンツを作るよりまずは便利なものを1つ作る
  • まずは使われている状態を目指す
  • SmartHRではコンポーネントライブラリから始めた

課題発見と課題解決のサイクルを繰り返す

  • プロダクト開発やブランドコミュニケーションの現場にあるリスクや課題を書き留める
  • 優先度の高いものから着手
  • 課題とそれに対する解決を残し続けていくプロセスそのものがデザインシステムである

原則を言語化する

  • 「誰が判断しても結論に大きなズレが生まれない」原則は必要
  • 時間をかけて言語化

「まずは便利なものを1つ作る」はタイトルにある通り「ちいさくはじめる」を体現している思想かなと思います。

最初から何でも揃った完璧なものを目指すより、まずは目の前の課題を解決できるものを作り、フィードバックを元に改善のサイクルを回すことに重きを置く。

それを繰り返す中で共通して見えてくる原則を言語化する。

作って終わり、ではないのがデザインシステムです。

デザインをみんなのものにする3つのステップ

最初は地道な草の根活動

  • 社内MTG等でお知らせの機会を作る
  • Slack上でコミュニケーション
  • デザインシステムを解説する会を企画
  • 社外にも広報

課題発見に小さく協力してもらう

  • 使っている現場に直接聞きに行く
  • 課題を解決できたらそれをお知らせに行く⇒その後も積極的にフィードバックをくれるように

コンテンツの作者になってもらう

  • 小さく解決策が作れそうなものをお願いしてみる
  • 作者になると実際に使われているか、改善できるところはないかと気になる

特に「コンテンツの作者になってもらう」はとても大事だなと思います。

デザインシステムに限らず、色んな人を巻き込んで当事者になってもらうのはプロダクト開発において必要なスキルの1つじゃないかと思います。

自分が作ったものは愛着も湧くし、もっと多くの人に使ってもらうために改善したくなるはず。

デザインチームだけのものではなく、組織全体で考える上でもこうしたステップは必要かなと思います。

デザインシステムの運用

第4章では構築したデザインシステムを運用していく上でのコツが記されています。

先程も述べた通り、デザインシステムは一度作ったら終わりではありません。

そのため、各プロセスの自動化は必要です。テストやコード規約等、作り始める段階から何が必要なのか見越しておくことが必要です。

また外部サービスや各種ツールも活用することを検討すべきです。

Figma等のデザインツールやStorybook等のコンポーネントライブラリ等、使えるものを有効に使うことでコストや工数を削減できます。

ただし、外部サービスのデメリットとして柔軟性に欠けるという点が挙げられます。

複雑な実装が必要な場合等はフルスクラッチで構築することも選択肢の一つです。

また、デザインシステムの前提として書かれていたのはデザインとエンジニアリングは不可分であるということです。

  • コミュニケーション手段の延長として皆が使える「道具」を作る
  • 非デザイナーでもデザインの意思決定を素早くできるように「パターン」を用意する

先程も書いた通りデザインシステムはデザイナーやデザイン組織だけのものではありません。

職種や職能の枠を超えてプロダクト開発にデザインの面から誰もが貢献できるようなシステム、それがデザインシステムなのではと思います。

レビューについて

第3章では様々な実例が示されているのですが、その中でもデザインレビューの項が非常に良かったです。

デザインレビューだけでなく、コードレビュー等にも通じる部分が多々あったのでぜひ読んでみてください。