ナビゲーションのツリーテスト：到達先だけでなく経路を読む

ツリーテストは、テキストだけで示したナビゲーションの階層から、必要な情報を見つけられるかを調べる方法です。アイコン、ページレイアウト、メニューの動作が判断に影響する前に、カテゴリ名と情報の置き場所を検討したいときに役立ちます。最後に正しい項目を選べたことは、得られる証拠の一部にすぎません。何度か道を間違えた末に、目的の場所へ着いた可能性もあります。

従業員向けヘルプセンターに、従業員の慈善団体への寄付に会社も金額を上乗せする制度のページがあるとします。「人事」「福利厚生」「社内規程」のどこに置くべきでしょうか。ツリーテストなら、従業員がどこを探すかを確認できます。ただし、それだけですべての選択理由が分かるわけではなく、完成したヘルプセンターの使いやすさを証明することもできません。

範囲を決め、その中で必要な枝をそろえる

参加者は、展開できるテキストのカテゴリを見て、答えがありそうな場所を選びます。カードソーティングでは参加者自身がコンテンツをグループ分けするのに対し、ツリーテストでは、用意された階層の中から項目を探します。NN/gのツリーテスト解説（英語）では、Page Laubheimerが、社内イントラネットで慈善寄付に関するタスクを使い、人事系のカテゴリ名を検討した例を紹介しています。このタスクに価値があったのは、必ずしも利用頻度が高かったからではなく、分類の問題が表面化したからです。

以下は、説明のために作った小規模な従業員ヘルプセンターであり、そのプロジェクトで使われたツリーや調査結果ではありません。字下げ一段が一つの階層を表し、末端の項目が到達先です。設定から分析まで、同じラベルを使い続けます。

• 従業員ヘルプ
  • 人事
    • 福利厚生
      • 健康保険
      • 寄付金のマッチング制度
    • 休暇
      • 休暇残日数
      • 休暇を申請
  • 社内規程
    • 行動規範
      • 利益相反
    • 寄付・ボランティア
      • ボランティア休暇の規程
      • 対象となる団体
  • ツール・アクセス
    • アカウント
      • サインイン情報をリセット
    • デバイス
      • 機器を申請

実際の調査では、正解の経路だけでなく、選ばれる可能性がある関連する枝も必要です。「社内規程」を取り除けば、寄付のタスクは簡単になりますが、検討したかった曖昧さそのものを避けてしまいます。意図的に「福利厚生」だけをテストするなら、結論の範囲もそこから先に限られます。トップページから「福利厚生」を見つけられるかまでは分かりません。

Optimalのツリー作成ガイド（英語）でも、サイト全体のテストと特定セクションのテストを分けています。その範囲を明示的に選びましょう。この例では、参加者が階層をたどることを調べるため、検索はテスト対象に含めません。この制約は、公開するヘルプセンターから検索機能をなくすべきだという意味ではありません。

結果を集める前に、何を答えとして認めるかを決める

各ページで何を説明する予定かを、コンテンツの担当者に確認します。この例では、「寄付金のマッチング制度」が、会社も寄付するかどうかと制度の仕組みを説明します。「対象となる団体」は、ボランティア活動の対象となる団体の一覧であり、会社による寄付の上乗せには答えません。この違いがあるため、そこは一見もっともらしくても十分な答えがない到達先です。結果を見てから都合よく追加した、別の正解ではありません。

本当に答えとして認められる到達先は、すべて調査前に指定します。二つの経路が同じ有用な情報に通じるなら、どちらも正解になり得ます。その際は経路全体を記録します。末端のラベルが同じでも、親カテゴリが違えば、ナビゲーション上は異なる選択だからです。配下のどこかに答えがあるカテゴリを選ぶことが、そのまま答えのページを選ぶことと同じになるわけではありません。

