学習目標
画面をきれいにすることと、利用者が目的を達成できることを分けて考える。「誰が、どの状況で、何を完了するか」を先に定め、評価できる要求にする。
似た用語の比較
| 用語 | 主に見るもの | 予約画面の例 |
|---|---|---|
| UI | 人とシステムの操作・情報提示の接点 | 日付選択、入力欄、エラー表示 |
| UX | 利用前後も含む経験や受け止め方 | 探しやすさ、予約への安心感、変更時の負担 |
| ユーザビリティ | 特定の利用状況における目的達成のしやすさ | 正しく予約できた割合、所要時間、満足 |
| アクセシビリティ | 障害などによる利用の障壁を取り除くこと | キーボード操作、読み上げ可能なラベル |
ユーザビリティは利用状況に依存する。熟練者が速く操作できても、初回利用者が迷う場合がある。アクセシビリティとユーザビリティは重なるが同義ではない。ISO 9241-11:2018の概要、W3Cのアクセシビリティ入門
人間中心設計の循環
利用状況を調べ、利用者の要求を定め、設計案を作り、要求を満たすか評価する。評価で問題が見つかれば戻る。この図は活動の関係を学ぶための独自概念図であり、規格の図の転載ではない。ISO 9241-210:2019
要求を測れる形にする
| 曖昧な要望 | 具体化した独自例 | 評価の注意 |
|---|---|---|
| 分かりやすく | 初回利用者が説明を受けずに予約を完了できる | 利用者属性と課題をそろえる |
| 速く操作できる | 代表的な予約課題の中央値と失敗数を記録する | 成功者だけの時間で評価しない |
| 読みやすく | 文字を拡大しても内容と操作が失われない | 見た目の点検だけでなく実操作 |
| エラーを防ぐ | 入力エラーの項目と修正方法を文字で示す | 赤色だけに情報を依存させない |
判断例
入力ミスの欄を赤枠にするだけでは、色の違いを識別しにくい利用者や読み上げ利用者に理由が伝わらない。「日付は開始日以降を指定してください」という文字、対応する入力欄のラベル、修正できるフォーカス順をそろえる。一般的な文字のコントラストはWCAG 2.2のレベルAAで原則4.5:1以上、大きな文字は3:1以上だが、例外と文字サイズ条件を含めて確認する。WCAG 2.2 達成基準1.4.3
間違えやすい点
- ペルソナは調査結果を整理する道具。作成者の思い込みを利用者の事実に置き換えない。
- ユーザビリティテストは利用者の能力試験ではなく、設計の問題を見つけるために行う。
- 満足度だけでは完了率や操作ミスは分からない。成功・効率・主観評価を組み合わせる。
- アクセシビリティは完成後だけの検査ではない。要件、設計、実装、評価を通じて扱う。
確認問題
- 「すべての利用者に使いやすい」だけで評価条件は十分か？ → 不十分。対象利用者、課題、環境、基準が必要。
- アイコンの色だけで状態を伝える設計の改善は？ → 文字や形など別の手掛かりも設け、支援技術にも状態を伝える。
試験範囲の改訂
UI分野は2024年秋以降のSA午前Ⅱ範囲に追加された。公開SA過去問では2025年春が追加後の対象回なので、古い年度に少ないことを学習不要の根拠にしない。IPA改訂通知