グッドパッチが実際に行っているステップ別に解説 デザインシステム構築前の準備フェーズですべきこと
これまでさまざまな組織のデザインシステム構築や運用を支援してきたグッドパッチ。本連載ではデザインシステムにフォーカスし、その概要や歴史、導入から運用、構築にいたるまで網羅的にお届けします。第4回は「デザインシステム構築前の準備」についてです。
※本記事はウェブマガジン「CreatorZine」に2024年2月5日に掲載された記事を再掲載したものです。
こんにちは。グッドパッチのUIデザイナーの乗田です。前回の記事では、デザインシステムを構築する前に理解しておきたい「調査」「計画」「構築」「適用」「拡張」の5つのプロセスについて解説しました。第4回では、「デザインシステムを構築するために必要な準備」をテーマにお届けします。
はじめに
グッドパッチがデザインシステムの構築を支援する際、準備フェーズで行う作業は主に次の4つです。
- プロジェクトビジョンの策定
- デザインシステムの構造の設計
- 使用するツールや技術の選定
- ロードマップの作成
準備のステップが多いと感じる人もいるかもしれませんが、これらはこの先のデザインシステムを構築・運用するフェーズで、迷いが生じた際にいつでも立ち戻れる「土台」として機能するため、これらのステップは欠かせません。
一方、準備フェーズのアウトプットは組織に直接的な価値をもたらすわけではありません。そのため、もしデザインシステムに割けるリソースが限られている場合は、次回紹介する「トークンの定義」や「コンポーネントの構築」から着手することをオススメします。
デザインシステムは常に価値を創出しながら作ることが望ましいものです。構築に決まった順番はないため、あくまで組織にとって価値がある部分から少しずつ取り組んでいくことを意識しましょう。
プロジェクトビジョンの策定
プロジェクトビジョンは、デザインシステムを組織で構築・運用する際の目的や目標を可視化したものです。プロジェクトの目的が不明瞭だと、チームがゴールに向かって進むことが難しくなります。そこで、チームが正しい方向へ向かってデザインシステムを構築するための羅針盤のような役割を果たすのが「プロジェクトビジョン」です。デザインシステムチームの共通指針であり、意思決定の基準として機能します。
プロジェクトビジョンは「目的」「目標」「課題」「手段」の4要素で構成し、ツリー状に表現するのが良いでしょう。
プロジェクトビジョン策定で大切なのは「デザインシステム本位にしない」ということです。これはつまりデザインシステムの構築をプロジェクトの目的にするのではなく、プロジェクトの目的を実現するための“手段”としてデザインシステム構築が存在するということです。
手段と目的を履き違えると「せっかくデザインシステムを作ったのに、何の課題も解決できなかった」といった落とし穴にはまってしまいます。
次のツリー図は、グッドパッチがデザインシステムの構築・運用を支援する際によく策定するプロジェクトビジョンを抽象化したものです。
このツリーを構成する4つの要素について、策定に至った背景や策定時に注意したいポイントを紹介します。
1. 目的
目的では、このプロジェクトで達成したいことを定義します。
グッドパッチが手掛けたこれまでのデザインシステム構築の支援を振り返ると、「時間の使い方を変える」という目的を起点にプロジェクトを進めていたケースがよくありました。この背景には、グッドパッチがデザインシステムを「クリエイティブのジャンプ台」と位置付けていることが大きく影響しています。
デザインシステムは遵守すべきルールではなくガイドラインであり、創造的なアウトプットの前段にある意思決定を簡略化してくれる土台であるからこそ、「時間の使いかたを変える」ことを目的に据えることが多いのです。
そのほかの目的として多かったのは、「チームのナレッジを良いデフォルトとしてストック・活用できる環境の実現」です。これはデザインの過程で生まれたナレッジを誰もが広く活用できる組織をつくるということです。チーム内で生まれたナレッジが再利用可能な状態で潤沢に用意されていることの効果は非常に大きいため、この目的もよく設定されています。
ここで大切なのは、デザインシステムの“効果”を目的に掲げない点です。組織課題の改善プロジェクトにおいてデザインシステム構築という“手段”が前提にあると「一貫性の向上」や「共通言語の構築」など、デザインシステムの効果そのものに着目してしまいがちです。しかし、「時間の使いかたを変える」などのより根源的かつインパクトの大きい目的を設定することでプロジェクトの価値を最大化させたり、手段に縛られずにプロジェクトを進行したりできるようになります。
2. 目標
目標では目的を達成するために到達すべき状態を明らかにします。グッドパッチではさまざまなプロジェクトにおいて、次の目標を掲げるケースが多くあります。
- ユーザーが課題解決に要する時間の短縮（Quality）
- チームのベロシティの向上（Cost）
- ユーザーに価値を提供するまでの時間の短縮（Delivery）
「Quality」「Cost」「Delivery」の各観点を目標としている背景には、プロジェクトへ多面的な価値をもたらす狙いがあります。また、同時に重要なのは、それぞれ計測可能な目標であることです。定量的な目標を設定することで目的の達成度合いが明らかになるほか、プロジェクト前後の変化も可視化できるようになります。
これらはすべて「成果目標」です。さらに目標の達成へと近付くためには、後述する「手段」を明らかにした上で、行動目標を具体的にブレイクダウンすることが望ましいでしょう。
3. 課題
ここでは、先ほど設定した「目標」とのギャップ、すなわち目標達成を妨げる要因を挙げていきます。課題は「発生型」と「設定型」に分類して定義できると効果的です。
発生型の課題では、過去から現在にかけて組織の理想の状態を阻害している課題を定義します。例えば、次のようなすでに発生している業務課題です。
- 保守やレビューに多くの時間を要している
- メンバーによってアウトプットの量や品質に差が生まれている
- タスクの前提をすり合わせるためのコミュニケーションに多くのコストがかかっている
発生型の課題は、「素早く正確に課題を解消し、組織に効果を還元するか」が重要です。これらを解消することで組織の生産性向上につながります。
設定型の課題では、組織の理想状態を阻害するであろう課題を定義します。以下のようなものを指すイメージです。
- メンバーが増えてオンボーディングにコストがかかる
- プロダクトの増加によりメンテナンスコストが増えたりリソースが足りなくなったりする
- アクセシビリティ要件への対応が遅れる
- メンバーが減ってリソースが足りなくなる
設定型の課題は、「組織の将来の姿を高い解像度で見つめ、発生するであろうニーズを探索すること」が重要です。これらを解決することで、組織の付加価値向上につながります。
「発生型」と「設定型」の課題はそれぞれ成果が求められるタイムスパンや効果が表れるタイミングが異なります。適切にアクションを実行するためにも、時間ごとに課題を分類して定義しましょう。
4. 手段
最後に定義するのが、課題を解決するための具体的なアクションやソリューションです。
- タスク管理と業務プロセスの最適化
- コミュニケーション効率の向上
- UIデザインや実装時の再利用性の向上
このように定義した手段を基に、デザインシステムの構築プロセスに取り組むのですが、ここで注意したいのが「すべてのアクションがデザインシステムの取り組みに反映されるわけではない」ということです。
例を挙げると、「コミュニケーション効率の向上」の具体策としては「デザインガイドラインやコンポーネントライブラリの構築」もあれば「ミーティング設計の見直し」もあるでしょう。
前者はデザインシステムに関する取り組みのひとつとして進めることが最適ですが、後者はその取り組み外でも実践可能です。
プロジェクトの全行動をデザインシステムに依存させてしまうと、本来はクイックに行えるはずだった取り組みも動き出しが遅くなり、課題解決から遠ざかってしまいます。そのため、デザインシステム構築の一環として取り組むものとそうでないアクションは適切に分類し、実践しましょう。
デザインシステムの構造設計
プロジェクトビジョン策定の次に取り組むのは、「デザインシステムの構造設計」です。デザインシステムの全体図を俯瞰できるよう可視化し、将来的にどのようなデザインシステムが構築されるのかという共通認識をチームですり合わせることが狙いです。
デザインシステムの構造は組織におけるデザインの対象物、そのデザインを行う過程で発生する課題やニーズ、ブランドとプロダクトの関係性、組織が大切にしている価値観などに応じて変化します。
グッドパッチでもこれまでさまざまなプロジェクトでデザインシステムの構造を設計しましたが、どれひとつとして同じ形になったことはありません。構造設計を行う際には、先ほど紹介したプロジェクトビジョンを駆使しながら、組織を正しく観察する必要があります。
次のツリー図は、グッドパッチがデザインシステム構築・運用を支援する際に設計するデザインシステムの構造を抽象化したものです。
この全体構造では、上部の要素は「組織」に、下部の要素は「ユーザー」にそれぞれ強く結びつくよう設計されています。第2回の記事でお伝えしたように、デザインシステムは組織とユーザーの媒介として機能するものです。設計時には、デザインシステムの構造にも両者の視点を反映する必要があります。
このようにデザインシステムは組織の特性やニーズを表したものであるため、その構造も組織によって大きく異なります。今回紹介した構造もデザインシステムのひとつのパターンに過ぎません。
例えば「コミュニケーションデザインガイドライン」は、組織の規模や提供するデザインの種類に応じ、その有無や規模が左右されます。インタフェースのコンポーネントやパターンを重視し、これらをデザインシステムの中心に据える組織もあれば、ブランドの哲学や価値観を中心に、それにもとづいて具体的なデザイン要素を配置する組織もあるでしょう。
また、同じ組織でも事業や組織構成が変化することで、デザインシステムへのニーズも変わり、結果としてその構造が変化することもあるはずです。
デザインシステムの構造に正解はありません。準拠すべきは事前に定義したプロジェクトの目的や目標です。デザインシステムが最大の価値を発揮し、設定した目的を達成するためにも柔軟な設計を行いましょう。
使用するツールや技術の選定
構造設計の次のステップは、使用するツールや技術の選定です。これらはデザインシステムの構築前に行うことが望ましいです。
使用ツール
メンバーごとに使用するツールが異なるとコミュニケーションの難易度が上がるほか、過去資産の再利用も難しくなってしまいます。たとえばデザイナーごとに使用するデザインツールが異なる場合、コンポーネントを再利用したりUIを複製することはできなくなります。またエンジニアやマネージャーがデザイン成果物を確認する際、デザイナーごとにツールを使い分けなければならず、ツールの学習コストも発生します。
チーム全体で同じ目線で会話をするためにも、デザインツールだけではなく、タスク管理やドキュメンテーションなどに使うツールも含め、組織内で統一しましょう。
ただし、プロダクトデザイン時のツール（FigmaやSketch）とコミュニケーションデザイン時のツール（IllustratorやKeynote）など、同じ役割の人が使うツールでもデザインの目的やアウトプット先の媒体が異なる場合には、必ずしも統一する必要はありません。コミュニケーションではなく、作業効率やアウトプットの品質が優先されるケースがあることにも留意してツールを選ぶことが大切です。
技術スタック
技術スタックの選定も、デザインシステム構築前に行いましょう。コミュニケーションコストの増加を抑えたり、開発の手戻りを防いだりすることができます。
このフェーズでは特に、「ウェブフロントエンド用のアプリケーションフレームワーク」と「UIライブラリ、またはUIをスタイリングするための技術」を選定します。これらはデザイナーとエンジニアが共創する際の前提となる要素であり、デザインシステム内のUIコンポーネントの設計方針に大きな影響を及ぼすため、早いタイミングで定義する必要があります。
アプリケーションフレームワーク（React、Vue.js、Svelteなど）の選定は、エンジニアのスキルセットに大きく左右されます。これらはウェブフロントエンドを開発する際の基盤となる技術のため、この選択によって将来的な開発・保守・運用に必要な工数も変わります。作業効率を最大化させるためにも、組織全体で慣れ親しんだフレームワークを使うことが望ましいです。
一方、UIライブラリの多くはアプリケーションフレームワークに依存するため、その選定によってUIライブラリの選択肢も絞られてしまいます。フレームワークとUIライブラリは並行して選定すると良いでしょう。
UIライブラリ（コンポーネントライブラリ） はフロントエンドで使用するトークンやコンポーネントが収録されたものです。UIデザインやプロパティの設計がすでに施されているほか、アクセシビリティが適切に確保されているものもあるため、フロントエンド開発の工数を最小化する際にも役立つはずです。
もちろん、ライブラリを使用せずにオリジナルのコンポーネントを構築することもできますが、デザインシステム構築の初期段階は、作業工数を潤沢に確保することが難しいケースがほとんどだと思います。また、デザインシステムへの要求も変化しやすいため、自作は推奨しません。最初はUIライブラリを使用し、カバーできないニーズが出たタイミングでオリジナルのライブラリを構築することをオススメします。
UIライブラリを選定する際の大きな基準は、「ライブラリのUIをどれだけ変更できるか」です。前述した通り、UIライブラリはすでにコンポーネントのUIデザインが完了した状態で提供されているため、組織のブランドをプロダクトに反映させる点からも、非常に重要なポイントです。
UIライブラリによっては、デフォルトのスタイルを書き換えたり、上書きしやすいように設計・提供しているものがあります。また、コンポーネントのプロパティ設計やアクセシビリティ対応は残したまま、UIのみを初期化する「アンスタイルモード」が提供されているケースもあります。選定時にはこれらの機能の有無もあわせて確認しましょう。
ロードマップの作成
最後に、目的と目標の達成に向けて「デザインシステム構築をどのように進めるか」を示す「ロードマップ」を作成します。
デザインシステムが中期／長期それぞれのスパンで組織にどのような成果を残すのか、そのためにチームがとるべきアクションは何なのかを明らかにするために、ロードマップは必要不可欠です。
ロードマップは準備の初期段階で定義したプロジェクトビジョンに基づいて構築します。
組織で掲げた「目標」を定量的な数値で表し、その目標が達成されることにより、どのタイミングでどのようなアウトカム（状態目標）がもたらされるのかを定義しましょう。数値目標と状態目標が接続されることで、「デザインシステムによって、いつまでにどのような効果が得られるのか」を明確にできます。
状態目標の定義が完了したら、具体的な行動目標を設定します。このときに参考にするのが、事前に設けたプロジェクトビジョンの「行動」です。行動目標はあくまでもロードマップにおける「How」に相当する要素です。行動目標の遂行によって生まれたデザインシステムが、本当に状態目標を達成できているかを常にトラッキングし、場合によっては柔軟にアクションを再定義することも必要です。
まとめ
今回はグッドパッチがデザインシステム構築を支援する際の準備フェーズで行う4つの作業について紹介しました。
- プロジェクトビジョンの策定
- デザインシステムの構造の設計
- 使用するツールや技術の選定
- ロードマップの構築
デザインシステムへのニーズは組織状態や事業フェーズによって変化します。そのため、プロジェクトビジョンやデザインシステムの構造も定期的にアップデートしながらデザインシステムを育てていきましょう。
次回はデザインシステムにおけるプロダクトガイドラインや、コンポーネントをはじめとするアセットの構築方法についてお伝えします。
連載「みんなで育てるデザインシステム」記事一覧
第1回：良いデザインシステムとは？その基本と構造をグッドパッチが解説
第2回：組織にデザインシステムが必要な理由とは──その効果や価値を徹底解説
第3回：デザインシステムのはじめかた──事前に理解しておきたいポイントや構築のための5つのサイクルとは
第4回：グッドパッチが実際に行っているステップ別に解説 デザインシステム構築前の準備フェーズですべきこと（本記事）
第5回：4つの要素で考える、プロダクトデザインのためのデザインシステム構築とは
第6回：適用範囲を広げ、より良いものにするために デザインシステムを“拡張”するポイント
第7回：生成AIで変わる「デザインシステム」の未来
