今日の問い
その画面案で確かめたいのは、色ですか、それとも操作の順序ですか。
30秒でつかむ
低忠実度プロトタイプは、細かな見た目を抑えた試作品です。今回確かめるのは、主要タスクを始められるか、判断に必要な情報があるか、迷ったとき戻れるかの三点です。
完成品らしさは要りません。前回までに作った構造、フロー、状態を、短時間で触れる形へ変えます。
30秒図解 · LESSON 18
循環図
粗く作り、早く間違いを見つける
見た目を抑えるほど、構造と行動へ議論を集中できます。
- 01仮説を描く
- 02触ってもらう
- 03迷いを観察
- 04構造を直す
CLUE · 見抜く手掛かり
捨てられる速さで作れているか
TRAP · ありがちな罠
きれいにして評価を取りに行く
原則
プロトタイプは完成品の縮小版ではなく、設計仮説を確かめるための候補案です。何を学びたいかで、作る範囲と忠実度を決めます。
まず primary-flow.md の成功経路を、灰色の箱、見出し、ボタンでつなぎます。各画面にはサイトマップのIDと、そこで利用者がする判断を注釈します。装飾を減らすと、議論を構造と順序へ向けやすくなります。
次に ui-states.md から、主要な失敗経路を一つだけ加えます。すべての例外を作り込むより、今回の問いに関係する状態を操作できることが大切です。リンクのないボタンは、未実装なのか意図的に対象外なのか区別します。
試す前に、課題文を一文で用意します。「予約を変更する画面を探してください」と誘導せず、「来週の予約を金曜日へ変更してください」と目的だけを渡します。説明しないと進めない場所があれば、画面側の課題として記録します。
低忠実度でも、文字が読めないほど粗くする必要はありません。実在する個人情報は使わず、内容を判断できる架空データを入れます。速く捨てられ、同じ問いでもう一案を作れる程度が適切です。
プロトタイプを設計仮説として扱い、調査目的や資源に応じて忠実度と操作範囲を選ぶ考え方を支える。
良い例と惜しい例
最初に作る試作品
AIへの指示例
目的: 予約変更の構造と操作順を確認できる低忠実度プロトタイプを作る
制約: 色は白、灰色、黒の3色まで。写真、影、アニメーションは使わない。実在する個人情報は使わない。対象外の操作は非活性と明記する
参照: sitemap.md、primary-flow.md、ui-states.md
受入条件: wireframes/に入口、予約選択、日時選択、確認、結果の5画面を作り、成功経路と空きなし経路をクリックでたどれる。各画面にidと検証したい判断を注釈する
確認問題
セルフチェック
1. 最初のテストで『予約変更の入口を見つけられるか』を確かめたいとき、優先すべき試作品はどれですか。
最終制作へ反映する
主要タスクの低忠実度プロトタイプ
サイトマップ、主要フロー、画面状態表を参照し、成功経路と重要な失敗経路を操作できる画面群をwireframes/へ作る。
Acceptance criteria
- 主要タスクを入口から成功確認まで操作でき、少なくとも一つの失敗経路から戻れる
- 各画面に対応するidと検証したい判断が注釈され、装飾の検討と分離されている
今日のまとめ
- 低忠実度プロトタイプは、設計仮説を安く早く確かめるために作る
- 検証したい問いに必要な画面と分岐だけを操作可能にする
- 次は、この構造を保ったまま視覚階層で読む順番を作る