テストの設定で、親ノードを最終回答として選べるかも確認します。実際にはカテゴリ自身に役立つページがあっても、末端の項目しか選べないシステムもあります。「福利厚生」のページ自体に答えがあるのに、必ず子項目を選ばせると、実際のサイトを正しく表せません。必要に応じてカテゴリページの内容を明示的にモデル化し、テストのためだけに追加した階層を記録するか、実際の構造を扱える手法を選びます。モデルで表せないという理由だけで、妥当な回答を失敗扱いにしてはいけません。

メニュー名ではなく、従業員が知りたいことを書く

「福利厚生の中から寄付金のマッチング制度を探してください」では、答えも経路も教えてしまいます。「寄付金のマッチング制度を探してください」だけでも、階層を理解せず、同じ単語を探して選べてしまいます。Optimalのタスク作成ガイド（英語）は、ツリーにある答えのラベルを繰り返さず、自然な状況を伝えることを勧めています。複雑な身の上話を付け加えずに、目的が分かる文にしましょう。

会社による寄付の上乗せを調べるタスクに加えて、同じヘルプセンターの別の場所を使うタスクも用意します。下表の到達先の列は調査設定用であり、参加者に見せる指示には含めません。

これらの到達先は、採点のしやすさではなく、コンテンツの定義に基づいています。一つのタスクが複数の異なる用件として自然に解釈できるなら、実施前に書き直します。たとえば「社会貢献活動について知りたい」では、金銭の寄付、時間を使うボランティア、承認された団体の確認などが考えられます。その文言で得た結果には、異なる意図が混ざってしまいます。

タスクと回答操作が伝わるかを試行する

本格的に参加者を集める前に、対象を代表する従業員に試してもらいます。正解の枝を説明せず、寄付のタスクをどのような意味に理解したかを聞きます。最終回答の選び方、戻り方、見つからないときの終了方法も理解できているか確認しましょう。試行によって、分かりにくいのはメニューではなく指示文だったと分かることがあります。

人事コンテンツの整理方法をすでに知っている管理部門の担当者と、ときどき参照する従業員は、分析上区別できるようにします。全員を同じ条件の参加者として扱うのではなく、関連する利用経験を記録します。タスクは明示した範囲に分散させ、必要に応じて提示順を変えます。ほぼ同じタスクを繰り返し、寄付金のマッチング制度への経路を覚えさせてしまわないようにします。

最初の選択、引き返し、到達先を分けて読む

説明用の例として、「社内規程」から入り、「寄付・ボランティア」を開いたあと、「従業員ヘルプ」まで戻る試行を考えます。その後、「人事」「福利厚生」と進み、「寄付金のマッチング制度」を選びます。これは解釈を説明するために作った経路であり、観察で得た調査結果ではありません。到達先は正解ですが、経路は寄り道を含みます。

最初の選択の結果（英語）は、最初にどの枝へ進んだかを捉える助けになります。最初に「人事」を選んだことと、最終的に「人事」を訪れたことは分けて考えます。後者には、間違った枝から戻ってきた場合も含まれます。「福利厚生」を開いてからのつまずきが大半なら、最上位カテゴリの名前を変えても、問題がある階層には届かないかもしれません。

経路の結果（英語）では、寄り道のない経路と寄り道のある経路を、成否とは別に見ます。誤った到達先にまっすぐ進む人もいれば、引き返しても見つけられない人もいます。したがって、寄り道がないことは成功と同じではありません。両方の失敗を一つの赤い印にまとめず、選択の全順序を残します。

Optimalが説明する到達先のビュー（英語）では、設定した正解に対して、参加者がどこを最終回答にしたかを確認できます。このヘルプセンターなら、誤った選択が「対象となる団体」に集中しているのか、無関係なページに散らばっているのかを見ます。この二つでは、追加で尋ねるべきことが異なります。途中で断念した試行は、別に残しましょう。最終回答がないことは、どこかを選んだこととは違います。

割合を報告する場合は、タスク、ツリーの版、参加者の属性、分母を併記します。途中で断念した試行や除外した試行をどう扱ったかも説明します。成功率を上げるために、確認済みの正解と未検証の近道を同じ扱いにしてはいけません。一つのタスクの結果は、ヘルプセンター全体の点数ではありません。

