ユーザビリティとは?利用文脈・評価方法・改善判断の手順

ユーザビリティは、ある利用者が、ある状況で、目的の作業をどれだけうまく進められるかを考える品質です。「誰でも使いやすい画面」と一括りにせず、対象者、タスク、環境を決めて評価します。定義を理解したら、観察する行動と成功条件を書き、結果を改善の判断へつなげます。
ユーザビリティは誰の何のタスクかで変わる
初回利用者には分からない略語でも、毎日使う担当者には効率的な場合があります。スマートフォンで片手操作する状況と、机上で複数資料を確認する状況でも、必要な情報や操作は変わります。使いやすさを評価する際は、利用者と文脈が前提になります。
Nielsenのユーザビリティ解説は、学習しやすさ、効率、記憶しやすさ、エラー、満足という観点を挙げています。どの観点を重視するかはタスク次第です。初回の設定では理解しやすさ、繰り返す集計では手際、重要な申請では正確さや回復可能性が問題になり得ます。
ISO 9241-11の公式概要も、ユーザビリティを利用の結果として扱います。規格の概要が特定のテスト人数や方法を定めているわけではありません。評価手順は、自社が確かめたい問いから組み立てます。
UX・UI・アクセシビリティとの関係
UIはボタン、表示、入力等の接点です。ユーザビリティは、その接点を通じて作業を達成できるかという評価の観点です。UXは利用前の期待や利用後の体験も含めた広い概念で、操作が快適でも提供価値が目的に合わなければ、体験全体の評価が高いとは限りません。
アクセシビリティは、障害のある人を含めて利用できることに関係します。W3Cの解説はユーザビリティとの重なりを示しています。別々のチェックだけで完結させず、必要な支援技術や実際の利用条件を含めて確認します。使いやすさが良好という観察だけで、アクセシビリティ適合を認定することはできません。
問いに合わせて評価方法を選ぶ
「どこで迷うか」と「どれくらいの割合で完了するか」は異なる問いです。前者を探索する観察と、後者を推定・比較する定量調査では、必要な参加者の集め方や件数が違います。手元にあるデータに合わせて問いを狭めることも必要です。
方法 | 主に確認する問い | 限界 |
|---|---|---|
ユーザーテスト | 実際の操作でどこに迷い・誤りがあるか | 少数の参加者から全体の発生率は決められない |
ヒューリスティック評価 | 設計原則から明らかな支障がないか | 実際の利用者特有の問題を見落とし得る |
利用ログ | どの工程で停止・離脱が見えるか | ログだけでは理由や意思を確定できない |
質問紙・面談 | 満足や期待、利用条件をどう捉えるか | 回答と実際の行動は一致するとは限らない |
ヒューリスティック評価には、状態の可視化やエラー予防等の原則を使えます。確認した問題を利用者の観察で確かめるなど、方法を補い合わせます。アクセスが少ないサービスに、十分な検出力のない比較実験を形式だけ導入する必要はありません。
参加者・タスク・成功条件を計画する
以下は架空の見積サービスで探索的な観察を行う計画です。参加者が解決したい状況を説明し、操作手順は教えずに試してもらいます。「このボタンを押してください」と誘導すると、ボタンを見つけられるかという問いが測れなくなります。
項目 | 架空の評価計画 |
|---|---|
対象者 | 初めて見積を依頼する業務担当者 |
環境 | 普段使う端末と入力手段。通信条件も記録 |
タスク | 人数条件の違う二つの見積を比較し、一つを保存 |
成功条件 | 指定条件が正しく、保存先と保存結果を確認できる |
支援ルール | 本人が求めた支援は記録し、無支援完了と分ける |
観察 | 迷い、誤操作、回復、未完了理由、所要時間 |
記録の扱い | 必要な観察だけを残し、録画等の説明・許可を先に確認 |
架空の5人で、無支援完了3人、支援あり完了1人、未完了1人なら、無支援完了は3/5=60%です。これはこの観察の記述であり、市場全体の完了率推定や統計的な優劣の判断には使いません。5人なら十分という一般ルールにもなりません。対象者群や目的が違えば計画を変えます。
時間は完了者だけを集めた値なのか、支援ありを含めたのかを示します。未完了者を除いて速さだけを比較すると、難しい状況の人が見えなくなります。操作後には、迷った理由を本人に確認し、観察した事実と説明の仮説を分けます。
影響・頻度・確かさと工数を分けて優先する
課題を並べるときは、影響の大きさ、見えた件数、根拠の確かさ、修正の負担を別々に記録します。修正コストを正方向で掛けるだけの式では、高い工数ほど優先されるなど、判断の意図が曖昧になります。目的に沿った順序を話し合います。
架空の課題 | 影響と根拠 | 対応判断 |
|---|---|---|
条件が変わったことに気づけない | 誤った見積を保存。観察と再現で確認 | 正確さに関わるため先に修正案を試す |
補足説明を見つけにくい | 一部が迷ったが別経路で完了 | 配置変更を小さく試し再観察 |
配色の好みが分かれる | 意見のみでタスクの支障は未確認 | 操作への影響を確認してから判断 |
少数の観察で見えなかった問題を、存在しないと断定しません。異なる利用者や支援技術を使う状況に重大な支障がないかも考えます。逆に、個人の好みだけで全面改修へ進めず、何を改善したいかを具体化します。
再観察と事業成果を分けて確認する
変更後は同じ成功条件で再びタスクを試し、元の支障が解消したか、新しい誤りがないかを確認します。同じ人が操作を覚えた影響、対象者や端末の違いも記録します。画面の改善と同時に料金や募集経路が変わったなら、成果の変化を画面だけの効果とは言えません。
完了しやすくなったという観察は重要ですが、売上、継続、問い合わせ負担はそれぞれ別に測ります。改善の判断記録には、変更点、根拠、残った疑問、次の確認を残します。利用者のタスクに戻って評価を続けることが、使いやすさを磨く実務になります。
次の検討には、タスク別のUI改善例、顧客導入工程の設計、アプリの識別子と観測データの扱いも役立ちます。