フレームワーク活用ガイドひとことで言うと#
「この問題にはこのデザインが最適」という解決策のカタログ。ログインフォーム、検索UI、ページネーション、エラー表示——こうした繰り返し登場するUIの問題に対する「ベストプラクティス集」をチームで共有管理する仕組み。毎回ゼロから考えるのではなく、検証済みのパターンを選んで適用する。
押さえておきたい用語#
- デザインパターン
- 繰り返し発生するUI/UXの問題に対する検証済みの解決策。問題・コンテキスト・解決策・根拠をセットで記述する。
- パターンランゲージ
- クリストファー・アレグザンダーが提唱した、問題と解決策の関係性を言語化した体系。建築分野からソフトウェアに応用された。
- アフィニティマッピング
- 大量のパターンやアイデアを類似性に基づいてグループ化し、分類体系を作る手法。
- バリエーション
- 同一パターンのコンテキストに応じた変形版。例：データテーブルの「インライン編集あり版」と「読み取り専用版」。
デザインパターンライブラリの全体像#
こんな悩みに効く#
- 同じようなUIを毎回ゼロからデザインしている
- デザイナーによって同じ機能のUIが違う形で実装されている
- 新しいデザイナーが入ると、過去の設計意図が伝わらない
基本の使い方#
デザインパターンは単なるスクリーンショット集ではない。各パターンに以下の構造を持たせる。
パターンの構成要素:
| 要素 | 内容 | 例（検索UI） |
|---|---|---|
| パターン名 | わかりやすい名前 | 「インクリメンタルサーチ」 |
| 問題 | どんな課題を解決するか | 大量のデータから素早く目的の項目を見つけたい |
| コンテキスト | いつ使うべきか | データが100件以上、検索頻度が高い場合 |
| 解決策 | 具体的なデザイン | 入力と同時に候補をリアルタイム表示 |
| 根拠 | なぜこのパターンが有効か | ユーザーの認知負荷を下げ、目的到達時間を短縮 |
| バリエーション | 異なるコンテキストでの変形 | フィルター付き、カテゴリ別表示 |
| 使用例 | 実際のプロダクトでの適用 | 商品検索ページ、ユーザー一覧 |
この構造があることで「なぜこのパターンなのか」が伝わり、誤用を防げる。
ゼロから作るのではなく、まず既存プロダクトに存在するパターンを棚卸しする。
パターン抽出のプロセス:
- スクリーンショット収集: プロダクトの全画面をキャプチャ
- 類似UIのグルーピング: 同じ役割を持つUIをまとめる（フォーム、リスト、モーダル等）
- 差異の分析: 同じ役割なのにデザインが異なる箇所を特定
- ベストの選定: 最もユーザビリティが高いバージョンを選ぶ
- ドキュメント化: 上記の構造に従って記述
よくある発見: 同じ「削除確認ダイアログ」が画面によって3パターン存在する → 最良の1パターンに統一。
パターンが増えると探しにくくなるため、分類体系が重要。
推奨する分類軸:
ユーザー行動ベースの分類:
| カテゴリ | パターン例 |
|---|---|
| ナビゲーション | タブ、サイドバー、パンくずリスト、ページネーション |
| データ入力 | フォーム、日付ピッカー、ファイルアップロード |
| データ表示 | テーブル、カード、リスト、グラフ |
| フィードバック | トースト通知、モーダル、プログレスバー |
| アクション | ボタン群、ドロップダウン、コンテキストメニュー |
| 検索・フィルタ | 検索バー、ファセット、ソート |
各パターンに「いつ使う / いつ使わない」を明記する。 選択の判断基準がないカタログは使われない。
作って終わりではなく、生きたライブラリとして運用するルールを決める。
運用に必要な仕組み:
| 項目 | 内容 |
|---|---|
| 管理場所 | Figma ライブラリ + Wiki（ドキュメント） |
| 追加プロセス | 新パターンの提案 → レビュー → 承認 → 登録 |
| 更新サイクル | 月1回のレビュー会議 |
| オーナー | デザインリード or デザインオプス担当 |
| バージョニング | 変更履歴を記録、非推奨パターンは「Deprecated」表示 |
パターンの追加基準:
- 2回以上同じ問題が出現した
- ユーザーテストで有効性が確認された
- 既存パターンでは解決できない新しい問題である
安易にパターンを増やさない。 パターンが多すぎると逆に選択が困難になる。
具体例#
状況: B2B SaaS。デザイナー4名。新機能のデザインに毎回2〜3週間かかる。UIの一貫性についてエンジニアから「同じ機能なのに画面ごとにUIが違う」と指摘が頻発。
取り組み:
- 2週間かけて既存プロダクトの全画面（87画面）を棚卸し
- 48種類のUIパターンを特定、うち23種類に不統一を発見
- 各パターンのベスト版を選定し、構造化してドキュメント化
- Figmaにコンポーネントライブラリとして登録
6ヶ月後の変化:
- 新機能のデザイン期間: 2〜3週間→1〜1.5週間（約50%短縮）
- UIの不統一に関するバグ報告: 月12件→月2件
- 新デザイナーのオンボーディング: 「ライブラリを見て」で初週から戦力化
- エンジニアの実装速度も向上（パターンが決まっているのでコンポーネント再利用が増えた）
状況: ECプラットフォーム。棚卸しの結果、「削除確認ダイアログ」が画面によって3種類存在していた。
- パターンA: テキストのみの確認ダイアログ（商品削除）
- パターンB: アイコン付きの警告ダイアログ（カート商品削除）
- パターンC: 入力確認付きダイアログ（アカウント削除）
分析結果:
- パターンAはユーザーテストで「重要度が伝わらない」（誤操作率8%）
- パターンBは視認性が高く誤操作率2%
- パターンCは「不可逆な操作」向けとして必要
統一方針:
- 通常の削除: パターンBに統一（アイコン付き警告）
- 不可逆な削除: パターンCを使用（テキスト入力確認）
- パターンAは廃止（Deprecated表示）
結果: 削除操作の誤操作率が全体で8%→2.5%に改善。 サポートへの「間違えて消した」問い合わせが月23件→5件に減少。
状況: ヘルスケアアプリ。健康データの入力フォームが画面ごとに異なるデザインで、ユーザーの入力完了率が低い（平均56%）。
パターンライブラリ整備:
- 日付入力: カレンダーピッカー（iOS標準準拠）
- 数値入力: ステッパー + 直接入力（体重・血圧向け）
- 選択肢: チップ選択（3〜5個）/ ドロップダウン（6個以上）
- テキスト入力: フローティングラベル + バリデーション即時表示
- 全フォームに「自動保存」パターンを適用（入力途中で離脱してもデータ保持）
結果: 統一されたフォームパターン適用後、入力完了率が56%→75%に改善（+34%）。 ユーザーインタビューでは「前より入力が楽になった」の声が多数。特に自動保存パターンの効果が大きく、中断→再開の復帰率が12%→68%に向上。
やりがちな失敗パターン#
- スクリーンショット集にしてしまう — 画像だけ並べても「いつ使うか」「なぜこのデザインか」がわからない。問題→コンテキスト→解決策の構造を必ず含める
- 最初から完璧を目指す — 全パターンを網羅しようとして半年経っても公開できない。主要10パターンから始めて、順次追加する
- 作ったら放置する — プロダクトは進化するのにライブラリが古いまま。現実と乖離し誰も使わなくなる。月1回の更新サイクルを設ける
- 判断基準なしにパターンを増やす — パターンが多すぎると選択に迷い、かえって効率が下がる。追加基準（2回以上出現・テスト済み）を設けて厳選する
まとめ#
デザインパターンライブラリは、繰り返し登場するUI/UXの問題に対するベストプラクティスを構造化して管理する仕組み。単なる画像集ではなく、問題・コンテキスト・解決策・根拠を含む構造が重要。既存プロダクトの棚卸しから始め、分類体系と運用ルールを整備することで、デザインの一貫性と速度を同時に向上させられる。