【翻訳】ツリーテスト(1)メニューのラベルとカテゴリの高速な反復評価(Kathryn Whitenton, NN/g, 2017)

www.nngroup.com

これらのヒントに従って、サイトのナビゲーション階層を効果的に評価し、よくあるデザインのミスを回避しましょう。

重複する情報カテゴリと紛らわしいラベルは、Webサイトのデザインで最も蔓延している問題の2つです。幸いなことに、オーディエンスにとって意味のあるカテゴリとラベルを作成するために使用できる、迅速かつ効果的なテクニックが存在します。

最もよく知られたテクニックは、カードソーティングでしょう。これは、ユーザーに代表的なコンテンツアイテムのリストを渡し、適切なグループ分けとラベル付けをさせるものです。カードソーティングは、オーディエンスがどのように考えているかを理解する上で非常に有効ですが、必ずしもあなたが従うべき正確な分類スキームが得られるわけではありません。例を挙げると、カードソーティングの参加者は、他のどこにも当てはまらないようないくつかのアイテムを入れるために、過度に一般的なカテゴリーを作ることがよくあります。これは理解できますが、もしあなたがメニューに「その他のもの」カテゴリーを実際に入れたとしたら、同じユーザーはそれを徹底的に避けるでしょう。ウェブサイトの訪問者は、曖昧なラベルをクリックするのを嫌がるものです。なぜなら、コンテンツを選別するために多くの作業をしなければならないと、当然のことながら考えるからです。

hrism.hatenablog.com

そのため、カードソーティングに続いてツリーテストを行い、提案されたメニュー構造を評価するのが最も効果的でしょう。

定義;ツリーテストは、階層的なカテゴリー構造(ツリー)を評価するもので、ユーザーにツリーの中で特定のタスクを完了できる場所を探させるものである、

ツリーテストは、カードソーティングのフォローアップとして非常に有効です。

  • ユーザビリティテストに似たタスクを使って、実際のシナリオで階層がどのように機能するかを評価しましょう。
  • ページレイアウトやナビゲーションメニューを設計する前に実施できるため、メニューのカテゴリーやラベルを安価に検討・改良することができます。

ツリーテストを行うには、ワイヤーフレームを描いたり、コンテンツを書いたりする必要はありません。用意するのは、ツリー(階層型メニュー)と、タスク(調査参加者に何を探せばよいかを説明する指示)の2つだけです。

ツリーを定義する

ツリーは、すべてのメインコンテンツのカテゴリと、そのサブカテゴリの完全なリストである必要があります。ツリーの特定のセクションのみをテストしたい場合でも、他のセクションを除外することは、ユーザーがどのセクションに移動すべきかを知っていると仮定しているため、リスクがあります。例えば、あなたのWebサイトに「製品」と「サービス」の両方のカテゴリがあったとして、「製品」のツリーだけをテストすることにした場合、ユーザーはこの2つのカテゴリの違いを理解しているかどうかを調べることができません。

階層構造のどの部分に最も興味があるかによって、ツリーの深さは3、4、あるいは5レベルにする必要があります。テストしたいサブカテゴリの最下層までの深さを含めます。各サブカテゴリーは、ユーザーから現実的な行動を引き出すために、その領域内のすべてのオプションの完全なリストを提供する必要があります。ユーザーは、リンクラベルを近くの選択肢と比較することによって評価することがよくあります。たとえば、歴史に興味のあるユーザーは、「文化」というラベルの付いたカテゴリーを試してみたくなるかもしれませんが、「歴史リソース」というオプションもあれば、試そうとは思いにくいでしょう。

競争的ツリーテスト:ラベルとロケーションの比較

同じツリー・カテゴリに異なるラベルを付けることを検討している場合、2つの異なるツリーをテストして、用語がどのように機能するかを比較することができます。 このようなテストは、Userzoomのツリーテストツールで特に簡単に行うことができます。このツールでは、ライブウェブサイトでのA/Bテストと同じように、参加者を異なるバージョンのツリーにランダムに割り当てることができます。複数のツリーをテストする場合、同じセッションで同じユーザーに2つの代替ツリーを表示することは避けましょう。2番目のツリーとインタラクトするときのユーザーの行動は、最初のツリーでの経験によって歪められてしまうからです。

