見たいものを先に見せる

考え方

見たいものを先に見せ、方法はそのあとで選ばせる。

ユーザーが見たいのは「もの」（オブジェクト）であり、「方法」（手段）ではない。方法を先に選ばせると、ユーザーは毎回「どれを選べばいいか」を考えることになる。

原則

方法を先に選ばせる	見たいものを先に見せる
入口が方法ごとに分かれる	入口はオブジェクトで1つ
方法を選ばないと見たいものが見られない	見たいものを見ながら方法を選べる
方法を間違えると戻ってやり直し	その場で別の方法に切り替えられる
画面名が動詞・手段になる	画面名が名詞・オブジェクトになる

避けたい構造

目指す構造

具体例

例1: モバイルオーダー

方法を先に	見たいものを先に
「受け取り方法を選ぶ」→「店舗を選ぶ」→ やっとメニューが見られる	メニュー画面で商品を見ながら、店舗をドロップダウンで選ぶ
店舗を変えると受け取り方法からやり直し	店舗を変えてもメニュー画面のまま

ユーザーが見たいのは「メニュー（商品）」。店舗や受け取り方法は手段に過ぎない。

例2: ポイント送信

方法を先に	見たいものを先に
「IDで送る」「連絡先で送る」「QRで送る」と入口が3つ	ポイント画面で「送る」を選ぶと送信フォームが開く
手段ごとに別画面、同じ確認フローが重複	フォーム内で方法をラジオで切り替え

ユーザーがやりたいのは「ポイントを送る」こと。ID・連絡先・QRのいずれも手段に過ぎない。

例3: 商品検索

方法を先に	見たいものを先に
「カテゴリから探す」「キーワードで探す」「人気順で探す」と入口が分かれる	商品一覧画面で、フィルタ・検索・並び替えを同時に使える
検索方法を変えると別画面に遷移	同じ画面内で条件を組み合わせられる

ユーザーが見たいのは「商品」。検索方法は手段に過ぎない。

例4: 書類提出

方法を先に	見たいものを先に
「郵送で提出」「窓口で提出」「オンラインで提出」と入口が分かれる	申請画面で内容を入力し、最後に提出方法を選ぶ
提出方法によって入力画面が別	入力内容は共通、提出方法だけ最後に選択

ユーザーがやりたいのは「申請する」こと。提出方法は手段に過ぎない。

なぜ逆のパターンが生まれやすいか

「方法を先に選ばせる」設計は、意図せず生まれやすい。

DBの構造に引きずられる

データベースが stores → products（店舗 → 商品）という親子構造だと、「まず店舗を選ぶ → その店舗の商品を表示」という画面設計になりやすい。

しかし、ユーザーの関心は逆であることが多い。ユーザーは「商品」を見たいのであって、「店舗」はその属性にすぎない。

分岐処理を先に確定させたい

「持ち帰りなら税率8%、店内なら10%」といった業務ルールがあると、先に受け取り方法を決めないと処理できないと考えがちだ。

しかし、確定が必要なのは最終処理のタイミングだけ。それまでは両方の可能性を保持しておけばいい。

業務フローをそのまま画面にする

業務マニュアルが「店舗確認 → 受け取り方法確認 → 注文受付」という順序だと、その順で画面を作りがちだ。

しかし、業務フローは「処理する側」の手順。「利用する側」が見たい順序とは限らない。

見分け方

画面名が動詞や手段になっていたら、方法を先にしている兆候。

兆候	例
画面名が「〜を選ぶ」「〜で送る」	「受け取り方法を選ぶ」「IDで送る」
入口が手段ごとに分かれている	「ID検索」「連絡先から」「QRで読み取り」
条件を先に選ばないと先に進めない	「まず店舗を選んでください」

画面名は「何を見ているか」（名詞）で付ける。「メニュー」「ポイント」「商品一覧」のように。

実践

入口はオブジェクトで1つに

• 避ける: 「IDで送る」「連絡先で送る」と手段を入口にする
• 目指す: 「ポイント」という1つの入口から、送信フォームを開く

方法は画面内で切り替え可能に

複数の方法がある場合、別画面にせず、同じ画面内で切り替えられるようにする。ユーザーが方法を間違えても、その場で別の方法に変えられる。

チェックリスト

• 入口が「方法」で分かれていないか
• 画面名が手段になっていないか
• 方法を変えるために、戻って別の入口を選ばせていないか
• 見たいものを見る前に、方法の選択を強制していないか

関連する原則

• 画面名は「何を見ているか」で名付ける — 画面名をオブジェクトにする
• モードレスを優先する — 方法の切り替えを画面内で完結させる