ヒューリスティック評価の進め方｜指摘・深刻度・改善の実例

ヒューリスティック評価は、ユーザビリティの原則に照らしてインターフェースを点検する手法です。評価者が1つのタスクをたどり、使いにくさにつながる具体的な設計上の問題と、優先して直すべき点を整理します。成果物は製品全体の点数ではなく、根拠と改善案を伴う、優先順位の付いた指摘です。

設計段階では、画面を編集し、対象の箇所にフィードバックを残せるUXデザインツールを使うと、問題のある状態と修正案を一緒に検討できます。画面から実際に確認できることと、利用者の反応についての予測は分けて扱います。

この手法でわかることを整理する

ヒューリスティック評価では、評価者が設計を点検します。ユーザビリティテストでは、参加者がタスクを行う様子をリサーチャーが観察します。前者では、フォームが入力内容を消してしまう設計を発見できます。後者では、利用者がその動作にどう気付き、どう復帰するかを観察できます。両者は補い合いますが、得られる証拠は同じではありません。

Nielsen Norman Groupの評価手順（英語）は、各自で独立して点検した後に指摘を統合する方法を勧めています。また、点検がユーザー調査の代わりになるわけではないことも示しています。製品をよく知る評価者でも、初めて使う人の問題を見落としたり、影響を読み違えたりすることがあります。

ここでは、共同作業サービスのアカウント登録を例にします。新規利用者が氏名、仕事用メールアドレス、パスワードを入力し、規約に同意して送信します。現在の設計には明確な送信中表示がなく、送信に失敗すると入力欄が空になります。以下は説明用に設定した条件であり、実際の顧客調査から得た結果ではありません。

タスクと点検するバージョンを決める

画面を見る前に、「利用条件を満たす仕事用メールアドレスでアカウントを作り、メール確認の段階まで進む」のようにタスクを1つ書きます。開始位置、端末、アカウントの条件も指定します。モバイルを使う新規利用者と、デスクトップを使う既存の管理者では、直面する問題が異なる場合があります。

点検するデザインや実装のバージョンを特定し、対象の画面を保存して、動作する経路を記録します。静止画からは、曖昧なラベルや情報の不足を指摘できますが、実際のキーボードフォーカスやサーバー動作までは確認できません。未実装の経路は、操作したことにせず、設計上の未定義箇所として記録します。

評価者には、同じタスクと制約を伝えます。この例では、仕事用メールアドレスが必要で、規約への同意後に確認メールが送られます。必要な製品ルールを共有しておくと、本来必要な手順を削除するような提案を避け、実現できる修正を検討しやすくなります。

原則を、タスクに沿った問いに置き換える

Nielsenの10原則（英語）は、フィードバック、なじみのある言葉、操作の自由、一貫性、エラー防止、記憶への依存を減らすこと、効率、情報の整理、復帰、ヘルプなどを扱います。広い原則なので、どの画面がなぜ使いにくいのかは、評価者が具体的に説明する必要があります。

まず登録全体を1度たどって経路を把握します。その後、判断が必要な箇所や、応答を確認する箇所に戻り、次のような問いで点検します。

• 「アカウントを作成」を押した後、処理が進行中かどうかわかるか。
• 「仕事用メール」という表示から利用条件がわかるか。それとも送信後に初めて制限に気付くか。
• 送信に失敗したとき、氏名とメールアドレスを残したまま、修正や再試行ができるか。
• メール確認画面に送信先のアドレスが表示され、入力ミスを直す方法があるか。

同じフォームでも、これらは別の問題につながります。他のアプリと違うという理由だけで問題にせず、その違いがタスクにどのような負担を生むかを説明します。よくあるパターンが今回の制約に合わない場合も、珍しいパターンに合理的な理由がある場合もあります。

別の人が再現できる指摘を書く

「登録がわかりにくい」だけでは、デザイナーが修正できません。きっかけとなる操作、表示された結果、予想される影響、関係する原則を記録します。同じ問題を解く方法は複数あるため、修正案は観察した状態と区別します。

