ニールセンの10ヒューリスティクスで行う簡易UX監査：タスク単位で見る手順と監査シート

仮の例から始めます。衣料品を扱う小規模ECサイトで、「サイズ交換の申請ができない」という問い合わせが毎週届くとします。申請ページを一枚ずつ眺めても、デザインが崩れているわけではなく、文言も間違っていません。それでも詰まる人がいるのは、問題が個々の画面ではなく「注文履歴を探す → 交換できる商品を選ぶ → 理由を書く → 受付メールを受け取る」という一連の流れのどこかにあるからです。簡易UX監査は、この流れを10の原則で順に見ていく作業です。専門のリサーチャーや大規模な調査予算がなくても、半日から一日で一通り回せます。

画面ではなく「タスク」を監査単位にする

ヒューリスティック評価は、評価者が既知の原則に照らしてインターフェースの問題を洗い出す方法です。Nielsen Norman Group（NN/g）は、これを専門家による検査型の手法として位置づけています。ここで最初にぶつかるのが「何を対象にするか」で、トップページ、商品ページ、カート、といったページ単位で割り振る監査をよく見かけます。ところが10原則のうち、「ヘルプとドキュメンテーション」「ユーザーが誤りを認識・診断・回復できるようにする」「ユーザーのコントロールと自由」の三つは、一枚のページを見ているだけでは発見しにくい原則です。エラーは入力を間違えた後にしか現れず、取り消しや戻る操作は、先へ進んでみて初めて試せるからです。

そこで、監査の単位をタスクシナリオにします。シナリオは次の形で一文にまとめます。

• 誰が：初めて購入した顧客、会員登録済みの顧客、など
• 何をしたくて：サイズ交換を申請したい、請求書の宛名を変更したい、など
• どの端末で：スマートフォン、PCなど（実際のアクセスの多い方を先に）
• どこから始めるか：購入完了メール、検索結果、広告のリンクなど

シナリオの材料は、想像ではなく実際の顧客の声から取ります。問い合わせ履歴で件数の多い用件、実際の顧客から作るカスタマージャーニーマップで摩擦が大きいと出た段階がそのまま候補になります。最初の監査では、シナリオを三つに絞ります。多くすると一つ一つの観察が浅くなり、シートの指摘が表面的な見た目の話に流れがちです。

評価者は、可能なら二人から三人にします。NN/gは、一人の評価者では見つかる問題が限られるため複数人での実施を勧めており、目安として3〜5人が挙げられています。小さなチームで五人を集めるのは現実的ではないので、担当者本人に加えて、サイトを使い込んでいない同僚をひとり入れるだけでも、見落としの種類が変わります。担当者本人は、どこを押せば進むかを知りすぎているため、迷う感覚が再現できないのです。

10原則を、画面に向ける問いに言い換える

原則の文章をそのまま読み上げても、評価者によって解釈が割れます。次の表は、10原則のそれぞれを「いま見ている画面で確かめる問い」に直したものです。原則名は、NN/gが公開している「10 Usability Heuristics for User Interface Design」に沿っています。問いの文面と日本語のEC・フォームでの例は、この記事の筆者側の言い換えであり、原典の記述ではありません。

日本語のフォームには、この表の外側にも頻出の落とし穴があります。たとえば全角・半角の数字の取り扱い、電話番号や郵便番号のハイフン有無、フリガナの必須化、住所の番地・建物名の分割です。これらは原則5（エラーの防止）に分類できますが、英語圏の事例を中心に書かれた解説では扱われにくい項目です。日本のサイトを監査するなら、シートの「入力」欄に独自の観点として追加しておく価値があります。フォームの項目設計については、Baymard Instituteがチェックアウトとフォームの使いやすさを継続的に調査しており、項目数、必須・任意の示し方、ラベルの位置などの論点が整理されています。数値は調査年と方法で異なるため、引用する際は原典を確認してください。

原則は一つの指摘に一つだけ割り当てる

慣れないうちは、一つの問題に複数の原則を当ててしまいがちです。たとえば「エラー文が不親切」は原則9にも原則2にも当たります。複数に割り当てると、原則別に数を集計したときに実態より問題が多く見え、改善の優先順位を議論するときに混乱します。主たる原則を一つ選び、副次的に関係する原則はメモ欄に書く、と決めておくと集計が安定します。

指摘の書き方と、重要度の付け方

監査シートの一行は、次の四つの欄で構成します。

評価語（「分かりにくい」「使いにくい」）を入れないのは、後で他の人が事実を確かめ直せるようにするためです。「理由の選択肢が10個ある」は誰が数えても同じですが、「選択肢が多すぎる」は評価者によって違います。事実の欄を数えられる形で書く習慣がつくと、重要度の議論が感想の言い合いになりにくくなります。

重要度は、発見とは別の作業として付ける

