ワークショップでは、参加者全員がコンテンツの本来の場所をすでに知っているため、提案されたナビゲーションが説得力があるように見えがちです。しかしユーザーは、請求書を見つける、配送先住所を変更する、特定のサービスが自分の地域に対応しているか確認するといった、具体的なタスクを持って訪れます。ツリーテストは、カテゴリーのラベルや階層構造が、そうした目的地へのスムーズなルートを提供できているかを検証する手法です。

参加者は完成したUIのレイアウトやビジュアルデザインを排した、テキスト版のナビゲーションを使ってリアルなタスクに挑みます。そのため、リニューアルにリソースを投じる前に構造を検証したい場合や、既存の階層が見つけやすさの課題につながっていないか確かめたい場合に役立ちます。

テストでわかること

たとえば、あるオンラインショップが配送情報を「カスタマーサービス」配下に置いているのに対し、一部のユーザーはまず「注文履歴」を探すとします。ツリーテストを行えば、そうした辿ったルートや、最終的にどこで操作を終えたのかが可視化されます。フォローアップの質問を組み合わせることでその選択理由を掘り下げることもできますが、辿った経路だけで、ラベル自体の問題なのか、タスクの誤解なのか、それとも別の要因なのかを断定することはできません。

これは、コンテンツのグループ化を依頼して構成案のヒントを得るカードソートとは異なります。ツリーテストは、すでに用意された構成を評価することから始まります。これら2つの手法を組み合わせて使うこともできますが、カードソートが必須というわけではありません。リニューアルの最初のステップとしては、現在のナビゲーションをテストしてみるのが最も有効な場合もあります。

Nielsen Norman Groupのツリーテストガイドでは、この手法の概要やカードソートとの違いが解説されています。不要な要素を削ぎ落とした形式は階層構造の検証に適していますが、Webサイト全体について推測できることには限りがあります。

ツリーとタスクの準備

検討中のナビゲーションについて、目的地の有力な選択肢となり得るものも含め、適切な広さと深さを盛り込みます。正解のブランチしか含まれていないテストでは、実際のタスクを難しくしているはずの選択肢が排除され、構造が過大評価されてしまいかねません。特に、同じ情報が複数の場所に存在してもおかしくない場合は、正解とみなす目的地をあらかじめ定義しておきます。

タスクのシナリオは、カテゴリーのラベル名をそのまま答えとして漏らさないよう、ユーザーが必要としている情報にフォーカスして作成します。先ほどのショップの例なら、「土曜日に配送可能か」を尋ねることで配送情報を探す動機が生まれますが、「配送オプション」を開くように指示してしまうと、単に答えをなぞらせるだけになってしまいます。参加者がタスクの意図を理解し、テストツールを問題なく使えるか確認するために、ツリーと設問文の両方でパイロットテストを実施しましょう。

ナビゲーションの利用に影響を与えるような経験や役割の違いを考慮し、意思決定に関連するユーザー層をリクルーティングします。参加者の人数は、問題の洗い出しが目的なのか、それとも精度の高いパフォーマンス数値を算出したいのかによって設計します。少人数のテストでも分かりにくいルートを特定できますが、そこで得られたパーセンテージを母集団全体の正確な測定値として扱うべきではありません。

成功率・ルート・不確定要素を総合的に読み解く

全体の成功率だけに頼るのではなく、タスクごとに結果をレポートします。平均値が高いと、重要な目的地で起きている深刻な問題を見落とす恐れがあります。参加者がどこから探し始め、どこで引き返し、どこで完了としたのか、そしてサイトがターゲットとするグループ間でそうした傾向に違いがあるかを確認します。

寄り道せず進めたか（直接性）やかかった時間は重要な文脈を与えてくれますが、慎重な解釈が必要です。時間がかかったケースには、迷いや熟読、中断、テストツールの操作への戸惑いなどが含まれている可能性がありますし、迷わず目的地に到達できたからといって、確信や理解があったことの証明にはなりません。モデレーターがいるセッションなら、参加者の発言からその違いを見極められます。アンモデレート型の調査では、適切なフォローアップ設問を用意し、推測だけで意図を決めつけないようにします。

構造の改善とインターフェースでの検証

テストで得られた知見をもとに、より分かりやすいラベルへの変更、グルーピングの見直し、頻繁にアクセスされるコンテンツへの別ルートの設置など、具体的な改善案をまとめます。その提案を裏付ける根拠を記録し、大きな決定であれば改善後の構造でもテストを実施しましょう。同じ参加者を再起用すると学習効果が生じる可能性があるため、複数ラウンドの結果を比較する際は留意が必要です。

ツリーテストが成功しても、インターフェースに関する問いは残ります。検索、ページレイアウト、クロスリンク、コンテンツのプレビューなどは、ナビゲーションを辿るユーザーの助けにも妨げにもなり得ます。実際のデザインを使ったユーザビリティテストを行うことでそうした影響を検証し、実際のプロダクトとして組み込まれた際にもその構造が有効に機能するかどうかを見極めることができます。