前回の続きと、この講義の役割
前回のH-09では、画面幅に応じてレイアウトを組み替えるレスポンシブデザインを学びました。今回はカテゴリHの締めくくりとして、これまで扱ってきた画面設計のルールを、アプリ全体で使い回せる資産にまとめます。それがデザインシステムです。一枚ずつ良い画面を作る話から、良い画面を仕組みで量産する話へと進みます。
このスライドのポイント
- 前回H-09: 画面幅に応じてレイアウトを組み替えるレスポンシブデザイン
- 今回: カテゴリHの締めくくり。画面設計のルールをアプリ全体で使い回せる資産にまとめる
- 「一枚ずつ良い画面を作る」から「良い画面を仕組みで量産する」へ
デザインシステムとは
デザインシステムとは、色、文字サイズ、余白の単位、共通部品、そして状態の見せ方を、アプリ全体の共通規則としてまとめ、文書や部品の形で管理したものです。ここでいう共通部品とは、ボタンや入力欄のように何度も使い回す画面の単位を指します。その具体的な作り方、つまり実装はカテゴリIで扱いますので、この講義では設計として捉えてください。状態の見せ方は、H-06からH-08で学んだ状態や空状態、フィードバックの表現を含みます。いわば、E-07で学んだ関数化を、見た目の世界に持ち込んだものだと考えてください。
このスライドのポイント
- デザインシステム＝色・文字サイズ・余白の単位・共通部品・状態表現を、アプリ全体の共通規則として文書化・部品化したもの
- 共通部品＝ボタン等の再利用単位（実装方法はカテゴリIで扱う）
- 状態表現＝H-06〜H-08で学んだ状態・空状態・フィードバックの見せ方
- E-07の関数化の「見た目版」
なぜ必要か
デザインシステムを持たないと、AIに画面を頼むたびに、少しずつ違うボタンや違う余白が生まれます。その結果、アプリ全体が画面ごとにちぐはぐな印象になります。しかも修正のときは、全画面を一つずつ個別に直すことになり、手間が膨れ上がります。これは、共通化せずに同じ処理を何度も書いたコードと、まったく同じ症状です。
このスライドのポイント
- 規則がないと、AIに頼むたびに少しずつ違うボタン・違う余白が生まれる
- 結果: アプリ全体が画面ごとにちぐはぐな印象になる
- 修正も全画面を個別対応することになり、手間が膨れ上がる
- 共通化せず同じ処理を何度も書いたコードと同じ症状
最小のデザインシステム
最小のデザインシステムは、四つの要素から始められます。色は、主となる色を一つと、文字や境界に使うグレーの階調に絞ります。文字は、見出し・本文・補足のように三段階のサイズを決めます。余白は、8ピクセルの倍数だけを使うと決めておくと、間隔が自然に揃います。部品は、主要なボタン二種類、入力欄、情報のまとまりを表す単位など、よく使うものだけをまず定義します。最初から完璧を目指さず、小さく決めて、必要に応じて育てていくのが現実的です。
具体例
具体例を見てみましょう。たとえば経費申請アプリで、ボタンの角の丸みを少し変えたくなったとします。デザインシステムがあれば、規則を一か所直すだけで、全画面のボタンにその変更が反映されます。もし規則がなければ、五十画面あれば五十回、同じ修正を手作業で繰り返すことになります。これは、B-09で学んだ値の一元管理を、見た目に当てはめたものでもあります。一度決めて共通化しておけば、変更に強くなるのです。
このスライドのポイント
- 例: 経費申請アプリでボタンの角の丸みを変えたい
- 規則あり: 一か所の修正で全画面のボタンに反映
- 規則なし: 50画面あれば50回、手作業で修正
- B-09の「値の一元管理」の見た目版
技術サンプルカード
スライドのサンプルは、AIに共通規則を守らせるための定型指示です。色や余白、ボタンの種類といった規則を、依頼のたびに文章としてそのまま渡します。読み方のポイントは二つです。一つは、同じ規則を毎回渡せば、AIが作る画面の見た目が自然に揃うこと。もう一つは、実務ではこの規則を一つのファイルにまとめてプロジェクトへ置き、繰り返し参照させる形をとることです。AIへの質問例は、できあがった画面が規則から外れていないかを点検するときに使います。
混同しやすい概念
混同しやすいのが、毎回きれいに作ることと、規則で揃えることの違いです。一見すると、毎回丁寧に作れば品質は上がりそうに思えます。しかし、その都度の判断に任せると、作る場面やAIへの頼み方によって、結果は少しずつばらついていきます。頑張るほどばらつくのです。安定した品質は、頑張りではなく、あらかじめ決めた規則から生まれます。
バイブコーディングでの確認点
確認点です。プロジェクトを始めるときに、まず色・文字・余白・部品という最小の規則を決めておきましょう。そして、AIに画面を頼むたびに、その規則をあわせて渡します。生成された画面については、規則から外れた箇所がないかを毎回チェックします。AIには「この画面で共通規則から外れている箇所を指摘してください」と聞くと、自分では気づきにくいばらつきを洗い出せます。
このスライドのポイント
- プロジェクト開始時に、最小の規則（色・字・余白・部品）を決めておく
- AIに画面を頼むたびに、その規則をあわせて渡す
- 生成後は「規則から外れた箇所はないか」を毎回チェックする
- 質問例:「この画面で共通規則から外れている箇所を指摘してください」
一問一答とまとめ
最後に一問一答です。画面ごとのばらつきを防ぐ仕組みは何でしょうか。……答えは、デザインシステムです。共通の規則と共通部品で、アプリ全体の見た目を揃えます。三十秒のまとめです。デザインシステムとは、色・文字・余白・部品・状態表現をアプリ全体の共通規則にまとめたもので、品質はセンスではなく規則から生まれます。これでカテゴリHは修了です。画面を設計として判断する基準が一通り揃いました。次回からはカテゴリI、いよいよReactを使って、これまで設計してきた画面や共通部品を実際に実装していきます。関連資料は「SaaS画面パターン100」「管理画面UIパーツ集」「UI改善プロンプト50」です。
このスライドのポイント
- 一問一答:「画面ごとのばらつきを防ぐ仕組みは？」→ デザインシステム（共通規則と共通部品）
- 30秒まとめ: 色・字・余白・部品・状態表現を全体の共通規則にまとめる。品質は規則から生まれる
- カテゴリH修了。画面を「設計として」判断する基準が揃った
- 次回: カテゴリI、Reactによる画面の実装へ
- 関連資料:「SaaS画面パターン100」「管理画面UIパーツ集」「UI改善プロンプト50」