重要度の付け方としては、NN/gが紹介している考え方が参考になります。問題の頻度（どれくらいの人が遭遇するか）、影響の大きさ（遭遇した人が乗り越えられるか）、持続性（一度気づけば次から避けられるか、毎回困るか）の三つを合わせて判断し、0から4程度の段階で表すものです。段階の定義の細部は、原典で確認してください。

この記事で強調したいのは、評価者が指摘を見つけた直後に重要度を付けないことです。見つけた直後は、自分が発見した問題を重く見積もる傾向があります。指摘を全員分まとめ、重複を整理したあとに、評価者が個別に重要度を付け、その合議で決めると、評価者ごとのぶれが目に見えるようになります。ぶれの大きい項目は「判断材料が足りない」というサインなので、次節の観察やデータで確かめる候補に回します。

仮の例を挙げます。交換申請の手順3で理由の選択肢が10個並んでいる指摘について、三人の評価者が付けた重要度が1、3、4に割れたとします。割れた理由を話し合うと、「PCでは一覧が収まるが、スマートフォンでは画面外に出る」という前提の違いが原因だった、と分かることがあります。この場合、ぶれは評価者の誤りではなく、見ている端末の違いを教えてくれた情報です。

アクセシビリティを同じシートで見る

ヒューリスティック評価とアクセシビリティの確認は、別の作業として切り離されがちです。しかし、小さな画面でボタンが押しにくい、文字が薄くて読めない、キーボードだけでフォームを進められない、といった問題は、ほとんどの顧客にとっても摩擦です。WCAG 2.2は2023年10月にW3C勧告となっており、監査シートに載せる最低限の項目は、次のように絞れます。

• 本文のコントラスト比（成功基準1.4.3、通常サイズの文字で4.5:1）。ボタン上の文字と、フォームのプレースホルダーを必ず見る。
• 押す対象の大きさ（2.5.8、最小24×24 CSSピクセル）。リンクが近接して並ぶ、フッターや注記の領域が見落としやすい。
• フォーカス表示と、固定ヘッダーによる隠れ（2.4.11）。キーボードのTabキーで順に辿り、いま操作中の場所が見えるかを確かめる。
• 入力欄のラベルと入力目的の特定（3.3.2、1.3.5）。プレースホルダーだけがラベル代わりになっていないか。
• 同じ情報の再入力を求めない（3.3.7）。確認画面や配送先の入力で、すでに入力した内容を再度書かせていないか。

日本では、ウェブアクセシビリティの規格としてJIS X 8341-3が広く参照されます。2016年版はWCAG 2.0に対応した規格で、WCAG 2.2とは版が異なります。自社や取引先がどちらを基準にしているかは契約や社内規程で変わるため、確認してから基準を決めてください。この監査では、基準の版にかかわらず上の項目を「顧客の摩擦を減らす観点」として見る、という位置づけで十分です。

確認は、完全な適合試験ではありません。ブラウザのズーム、スマートフォンでの画面の向き、キーボード操作、スクリーンリーダー（OS標準のもので十分）を、各シナリオで一度ずつ試す程度に留めます。適合の判定が必要な場合は、専門の試験として別に計画してください。

監査でわかること、わからないこと

ここまでの手順で、監査後には、重要度付きの指摘一覧が手元に残ります。この時点で、シナリオごとに「最も重い指摘を三つ」を選び、直す案を一行ずつ添えます。直す案の欄は、デザイナーやエンジニアへ依頼する前に、費用感（半日で直る、数日かかる、仕様の相談が要る）を三段階で書いておくと、着手の順番を決めやすくなります。

ただし、ヒューリスティック評価は実際の顧客の観察の代わりにはなりません。評価者が「問題だ」と判断した点が顧客にとって問題でないことは珍しくありませんし、逆に評価者が気づかなかった困りごとは、リストに現れません。Steve Krugが『Don't Make Me Think』で繰り返し述べているのは、ごく少人数でも頻繁に実際の利用者を観察することの価値でした。監査は、その観察を始める前に明らかな問題を取り除き、観察の時間を、本当に判断が必要な論点へ振り向けるための準備と考えるのが現実的です。

一方で、指摘一覧をそのまま改善の根拠にして、効果を検証しないまま変更を重ねるのも避けたい進め方です。改善が顧客の行動に変化を与えたかは、計測と比較でしか分かりません。ある指摘が「重要度4」でも、その画面に到達する顧客が少なければ、全体への影響は限られます。到達数と離脱の位置はアクセス解析で確認できるので、指摘と数字を並べて読んでください。その後の検証のしかたは、CROの検証計画：勘からテスト計画へで扱っています。また、指摘を「約束・証拠・オファー・フォーム」の順に整理するなら、ランディングページの構成を扱った記事の視点が使えます。

最後に、この監査で出てくる指摘の多くは、新しい発見というより、以前から誰かが気づいていた問題の再確認です。再確認で終わらせず、シートに書いた時点で担当と期限を決めることが、監査を成果につなげる分かれ目になります。具体的な設計の進め方を実習で扱う内容は、カスタマーエクスペリエンス実践コースで用意しています。