例えば、トマトを「果物」と「野菜」のどちらに配置するかなど、ラベルの異なる位置を比較するだけであれば、別のツリーを用意してテストする必要はありません。それぞれの場所について2つの異なるツリーをテストする代わりに、1つのツリーをテストして、何人のユーザーが「果物」をクリックしたのか、「野菜」をクリックしたのかを比較することができるのです。(両方クリックされた場合、どちらのカテゴリーを先にクリックしたかもわかります)。

テストの準備:ツールとフォーマット

ペーパープロトタイプ(またはクリックできるプロトタイピングツール)を使ってツリーテストを行うこともできますが、ツリーテスト用に特別に設計されたサービスを利用すると、結果の分析プロセスが大幅に短縮され、利用する価値が十分にあります。UserzoomTreejackは、ツリーテストを実施するための良いオプションです。

また、スプレッドシートで管理する方法もあります。ツリーをスプレッドシートで準備し、簡単に視覚化・編集できるようにし、階層全体をコピーしてツリーテストツールに貼り付けるだけです。スプレッドシートは、A列の一番上のセルにホームページを表示し、左から右の列で下位レベルをリストアップする形式にしてください。

階層をインポートする際にレベルが正しく解析されるように、各行には必ず1つのカテゴリのみをリストアップしてください。

メニューツリーを含むスプレッドシートスクリーンショット。このスプレッドシートは、New Mexico State Government Web サイトのツリー (メニュー階層) を示しています。各カテゴリは独立した行に表示され、サブカテゴリはそれらを含む親カテゴリの右側の列に配置されます。―Image by NNg

階層をテストツールに貼り付けると、カテゴリが解析され、各カテゴリを展開して対応するサブカテゴリを表示できるクリック可能なメニュー階層を自動的に作成するために使用されます。

OptimalWorkshopのテストツール「Treejack」で作成したツリーのスクリーンショット。上の写真のTreejackのようなツリーテストツールは、スプレッドシートの階層を自動的に解析して、カテゴリとサブカテゴリを持つクリック可能なメニューにします。―Image by NNg

ツリーテストの実行

ユーザーに完了させるタスクは、ツリーそのものと同じくらい重要です。まず、どのカテゴリとラベルをターゲットにするかを決定する必要があります。理想的には、以下のようなタスクが含まれます。

  • Webサイトの主要な目標とユーザーのタスク:「最も重要な製品を見つける」など。主要なナビゲーションタスクの成功率は、副次的なタスクを比較するための基準値となり、将来のテストの基準点となります。
  • 潜在的な問題領域ステークホルダーやカードソートの参加者から提案された新しいカテゴリーなど。

ラベルや場所の比較―同じカテゴリの代替ラベルや場所。また、各タスクについて、その情報がツリー内のどこに位置するのか、正解を定義しておく必要があります。この情報により、テストツールは各タスクの成功率を自動的に計算することができます。

Userzoomのツリーテストツールでタスクの正しい位置をマークする例。Userzoomのツリーテストシステムのこの画面は、特定のタスクに対してどのカテゴリが正解であるかを示すために使用されます。―Image by NNg

タスクのフレーズ化

各タスクは、ユーザーにそのカテゴリに含まれるものを見つけるよう求めることで、カテゴリラベルをテストする必要があります。ユーザビリティテストのタスクと同様に、ツリーテストのタスクの指示は、答えを明らかにするような用語を使用しないようにする必要がありますプライミング*1を防ぐには、シナリオと動機を説明することで達成できる場合があります。しかし、ユーザーは指示を注意深く読まない可能性があり、長いストーリーに埋もれてしまうと重要な詳細を簡単に見逃してしまうことを心に留めておいてください。

