Design Systems
「Design Systems — デジタルプロダクトのためのデザインシステム実践ガイド 」を読みました。
本書は、ドイツの Smashing Magazine が出版している「Design Systems」(Alla Kholmatova 著) の日本語訳です。昨今ウェブサイトの情報設計や UI デザインにおいてポピュラーになりつつある「デザインシステム」というアプローチについて、著者自身の経験や他社事例を交えつつ、その効果的な構築と運用の実践方法をまとめたものです。
一貫性のある UI によってユーザビリティを保ち、また統一的なブランド表現を担保するために、デザインシステムは今後ますます、効率的なツールとして重視されてゆくことでしょう。形 (成果物) としてのデザインシステムのありかたは「十社十色」で、いざ自分たちが実際どう取り組めばよいものか、捉えどころのなさを感じてしまうかもしれませんが、本書で紹介されている具体的な事例を参考にすることで、どのように企業やチームの中で共通認識を醸成し、デザインシステムを位置づけ、作り、メンテし、運用してゆけばよいのか、というヒントが得られるように思います。
以下、本書を読んで得た学びや感じたことのメモです。
デザインシステムとは？
デザインシステムとは、デジタルプロダクトの目的を達成するために首尾一貫したルールで編成された、お互いに関連づけられたパターンとその実践方法です。(P.14 : 強調は筆者)
- 「デザインシステム」は、「パターンライブラリー」「スタイルガイド」と同義と解釈されることが多いが、単に UI デザインのパターン (とそのライブラリー化) だけでなく、そのパターンを適切に運用するための、デザイン原則や共有言語を含む「デザイン体系」と言える。
デザインシステムを作る
- デザインシステムを確立するためには、以下の要素がある。
- プロダクト (ウェブサイトやアプリケーションなど) の目的
- デザイン原則
- デザインパターン
- 共有言語
- 企業やチームにとって、デザインシステムのありかたは色々。「ルール (厳格 vs 緩い)」「部品 (モジュール型 vs 統合デザイン型)」「組織 (集中型 vs 分散型)」の3つのパラメーターの度合いによって変わってくる。
- 「ルール (厳格 vs 緩い)」「組織 (集中型 vs 分散型)」パラメーターの度合いは、もともとある企業文化の影響を強く受けそう。
- 「部品 (モジュール型 vs 統合デザイン型)」パラメーターが「モジュール型」に寄ったチームだと、再利用性の高い UI コンポーネントを作ることが重視されるため、デザインパターンを作りやすくなる。ただし「モジュール型」に寄りすぎると、コンテンツごとに尖ったデザインをしにくいかもしれない。
デザインパターン
パターンは、デザインの問題を解決するために繰り返し使用される、再利用可能な解決策です。(P.18 : 強調は筆者)
- デザインパターンには、2つの種類がある。
- 機能パターン : 「モジュール」や「コンポーネント」とも呼ばれる。期待されるユーザー行動から導出される。(例 : ボタン、リンク、タブ、各種フォーム要素、フィードバックメッセージ、カード、ナビゲーションメニュー、など)
- 認知パターン : 「スタイル」「ビジュアル (外観)」とも呼ばれる。インターフェースやブランドの個性やエートスから導出される。(例 : 配色、インタラクションの動き、タイポグラフィ、アイコンデザイン、など)
- パターンを定着させ、適切に運用するためには、共有言語も欠かせない。共有言語の根幹を成すのは命名規則 (P.97) だが、ただ命名するだけでは不十分。パターンを使用する理由、コンテキスト、目的なども把握したうえで言語化する必要がある (P.23)。
- 共有言語は、チームみんなが命名に参加するとスムーズに運用されやすくなる。Slack チャンネルを作るなどして、気軽に議論できる場を設けるとよい (P.104)。
- 共有言語を浸透させる方策として、パターンウォールやSlack ボットなどを用いるのも有効 (P.107)。
デザインパターンのライブラリー化
- デザインパターンを洗い出し、ライブラリー化する過程においては、開発、デザイン、コンテンツ作成、それぞれの部門が関わる必要がある。いずれかが抜けた形で進めてしまうと、運用で破綻する恐れがある。(P.213)
- Google ドキュメントを用いるなどしてチーム全員がデザインパターンをレビューしたり編集したりできるようにするとよい。(P.214)
- パターンライブラリーを編成する際の肝は、パターンを探しやすく、再利用しやすくすること。これが不十分だと、パターンに則らない形で類似の UI が作られてしまったり、無駄に重複するパターンが新たに作り出されてしまう恐れがある。
- パターンライブラリーは、「アルファベット順」「階層 (Atomic Design 的な考えかた)」「目的や構造」といった切り口で編成されることが多い。
- 機能パターンの明文化においては、名称、目的、例 (外観、コード)、バリエーション、といった要素を盛り込むとよい (P.223)。(たとえば IBM Carbon では、各パターンの中で「Code (コード)」「Usage (使用例)」「Style (外観)」 という要素がタブで用意されている。)
- 認知パターンの明文化においては、構成要素 (たとえばカラーパレットの並び) だけでなく、使用方法 (たとえば、どの UI にどの色を適用するか) も明示するとよい (P.232)。
- 機能パターンと認知パターンは、横軸と縦軸のような関係で密接につながっているので、相互に参照できるようにするとよい (P.234)。
- インタラクションの状態 (デフォルト状態、hover、focus、selected、など) といった特定の切り口で一覧的にまとめりのも一考 (P.236)。
デザインシステムの運用
- デザインシステムを継続的に運用するために、体系的なワークフローを整備する。新規パターン案を受け入れ → デザインシステム管理チームにて新規パターン案のレビュー → (採用する場合) 正式なパターンとして明文化 → パターンライブラリーに反映、といった具合。
- ワークフローはオープンに。GitHub を用いてイシュー管理したり、Trello を用いてカンバン方式を採用したり、など。
- 新規パターンの採用基準は、再利用性 (汎用性) が高いこと、が基本。ただし、一見特異なものでも実は汎用性がある可能性はあるので、オープンなコミュニケーションが大事。
- パターンライブラリーを最新のものに保ち、信頼できる情報源にしよう。