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

ユーザビリティは誰の何のタスクかで変わる

初回利用者には分からない略語でも、毎日使う担当者には効率的な場合があります。スマートフォンで片手操作する状況と、机上で複数資料を確認する状況でも、必要な情報や操作は変わります。使いやすさを評価する際は、利用者と文脈が前提になります。

Nielsenのユーザビリティ解説は、学習しやすさ、効率、記憶しやすさ、エラー、満足という観点を挙げています。どの観点を重視するかはタスク次第です。初回の設定では理解しやすさ、繰り返す集計では手際、重要な申請では正確さや回復可能性が問題になり得ます。

ISO 9241-11の公式概要も、ユーザビリティを利用の結果として扱います。規格の概要が特定のテスト人数や方法を定めているわけではありません。評価手順は、自社が確かめたい問いから組み立てます。

UX・UI・アクセシビリティとの関係

UIはボタン、表示、入力等の接点です。ユーザビリティは、その接点を通じて作業を達成できるかという評価の観点です。UXは利用前の期待や利用後の体験も含めた広い概念で、操作が快適でも提供価値が目的に合わなければ、体験全体の評価が高いとは限りません。

アクセシビリティは、障害のある人を含めて利用できることに関係します。W3Cの解説はユーザビリティとの重なりを示しています。別々のチェックだけで完結させず、必要な支援技術や実際の利用条件を含めて確認します。使いやすさが良好という観察だけで、アクセシビリティ適合を認定することはできません。

問いに合わせて評価方法を選ぶ

「どこで迷うか」と「どれくらいの割合で完了するか」は異なる問いです。前者を探索する観察と、後者を推定・比較する定量調査では、必要な参加者の集め方や件数が違います。手元にあるデータに合わせて問いを狭めることも必要です。

ヒューリスティック評価には、状態の可視化やエラー予防等の原則を使えます。確認した問題を利用者の観察で確かめるなど、方法を補い合わせます。アクセスが少ないサービスに、十分な検出力のない比較実験を形式だけ導入する必要はありません。

参加者・タスク・成功条件を計画する

以下は架空の見積サービスで探索的な観察を行う計画です。参加者が解決したい状況を説明し、操作手順は教えずに試してもらいます。「このボタンを押してください」と誘導すると、ボタンを見つけられるかという問いが測れなくなります。

架空の5人で、無支援完了3人、支援あり完了1人、未完了1人なら、無支援完了は3/5＝60%です。これはこの観察の記述であり、市場全体の完了率推定や統計的な優劣の判断には使いません。5人なら十分という一般ルールにもなりません。対象者群や目的が違えば計画を変えます。

時間は完了者だけを集めた値なのか、支援ありを含めたのかを示します。未完了者を除いて速さだけを比較すると、難しい状況の人が見えなくなります。操作後には、迷った理由を本人に確認し、観察した事実と説明の仮説を分けます。

影響・頻度・確かさと工数を分けて優先する

課題を並べるときは、影響の大きさ、見えた件数、根拠の確かさ、修正の負担を別々に記録します。修正コストを正方向で掛けるだけの式では、高い工数ほど優先されるなど、判断の意図が曖昧になります。目的に沿った順序を話し合います。

少数の観察で見えなかった問題を、存在しないと断定しません。異なる利用者や支援技術を使う状況に重大な支障がないかも考えます。逆に、個人の好みだけで全面改修へ進めず、何を改善したいかを具体化します。

再観察と事業成果を分けて確認する

変更後は同じ成功条件で再びタスクを試し、元の支障が解消したか、新しい誤りがないかを確認します。同じ人が操作を覚えた影響、対象者や端末の違いも記録します。画面の改善と同時に料金や募集経路が変わったなら、成果の変化を画面だけの効果とは言えません。

完了しやすくなったという観察は重要ですが、売上、継続、問い合わせ負担はそれぞれ別に測ります。改善の判断記録には、変更点、根拠、残った疑問、次の確認を残します。利用者のタスクに戻って評価を続けることが、使いやすさを磨く実務になります。

次の検討には、タスク別のUI改善例、顧客導入工程の設計、アプリの識別子と観測データの扱いも役立ちます。