寄り道を、原因の断定ではなく次の問いにつなげる

この説明用の経路からは、従業員が福利厚生とボランティアに関する規程をどう区別しているかを調べる価値がありそうだと考えられます。しかし、「人事」というラベルが悪いとまでは言えません。会社の決まりはすべて「社内規程」にあると思ったのかもしれませんし、会社が何を拠出するのかを誤解したり、単に探索したりしたのかもしれません。モデレーターが追加で聞くなら、「人事という名前は分かりにくかったですか？」ではなく、「そこには何があると思いましたか？」と尋ねます。

寄付のタスクとボランティアのタスクを比べます。どちらも「社内規程」から始まるなら、ラベルによって二つの異なる用件が同じものとして捉えられている可能性があります。両者を区別できているのに「対象となる団体」で止まるなら、下位のラベルと実際の内容を調べます。適切な変更は、カテゴリ名かもしれませんし、情報の置き場所や、役立つ第二の経路かもしれません。必ずしもメニューを短くすることではありません。

小規模な定性調査からは、再検討すべき問題を見つけられますが、母集団全体でどれほど起きるかは分かりません。数件の寄り道を全体の失敗率に置き換えたり、案どうしの小さな差を決定的だと主張したりしないようにします。所要時間にも文脈があります。時間をかけて成功した人は、丁寧に読んでいたのかもしれません。一方、すぐに間違った答えを選んだ人は、強い思い込みに従っていた可能性があります。

Pixsoで、変更点を一つに絞った案を比べる

次に検証する仮説を具体的にします。たとえば、すべての子項目と競合する枝をそのままにして、「人事」だけを「人事・福利厚生」に変える案が考えられます。これなら問いは、「全面的に作り直したメニューのほうがよいか」ではなく、「範囲が伝わる名前にすると寄付のページがあると気づきやすくなるか」です。同時に「寄付金のマッチング制度」の位置まで変えると、結果が文言によるものかを判断しにくくなります。

Pixsoでテキスト、図形、線を使い、元の階層と変更案を横に並べて描きます。その上に参加者向けのタスクを置き、説明用の経路は元のツリーだけに添えます。経路には説明用の例だと分かるラベルを付けましょう。実際の調査なら、個人を特定できない試行IDなどを使い、元の調査記録を参照できるようにします。一つだけ変えたラベルを強調し、それ以外のツリーの内容はそろえます。PixsoのUIデザイン・注記ツールは、このようなデザインレビュー用の資料作成に使えます。テストのデータは調査から得るものであり、Pixso内蔵のツリーテスト分析機能で集めるわけではありません。

Pixsoでナビゲーションのツリーを描き、改善案を検討する →

同じタスクと正解のルールで、変更案をテストします。初めて触れたときの反応を比較するなら、全員が一つ目で到達先を覚えてから二つ目を繰り返すのではなく、条件が比較可能な別の参加者グループを使います。ほかの調査条件はそろえます。ボランティアと機器のタスクも確認し、一つの経路を改善するための変更によって、別の場所の問題が見えなくならないようにします。

改めた階層を、実際の画面に戻して確かめる

方向性を決めたら、実際のナビゲーションレイアウトにラベルを置き、従業員のタスクをもう一度テストします。メガメニューなら複数の階層を同時に見せられますが、狭い画面のメニューでは一階層ずつ開くかもしれません。検索、ページの内容、操作時の動作によって体験は変わります。ツリーテストの結果だけでは、それらの問題は解決しません。

完成した画面を使い、寄付の情報をもとに行動できるかが問いになったら、構造化したユーザビリティテストの進め方（英語）を活用します。ツリーテストについては、どの階層を調べたか、参加者がどこへ進んだか、何を変えたか、何をまだ確認する必要があるかという範囲に結論をとどめます。得たいのは、経路から切り離された緑色の成功率ではなく、根拠を説明できるナビゲーションの判断です。