指摘S-02：送信失敗後に入力済みの情報が消える。 エラー状態の設計では、「再試行」を押すと空の登録フォームに戻ります。利用者は氏名と仕事用メールアドレスを再入力する必要があり、復帰時に避けられるはずの手間が発生します。機密性の低い入力情報を残し、アカウントが作成されたかどうかを説明してから、再試行を案内します。

確認できる事実は、設計上、エラーから戻るとフォームが空になることです。予想される影響は再入力の手間であり、本番で発生する頻度は不明です。根拠がなければ「大半の利用者が登録をやめる」とは書けません。また、パスワードまで必ず保持すべきとは限りません。機密性の高い入力内容とセキュリティ要件は別途検討します。

対象の画面や状態を添付し、バージョンを明記します。別の評価者が問題を見つけられない場合は、深刻度を議論する前に経路を確認します。通常の画面だけを示すスクリーンショットでは、送信に失敗した後の状態を説明できません。

深刻度には理由を添える

Nielsenの深刻度評価の考え方（英語）では、頻度、影響、繰り返し起きるかどうかを考慮します。関係の薄い画面の評価を平均して割合にするより、それぞれの要素を明示します。実際の頻度が不明なら、「送信に失敗するたびに起きる」など、問題が現れる条件を書きます。

短い尺度を決め、一貫して使います。実務向けに整理するなら、0はユーザビリティ上の問題ではない、1は見た目の問題、2は復帰できる中断、3はタスクを著しく難しくする問題、4はタスクを完了できない、または容認できない結果につながる問題、とできます。数値は議論の整理に使い、その根拠を必ず添えます。

この評価は例の条件に基づきます。別の製品にそのまま当てはめず、利用できる復帰経路を確認してください。軽微な見た目の問題はすぐ直せるかもしれませんが、それによって主要タスクの行き詰まりを後回しにしないようにします。修正工数と利用者への影響は分けて記録します。

独立した評価を、証拠を残して統合する

各評価者が点検を終えるまでは、他の人のメモを見ないようにします。統合時には、同じ状態と影響を説明している指摘をまとめます。「フォームのデータが消える」と「再試行でメールが消える」は同じ問題かもしれません。一方、送信中表示の不足と利用条件の説明不足は、同じ画面にあっても別の問題です。

意味のある違いは残します。通常の経路を見た人と、エラー時の経路を見た人では、評価が変わることがあります。深刻度が食い違う場合は、まず条件を比較します。復帰できないと思って高く評価したが実際には経路があった場合も、正常時だけを見て低く評価した場合も、評価を見直します。

採用した指摘ごとに、次の判断を担当する人を決めます。次の作業は、設計変更、技術調査、ユーザー調査などです。採用しなかった指摘にも短い理由を残せば、同じ好みの違いが繰り返し不具合として持ち出されることを防げます。

修正内容と、まだ不明な点を確認する

S-02では、氏名とメールアドレスを残した送信失敗画面を作り、何が起きたのかを説明して再試行の操作を用意します。その後、同じ経路をもう一度たどります。「アカウントは作成済み」と表示しながら、同じアカウントの新規作成を促すなど、修正によって矛盾が生まれていないかも確認します。

Pixsoでは元の画面と修正案を編集可能な状態で残し、意図する経路をプロトタイプでつなぎ、対象の位置にコメントを置けます。これらを使って動作を合意します。プロトタイプが示すのは提案する操作であり、実際の送信処理、データの扱い、復帰動作の検証には、動く実装が必要です。

設計上の問題を修正したら、重要な予測を誘導しないタスクを使ったユーザビリティテストで確認します。この例なら、登録に失敗した後の復帰を参加者に依頼し、押すべきボタンは教えません。修正画面がわかりやすく見えるかを質問するだけでなく、説明と次の操作が伝わるかを観察します。

合意した修正を裏付ける証拠が得られたら、その指摘を完了にします。コメントを解決済みにしたことは議論の記録であって、実装が正しく動く証明ではありません。評価を終えたチームに必要なのは、理由を説明できる改善事項、その根拠、そして利用者や実装を通じて確かめるべき問いです。