例として、New Mexico State Governmentツリー(上図)の「Starting a Business」カテゴリを評価するために考えられるフレーズをいくつか紹介します。

  1. 起業に関する情報を探す。
  2. 来年、サンタフェに引っ越してきて、芝生の手入れをする副業をして収入を補いたいと考えています。どのような規制があるか調べてください。
  3. あなたは、芝生の手入れサービスを開始することを検討しています。このサイトに、このプロセスを開始するのに役立つ資料があるかどうか確認してください。

最初の例では、起業というラベル用語が正確に使われているため、答えが分かってしまいます。一方、2つ目の例は長く、余計な単語が多いため、ユーザーが素早く流し読みした場合、タスクの要点と勘違いしてしまう可能性があります。3番目の例は、ラベル用語と誤解を招くような詳細の両方を回避しています。

ツリーテストの限界

ツリーテストは、多くの場合、遠隔地、非モデレート調査として実施されます。代表的なユーザーをリクルートした後、調査へのリンクを送るだけで、テストツールが自分のコンピューターを使ってタスクを完了させるプロセスを案内します。テストツールは、ユーザーがどのカテゴリーをクリックしたかを正確に追跡することにかけては、人間よりはるかに優れています。

しかし、この形式では、ユーザーの行動(タスク実行中のコメントなど)を完全に把握することはできませんし、パーソナライズされたフォローアップの質問をすることもできません。

この形式の影響を最小限に抑えるには、データの大部分を収集する前に、少なくとも数回のモデレートされたパイロットセッションを実施してください。このようなモデレートセッションでは、タスクの文言が理解しやすいかどうかを確認し、また定量データでは見つけにくいニュアンスも拾うことができます。例えば、最近実施したあるツリーテストでは、パイロットテストの段階で、多くのユーザーがセッションの前半で特定のカテゴリを避けていることに気づきました。この傾向は、タスクの順序をランダムにしたため、定量的な結果では顕著ではありませんでしたが、各セッションで、ユーザーが明白な選択肢を無視するタスクを次々と目にしたとき、それは非常に明白でした。このインサイトを得ただけでも、パイロットテストは有意義な一日となりました。

また、ツリーテスト後に簡単なアンケートを実施することで、フォローアップの質問ができないことを部分的に補うことができます。

分かりにくいと感じたラベルを思い出してもらうのではなく、ラベルのリストを提示して、どれが分かりにくいかチェックしてもらうのです。この質問には、さらにコメントやフィードバックを求める自由形式の質問を加えることで、クリック履歴からではわからない、思いがけない思い込みや誤解を引き出すことができます。

まとめ

ツリーテストは、カテゴリラベルの評価のみに焦点を当てたものです。これは大きな強みであると同時に、大きな弱みでもあります。ユーザーが操作するメニューには、視覚的なスタイルとコンテンツがまったくないため、デザイン全体と操作するのとは大きく異なる体験が得られます。たとえば、メガメニューのあるデザインは、複数のサブカテゴリーのコンテンツを同時に表示するため、ツリーテストでテストしたものとはまったく異なるブラウジング体験を提供します。

しかし、このような固有の制限であっても、慎重なデータ分析によって克服または最小化できる場合があります。たとえば、メガメニューのあるサイトの成功率ではなく、ユーザーが正しいトップレベルのカテゴリーを選択したかどうかに注目することで、このような制限を克服することができます。

全体として、これらの制限は、設計プロセスの早い段階で情報階層の大きな構造変更をすばやく反復し評価できるという利点のために支払うべき小さな代償です。デザインやコーディングの必要なく、スプレッドシートを編集するだけで全く新しいツリーを作成し、テストすることができます。



*1:「ある刺激にさらされると、その後の、おそらくは無関係なタスクでの行動に影響を与える。これはプライミングと呼ばれ、プライミング効果はユーザビリティやウェブデザインの分野で多く見られる。」Priming and User Interfacesより。