この記事を書いた人
- 君塚 伴子クリエイティブグループ/デザイナー（ビジネス・アーキテクツ）
異業種・同業種・フリーランスを経験。2000年にウェブ業界に入社後、インタラクティブサイトの構築でアートディレクターとして携わる。2018年よりビジネス・アーキテクツに入社し、WEBデザインシステムの構築を習得。現在は中規模以上案件のUI/UXを踏まえたデザインリードを担当。最近は、FinTech企業のサイト構築にやりがいを感じている。
- 「デザインガイドラインを作成したのに、現場ではあまり参照されない。」
- 「レビューのたびに同じ指摘が繰り返される。」
- 「担当者によって判断が分かれ、画面やコンテンツの品質にばらつきが出る。」
Webサイトやプロダクトの運用現場では、こうしたことが起こりがちです。原因のひとつは、ガイドラインにルールが書かれていても、デザイナー以外の担当者が「どんなときに、どう判断すればよいのか」まで分からないことにあります。
デザインガイドラインは、色や余白、UIコンポーネントの仕様をまとめるだけの技術資料ではありません。デザイナーだけでなく、エンジニアやディレクター、マーケター、外部パートナーなど、実際に制作や運用に関わる人が迷わず使える「共通言語」であるべきです。
本記事では、非デザイナーにも伝わりやすく、作って終わりにならないデザインガイドラインを作るための考え方や作成・運用のポイントを解説します。
デザインガイドラインが形骸化する原因
デザインガイドラインを作ったからといって、そのまま現場で使われるとは限りません。公開当初は参照されていても、時間が経つにつれて使われなくなったり、更新されないままでいると、実際のWebサイトとガイドラインの内容が合わなくなったりすることもあります。
私たちビジネス・アーキテクツ（BA）がWebサイトの制作や運用、デザインルールの整備に関わる中でも、こうした課題に向き合うことがあります。
特に注意したいのが、ガイドラインを作った人と、実際に日々の制作や運用で使う人が異なるケースです。先ほども書いたように、Webサイトにはデザイナーだけでなく、運用ディレクターやマーケター、エンジニア、外部の制作パートナーなど、さまざまな立場の人が関わります。担当者も入れ替わりますし、経験の長さも異なります。
すると、次のようなことが起こります。
- 運用担当者は、「ブランドイメージに合わせる」と書かれていても、具体的にどのレイアウトやクリエイティブを選べばよいのか判断できない。
- エンジニアは、Figma上のデザインを見ても、余白や文字サイズの違いが意図したものなのか判断できず、実装時に確認が必要になる。
- 外部パートナーは、既存のガイドラインでは対応できないケースが出たときに、どのルールを優先し、誰に確認すればよいのか分からない。
- 経験の浅い担当者は、過去の経緯や意図を知らないため、ガイドラインに書かれている内容だけを正解として判断してしまう。
結果として、毎回分かる方に確認したり、過去のページを参考にしながら個別に判断したりするようになり、ガイドラインがあっても十分に活用されない状態が生まれてしまうのです。
ガイドラインが使われなくなる3つの理由
ガイドラインが使われなくなる理由は、プロジェクトや運用体制によってさまざまです。私たちBAでは、実際の制作や運用で起きる課題を整理すると、主に次の3つに分けられると考えています。
- 伝わらない（言語化の壁）
「トンマナを合わせる」「抜け感を出す」といった感覚的な表現だけでは、非デザイナーにとって具体的な判断材料とはなりません。どのレイアウトやどの表現を選べばよいのか分からず、結局その都度デザイナーに確認することになってしまいます。 - 実装につながらない（実装とデザインの乖離）
デザインツール上でルールを作っても、UIパーツの名称や役割、使用条件が実装側のエンジニアとも共有されていなければ、エンジニア側でも都度判断が必要になります。小さな解釈の違いが積み重なることで、デザインと実装にズレが生まれやすくなってしまいますし、なにしろ時間がかかることになります。 - 更新されない（運用の壁）
Webサイトを運用していると、ガイドラインを作った時点では想定していなかったページや機能が増えていきます。そのときに、誰が判断をおこなうのか、ルールを追加できるのか、例外として扱うのかまで決まっていないと、少しずつ独自の判断が増え、ガイドラインと実際のサイトが合わなくなってしまいます。
こうした問題を防ぐには、ルールを増やすだけではなく、関係者が迷ったときに立ち返れる「判断基準」としてガイドラインを設計することが重要です。
目指すべきは「ルール集」ではなく「判断基準」
ガイドラインを使い続けてもらうためには、単に「守るべきルール」を並べるだけでは不十分です。大切なのは、迷ったときに「なぜこのルールなのか」に立ち返り、自分で判断できるようなガイドラインにしておくことです。
私たちBAでも、デザインルールを整理する際には、数値や見た目だけでなく、その背景にある目的や使い分けまで伝えることを意識しています。そのために必要な3つの要素をお伝えします。
①数値だけでなく「なぜそうするのか」まで伝える
例えば、「余白は24px」「ボタンは青」と数値や色だけを決めても、そこにないケースが出てくると判断できなくなり応用が効きません。
「関連する情報なので要素間の余白は24pxにする」「最も促したいアクションにだけ青いボタンを使う」のように、ルールとあわせてその目的や使い分けを例示しておけば、ガイドラインに載っていないケースでも判断しやすくなります。
②個人の注意だけに頼らない
ガイドラインに書かれていても、すべてのルールを毎回確認しながら制作するのは現実的ではありません。できるところは、あらかじめ「仕組み」に組み込んでしまうと徹底されます。
例えばアクセシビリティでは、コントラスト比や音声読み上げへの対応を担当者一人ひとりの注意だけに任せるのではなく、適切な色や文字サイズ、タグ構造を反映した共通パーツを用意しておけば、一定の品質を保ちやすくなります。
ガイドラインに書くだけでなく、実際の制作や実装でそのルールを使いやすい状態まで用意しておく、という考え方です。
③使う人にとってのメリットを考える
ガイドラインは、守るための決まりを増やすものではありません。使うことで日々の仕事が進めやすくなることが最も大切です。
制作・開発側であれば、デザインや実装方法をその都度確認する時間を減らせます。レビューする側にとっても、同じ指摘を繰り返したり、大きな手戻りが発生したりすることを減らせます。
こうした状態をつくるためには、ガイドラインに何を書くかだけでなく、実際の制作や運用の中でどう使ってもらうかまでを考え、ガイドラインに含めておく必要があるのです。
次からは、「ガイドラインに何を盛り込むか」と「作ったガイドラインをどう運用していくか」の2つに分けて見ていきます。
非デザイナーにも使いやすいガイドラインにするために整理したい3つの要素
では、実際にガイドラインには何をまとめておけばよいのでしょうか。
私たちBAでは、デザインルールを整理する際、大きく「基本デザイン」「UIコンポーネント」「デザインパターン」の3つに分けて考えます。
例えば、多くの関係者が制作や運用に関わるWebサイトでは、色や余白だけを決めても十分ではありません。個々のUIパーツをどう使うのか、さらにそれらをどう組み合わせて画面を作るのかまで整理しておくことで、デザイナー以外の人も判断しやすくなります。
特に銀行の口座開設サイトのように、入力フォームやエラー表示などを多く含み、一貫した表現が求められるサイトでは、こうした整理が重要になります。
①基本デザイン（ファンデーション）：判断の土台をそろえる
まず整理するのが、カラー、タイポグラフィー、余白、グリッドなど、Webサイト全体に共通する基本的なルールです。
BAでも、デザインシステム化を見据えたプロジェクトでは、いきなり個々のUIコンポーネントを作るのではなく、先にこうした基盤となる部分の整理から始めることがあります。
例えば、
- カラー
使用する色だけでなく、「この色はどのような場面で使うのか」まで決めておく。例えば、メインカラーのネイビー（#002B62）や、警告色の赤（#D9381E）は「重大な警告・エラー表示のみに使用」といった使用目的も記すようにします。 - 余白
使用できる値を決め、フォーム内、カード内、セクション間など、用途による使い分けを示しておく。例えば、「余白は8の倍数（8px,16px,24px,32px,48px）のみ使用」とルール化し、用途別の値（入力フォーム間16px、カード内24px、セクション間48pxなど）を定義します。
といった形です。
重要なのは、数値を決めること自体ではありません。担当者が変わっても同じ考え方で判断できるよう、使う場面まであわせて整理しておくことです。余白の例では、こうすることでエンジニアがCSS変数として定義しやすくなり、外注パートナーも推測による数値のズレを防ぎやすくなる効果があります。
②UIコンポーネント：デザインと実装で同じものを指せるようにする
次に、ボタンや入力フォーム、モーダル、ナビゲーションなど、繰り返し使用するUIを整理します。ここでは見た目だけでなく、「名称」「役割」「どのような場面で使うのか」までそろえておくことがポイントです。
例えば、「青いボタン」と呼ぶのではなく、「プライマリーボタン＝ユーザーに最も促したい操作に使用する」と決めておけば、デザイナー、ディレクター、エンジニアの間でも同じものを指して話しやすくなります。
Figmaなどのデザインツールと実装側でも、コンポーネントの名称や対応関係をできるだけそろえておくと、確認の手間を減らせます。また、必要に応じてStorybookなどを使い、ホバーやエラー時を含めた実際の挙動を確認できるようにすることもあります。
では、こうした考え方をガイドラインにはどのように記載すればよいのでしょうか。例えば、次のような内容を整理しておきます。
- 名称と役割を明記する
「プライマリーボタン」「セカンダリーボタン」のように名称を統一し、それぞれがどのような役割を持つのかを記載します。 - 使用する場面を示す
「プライマリーボタンは、ユーザーに最も促したい操作に使用する」「セカンダリーボタンは、戻る・キャンセルなど補助的な操作に使用する」といった形で、使い分けの基準を示します。 - デザインと実装の対応関係を示す
Figma上のコンポーネント名と、実装時に使用するクラス名やコンポーネント名をできるだけそろえます。名称を完全に統一できない場合も、どれが対応するのかを一覧で確認できるようにしておきます。 - 状態変化もあわせて示す
通常時だけでなく、ホバー時、フォーカス時、エラー時、非活性時など、状態による見た目や挙動の違いも整理します。必要に応じてStorybookなどを参照できるようにしておくと、実装時にも確認しやすくなります。
このように、単に完成した見た目を載せるのではなく、「何と呼ぶのか」「いつ使うのか」「実装では何に対応するのか」まで確認できる状態にしておくことで、非デザイナーやエンジニアも判断しやすくなります。
③デザインパターン（レイアウト）：組み合わせ方まで示す
UIコンポーネントをそろえても、その組み合わせ方が毎回異なれば、ページ全体の使いやすさや見た目はばらつきます。
そこで、よく使う画面については、コンポーネントをどう組み合わせるのかまでパターンを例示として示すようにします。
例えば口座開設サイトの入力フォームであれば、入力項目の並び順、エラー文の位置、ボタンの配置などをひとまとまりのパターンとして用意します。
こうして「部品」だけでなく「部品の使い方」まで共有しておくことで、ディレクターやマーケターが新しい画面を検討する際にも、既存のルールをもとに考えやすくなるのです。
ここまで紹介した3つの要素を整理しても、ガイドラインは作っただけでは使われ続けません。次に考えたいのが、日々の制作や運用の中でどう使い、更新していくかです。
ガイドラインを使い続けるための「運用設計」
ガイドラインは、作成した時点で完成するものではありません。むしろ完成した瞬間から古くなっていくものとも言えます。Webサイトを運用していれば、新しいページや機能が増え、担当者も変わります。実際のサイトとガイドラインの内容にズレが出てくることもあるでしょう。
そのため私たちBAでは、ガイドラインそのものを作るだけでなく、「誰が更新するのか」「日々の業務のどこで使うのか」「これまでにないケースが出たときにどうするのか」まで考えておくことが重要だと考えています。
①誰が更新するのか（役割）
まず決めておきたいのが、ガイドラインを管理・更新する役割です。
必ずしも専任の担当者を置く必要はありませんが、内容を変更したいときや、ガイドラインに載っていないケースが出たときに、誰に相談すればよいのかは明確にしたいです。
BAでは、デザイナーやフロントエンドエンジニアなどを中心に更新担当を決め、Slackなど普段使っているツールに相談先を用意する方法を採用しています。
相談のあった内容や例外対応を一定（月次や半期に1回などプロジェクトによって変わります）のタイミングで振り返り、必要に応じてガイドラインへ反映していくことで、実際のWebサイトとのズレも小さくできます。
②日々の業務のどこで使うのか（プロセス）
ガイドラインをリリース直前だけに確認する資料にしてしまうと、制作途中で生じたズレを最後にまとめて直すことになります。
そこで、普段の制作フローの中で参照するタイミングを決めておきます。
例えば、
- ディレクターがワイヤーフレームを作成するとき
- デザイナーがデザインレビューをするとき
- エンジニアが共通コンポーネントを使って実装するとき
などです。
ガイドラインのために新しい作業を増やすというより、もともとの制作・レビュー工程の中で自然に確認できるようにしておくほうが、継続して使いやすくなります。BAでは、こうした普段の制作・レビュー工程の中でガイドラインを参照できるように運用を設計しています。
③これまでにないケースが出たときにどうするのか（例外時の判断）
運用を続けていくと、ガイドラインだけでは判断できないケースは必ず出てきます。そのたびに個別の判断を積み重ねてしまうと、少しずつルールが崩れていきます。
そのためBAでは、例外が出た場合の判断の流れも決めています。例えば、次のような流れです。
- ガイドラインでは判断できない理由や背景を整理する。
- 既存のルールやコンポーネントで対応できないか確認する。
- 対応できない場合は、既存のデザイン方針や原則と照らして追加・変更の必要性を判断する。
- 新しいルールとして採用する場合は、ガイドラインや関連するデータ・コードにも反映する。
ガイドラインを「一度決めたら変えてはいけないもの」にするのではなく、Webサイトの変化に合わせて見直せるようにしておくことも、長く使い続けるためのポイントです。
この3点をあらかじめ決めておくことで、ガイドラインを作ったまま放置せず、実際の運用やWebサイトの変化に合わせて見直しやすくなります。
まとめ：ガイドラインは品質を維持するための仕組み
デザインガイドラインは、デザイナーだけが使うルール集ではありません。運用ディレクターやマーケター、エンジニア、外部パートナーなど、Webサイトに関わる人が同じ基準で判断するためのものです。
そのためには、色や余白などのルールをまとめるだけでなく、「なぜそのルールなのか」「どのような場面で使うのか」まで伝え、さらに日々の制作や運用の中で使い続けられる仕組みを整えておくことが大切です。
判断の基準がそろえば、その都度デザイナーに確認したり、同じ内容を何度もレビューしたりする手間を減らしやすくなります。担当者が変わっても一定の品質を保ちやすくなり、Webサイトの変化に合わせてガイドライン自体も見直していけます。
ガイドラインを「作って終わり」の資料にせず、実際の制作や運用の中で使い続けられるものにすることが、デザイン品質を維持していくうえで重要です。