1 ワイヤーフレームの概要
1.1 定義と目的
1.1.1 構造を先に決める考え方
ワイヤーフレームは、画面における要素の位置関係や、ユーザーが辿る流れを中心に検討するための設計図である。視覚的な質感や配色の完成度よりも、情報の階層、機能の配置、入出力の順序といった骨格を先に固める点に特徴がある。この順序により、後工程でデザインや実装に進んだ際の手戻りを抑えやすくなる。
1.1.2 コミュニケーション支援としての役割
関係者間で「何をどこに置くか」「どの操作で何が起こるか」を共有するための共通言語として機能する。文章だけでは伝わりにくい画面内の関係性を、単純な線や枠、仮の部品で視覚化するため、認識のズレを初期段階で発見しやすい。また、合意形成の材料として、議論の焦点を装飾から要件へ移す効果がある。
1.2 ワイヤーフレームで表す要素
1.2.1 レイアウトと情報配置
画面上の区切り、見出しの位置、主要コンテンツのまとまり、補助情報の扱いなど、情報の並びを表す。典型的にはヘッダー、メイン領域、サイドやフッターなどのブロックに分け、重要度の高い要素ほど目立つ場所に配置する方針が示される。これにより、ユーザーが最初に読むべき領域や、読み進めの順序が見える化される。
1.2.2 コンポーネントと状態
ボタン、入力欄、選択肢、リスト、カードなどの部品を配置し、同時に状態も整理する。例として、入力フォームでのエラー表示、読み込み中の表示、選択中の見え方、無効状態などが該当する。状態まで含めることで、単なる配置図ではなく「操作の結果」までの理解につながる。
1.2.3 導線と画面遷移の考え方
リンクやボタンを起点に、次にどの画面へ進むか、どの情報が持ち越されるかといった導線を意識する。ページ単体のレイアウトだけでなく、ユーザーの行動がどの経路で完了するか、迷わない流れが設計されているかを確認できる。必要に応じて、分岐（条件により別の画面へ進む場合）や戻り経路も図示する。
2 作成プロセス
2.1 企画・要件の整理
2.1.1 ユーザー像と利用シーンの把握
まず、利用者の目的や前提知識、操作環境を把握する。たとえば初回利用者か、頻繁な利用者か、スマートフォン中心か、デスクトップ中心かといった違いが画面構成に影響する。さらに「いつ」「どのような状況で」使うかを想定し、短時間で判断できる情報の組み方や、迷いが起きやすい場面のケアを検討する。
2.1.2 機能要件の棚卸し
実現すべき機能を列挙し、画面に落とし込む単位に分解する。入力が必要な箇所、選択が必要な箇所、結果を表示する箇所、確認や訂正の工程などを整理し、各機能がどの画面で発生するかを対応づける。ここで抜けがあるとワイヤーの段階で矛盾が生じやすいため、要件を網羅する意識が重要になる。
2.1.1 優先度付けとスコープ決定
機能の重要度と緊急度を踏まえ、まずは最小限で成立する範囲を決める。優先度が高い機能は導線の中心に置き、低優先度のものは後回しにするか、段階的な導入を前提に配置する。スコープの線引きにより、ワイヤーフレームが「全部入りの図」ではなく「検証に耐える設計」に保たれる。
2.2 ワイヤー作成
2.2.1 低忠実度（スケッチ）から始める手順
手を動かす順序として、最初に大枠のブロック配置を素早く描く。細部の文言や見た目に時間を費やすより、画面の役割（何のための場所か）を確定させることを優先する。複数案を並べて比較できる状態にしておくと、代替案の議論がしやすくなる。
2.2.2 グリッド・整列の基本
低忠実度でも、整列のルールは検討価値が高い。グリッドを使って余白や要素間隔の基準を設けると、画面の読みやすさや実装時の調整がスムーズになる。整列は見た目だけでなく、情報のまとまりを視覚的に規則化する役割も担うため、ワイヤーの段階で最低限の整合性を取る。
2.2.3 注釈（意図・例外ケース）の書き方
注釈は、図だけでは伝わらない意図を補うために記す。たとえば「ここはユーザー権限により非表示」「エラー時のみメッセージが出る」「次の画面へ進むと入力値が保持される」といった条件が対象になる。言い切りではなく根拠や前提を添えると誤解が減る。例外ケースを明示しておくと、後から仕様が増殖する事態を抑えやすい。
2.3 レビューと反復
2.3.1 誰が見るか（関係者の選定）
レビュー対象は、利用者側の視点と、実現側の視点を両方含めるのが望ましい。プロダクト担当、デザイナー、エンジニア、場合によっては企画やカスタマーサポートが関与する。特定の視点だけでは、導線の破綻や実装上の制約が後工程に回る可能性があるため、役割に応じた確認観点を割り当てる。
2.3.2 フィードバックの反映基準
受け取った指摘は、重要度と影響範囲で整理し、反映の優先順位を決める。ユーザーの理解に直結する不明点や、主要な操作導線の破綻は優先度が高い。一方で見た目の好みのような主観は、忠実度が上がってから議論するなどタイミングを選ぶことで、焦点がぶれにくい。決定理由を簡潔に記録することで、次の反復が効率化される。
2.3.3 バージョン管理の実務
ワイヤーフレームは段階的に改訂されるため、版の追跡が必要になる。ファイル名や更新履歴を整理し、どの変更がどの要件に対応したかが分かる状態にする。共同作業では、コメントや変更提案の履歴を残し、承認者がどの状態を採用したかを明確にすることが望ましい。
3 形式と忠実度の違い
3.1 低忠実度ワイヤーフレーム
3.1.1 スケッチ型の特徴
スケッチ型は、手早く描くことを前提としている。線や簡略化された枠で画面要素の配置を表し、文言やスタイルは最低限に留めることが多い。検討の目的がアイデアの探索や方向性の比較にある場合、速さが価値になる。
3.1.1 目的に応じた粒度
低忠実度でも、議論したい範囲に応じて粒度を調整する。たとえば全体の情報構造を検証するなら、主要ブロックと見出しの階層が中心になる。導線の妥当性を確かめるなら、遷移の起点や分岐の有無を強調する。目的に合わせて「十分な情報」と「不要な詳細」を線引きすることが重要である。
3.2 中忠実度ワイヤーフレーム
3.2.1 タイポグラフィの扱い
中忠実度では、文字の大きさや見出しの階層など、読みやすさに関わる要素をある程度示す。厳密なフォント指定である必要はないが、重要情報が目に入りやすいように階層を反映する。これにより、文量や配置が情報設計の意図と整合しているかを評価しやすい。
3.2.2 ボタン・フォームなどの具体化
ボタンのラベルやフォームの項目、入力形式（例：選択式か、自由入力か）を具体化し、操作の意味を伝える。エラーメッセージの位置や、必須項目の表示方法なども明らかにすることで、ユーザーが迷うポイントを減らせる。さらに、状態（未入力、入力済み、送信可否）を図の一部として示すことが多い。
3.3 高忠実度との境界
3.3.1 モックアップ／デザイン案との関係
高忠実度へ近づくほど、見た目の要素が増え、ワイヤーの役割は「構造の検証」から「体験のイメージ合わせ」へ移行する。境界としては、色や細かな余白、詳細なコンポーネント仕様が入り始める段階が目安になる。ワイヤーフレームは最終的な完成図ではなく、設計判断を支える中間成果物として位置づけられる。
3.3.2 プロトタイプへの接続方針
プロトタイプでは、操作可能な形で挙動を確かめるため、ワイヤーの情報がそのまま入力になる。接続方針として、どの画面をまず動かすか、主要な状態（読み込み、成功、失敗）をどこまで用意するかを決める。ワイヤー段階で遷移と状態が整理されているほど、プロトタイプ化の手戻りが減りやすい。
4 実務上のポイント
4.1 情報設計の観点
4.1.1 見出し階層とコンテンツの位置
見出しの段階や、本文・補足・補助リンクの位置関係を明確にする。情報の優先度が曖昧だと、画面全体の意図が伝わらず、利用者が迷う原因になる。ワイヤーでは、階層が視線の流れに沿って配置されているかを確認することが中心となる。
4.1.2 ナビゲーション設計の整理
ナビゲーションは、現在地の把握と移動のしやすさに関係する。トップメニュー、サイドナビ、パンくずリスト、検索導線などをどう組み合わせるかを整理する。画面内での移動だけでなく、上位階層へ戻る動線や、目的に直行する導線の存在が重要である。
4.2 アクセシビリティへの配慮
4.2.1 見やすさ（コントラスト以外も含む）の考え方
アクセシビリティは色だけで判断されない。情報の区別が形状や配置に依存しているか、読み取りができる余白設計になっているか、文字の密度が高すぎないかなどを検討する。ワイヤーの段階でも、テキストがどのくらいのスペースを占めるか、長文化した場合に破綻しないかの見立てが有効である。
4.2.1 主要操作の分かりやすさ
主要な操作は、ユーザーが「何ができるか」「次に何が起きるか」を理解できる形で提示する必要がある。ボタンや入力要素の役割が明確か、ラベルが意味を持つか、エラー時の案内がどこに現れるかを検討する。さらに、キーボード操作や支援技術での利用を想定し、視覚情報に頼りすぎない構成にすることが求められる。
4.3 よくある失敗と対策
4.3.1 画面が増えすぎる問題
ワイヤー作成が進むにつれ、必要性が薄い画面や条件付きの分岐が増えて管理が難しくなることがある。対策として、目的達成に直結する画面を優先し、例外は統合して扱うか、注釈で吸収する判断が有効である。また、同種の画面をテンプレート化して差分だけを示すと、全体像の把握が容易になる。
4.3.2 注釈不足による誤解
配置図が整っていても、条件や例外が注釈されていないと誤解が生じる。対策として、状態変化や権限差、入力の必須性、表示のタイミングなど、仕様が絡むポイントを重点的に記す。レビュー時に「この場合はどうなるか」を質問できる粒度にしておくと、後での齟齬を減らせる。
4.3.3 仕様が固まる前に細部へ寄りすぎること
忠実度を上げるほど描き込みは増えるが、要件が未確定な段階で細部に時間を使うと、変更が連鎖しやすい。対策として、確定している前提と未決事項を分けて扱い、未確定部分は仮置きやラベル化で整理する。反復のたびに、学習で得た知見に基づいて必要な部分だけを更新する運用が有効である。