Web画面には、見出し、説明、ボタン、検索、関連記事など多くの要素があります。
すべてを同じ強さで並べると、読者は自分が何をすればよいかを探す必要があります。
優先度の設計は、画面の目的と利用者の現在地から始めます。
架空の講座申込ページを使い、主要操作と補助操作を分け、スマートフォンや拡大表示でも必要な情報へたどり着ける配置を考えます。
この記事で学ぶこと
- 主要な操作の表示を移動先の内容とそろえます。
- 判断に必要な条件を操作前に示します。
- 小さい画面で情報や操作が隠れないか確認します。
一画面の主目的を一文にする
画面ごとに、利用者が何を完了するかを決めます。
講座詳細なら参加条件を理解して申込みへ進む、確認画面なら入力内容を確認して送信する、完了画面なら受付結果と次の案内を知る、と役割が変わります。
同じサイトでも、すべての画面の主目的が購入とは限りません。
主目的は、サービス側の利益だけでなく利用者の必要と一致させます。
詳細を確認したい人へいきなり入力を求めると、判断材料が不足します。
逆に入力中の人へ大量の関連記事を見せると、進行を妨げる場合があります。
現在地に必要な情報と操作を選んでください。
架空の申込ページでは「日時、費用、対象を確認し、参加を申し込む」と書きます。
申込みを支える問い合わせは補助操作に置きます。
資料請求や別講座の購入を同じ大きさで並べる必要があるかは、この目的に照らして判断します。
例外的に複数の目的を扱う一覧画面もあります。
そこで無理に一つの商品だけを押し出すのではなく、「条件に合う講座を選ぶ」を主目的にできます。
選ぶ画面と申し込む画面で優先度を変えると、読者の行動へ合った構成になります。
表示が整っていても、読み込み中に要素が大きく移動すると、別のボタンを押してしまう可能性があります。
画像や追加情報が表示される前後で配置を確認します。
静止画の完成図だけでなく、画面が表示され操作される過程も情報の優先度の検証に含めます。
判断に必要な情報を先へ置く
上へ置くべき情報は、読者が次の操作を選ぶために必要な情報です。
講座詳細では対象、内容、日時、費用などが候補です。
運営会社の長い沿革が最初にあると、参加できるかを知るまで時間がかかります。
情報の正確さと順番の両方を設計します。
すべてを最初の画面へ詰め込む必要はありません。
概要で対象と内容を示し、読み進めると詳細と条件を確認できるようにします。
大きい画像が入口を占める場合は、その画像が判断を助けるかを確かめます。
雰囲気だけの画像で主要情報が見えなくなるなら縮小を検討します。
短い見出しや一覧を使うと、探す情報へ移りやすくなります。
ただし説明をすべて折りたたみへ隠すと、必要な条件を見落とす場合があります。
購入を左右する費用や制限は、開く操作をしなければ分からない場所だけに置かないでください。
初めて来た人と再訪した人で必要な情報が違う場合は、詳細へ進む道と申込先へ進む道を整理します。
どちらも同じ強さの派手なボタンにする必要はありません。
文章内の案内やページ内リンクを使い、主目的を保ちながら移動を助けます。
主要操作と補助操作を区別する
主要操作は、現在の画面で最も進めたい動作です。
補助操作は、その判断を支える動作です。
申込ボタンを強くし、問い合わせや戻る操作を識別できる形で添えます。
ただし補助操作を見つからないほど薄くして、利用者の選択を妨げないようにします。
ラベルは「次へ」だけより、次に何をするか分かる言葉が役立ちます。
「入力内容を確認する」「申込みを送信する」なら、確認と確定を区別できます。
クリック後に起きることが想像と違う表示は避けてください。
最終送信の前に条件を読める位置を確保します。
画面下へ固定するボタンは便利な場合もありますが、本文や入力欄を隠す可能性があります。
小さい画面、画面内キーボード、文字拡大で重なりを確認します。
いつでも押せることを優先して、判断に必要な説明を読めなくしてはいけません。
操作の状態も設計します。
処理中、入力エラー、送信完了が区別できれば、利用者は次に何をするか判断できます。
処理中に何度も送信しそうな画面なら、押した結果が伝わっていない可能性があります。
色だけでなく、具体的な状態の文章を添えます。
小さい画面の順番を先に試す
横並びの情報を縦にしたとき、読む順番が意味を保つか確認します。
パソコンで左に説明、右に申込み条件がある場合、スマートフォンではどちらが先かを決める必要があります。
見た目の並びだけでなく、読み上げやキーボード操作の順番も不自然にならないようにします。
幅375pxなど一つの値は試験条件の例です。
一台で見えればすべてに対応したとは言えません。
狭い幅、横向き、文字拡大で、重要な情報が欠けないかを確かめます。
長い講座名やエラーメッセージを入れ、短い仮文章だけで成立する配置にしないでください。
表や図は横方向が必要な場合もありますが、本文まで横スクロールが必要になる状態は見直します。
W3Cのリフローの解説は、拡大した状態で情報を失わずに読める設計を考える手がかりになります。
例外のある基準なので、表も必ず一列へ崩すという意味ではありません。
タップできる見た目だけでは十分ではありません。
キーボードで移動できるか、現在の位置が見えるか、ボタンの名称が意味を持つかも確認します。
細かな実装は開発担当と分担できますが、設計側も操作の順番と役割を言葉で渡してください。
利用者の課題で優先度を評価する
評価では、対象に近い人へ「この講座へ参加できるか確認し、申込み直前まで進んでください」と依頼します。
どの情報を探し、どこで戻り、何を尋ねたかを観察します。
自分が意図した順番を先に説明すると、迷いを見つけにくくなります。
架空のテストで日程を探して往復する人がいたなら、日程を概要へ追加する候補になります。
申込みをためらう理由が日程の不一致なら、配置とは別の問題です。
見つけられないこと、理解できないこと、条件が合わないことを分けて記録してください。
修正の優先順位は、操作できない問題、誤解する問題、探しにくい問題の順を目安にします。
装飾の好みを先に直すより、目的を完了できない箇所を解消します。
変更後は同じ課題で試し、問題が別の場所へ移っていないか確認します。
完成時には、画面目的、主要操作、補助操作、情報順、状態の一覧を残します。
新しいバナーや案内を追加する際、この一覧へ照らせば優先順位が崩れにくくなります。
一度の美しい画面より、更新しても利用者の行動を助けられる設計を目指します。
問い合わせが増えた場合は、利用者が何を見て質問したかを調べます。
答えを掲載済みという理由だけで、読者の問題と決めないでください。
見出し、位置、言葉が探す行動に合っているかを確かめ、必要なら近くへ短く再掲します。
更新時は説明の一致も確認します。
実践課題
実践課題：画面の配置図を作る
一つのWeb画面を、文字と箱だけの配置図にします。
実際の見出し、条件、ボタン名を用意し、パソコンとスマートフォンの読み順を並べてください。
操作前、処理中、完了の状態も短く書き、画面の目的が変わる点を確認します。
- 画面の主目的を一文にする
- 主要操作と補助操作を分類する
- 判断材料を読む順に配置する
- 小さい画面と拡大表示で確認する
架空の完成例「目的＝講座の条件を確認して申込む。順番＝対象と内容→日時と費用→参加方法→申込ボタン。補助＝問い合わせ。ボタン名＝申込フォームへ進む。入力後は確認画面を経て送信し、受付結果を表示する。」
自己確認
- 主要操作の意味と遷移先が一致する
- 必要な条件を操作前に確認できる
- 小さい画面でも内容が隠れない
まとめ
画面の優先度は、利用者の現在地と主目的から決めます。
判断材料を先へ置き、主要操作と補助操作を区別します。
小さい画面と拡大時の順番まで確かめ、更新しても役割が崩れない記録を残してください。
- 主要な操作の表示を移動先の内容とそろえます。
- 判断に必要な条件を操作前に示します。
- 小さい画面で情報や操作が隠れないか確認します。
