紛らわしい情報アーキテクチャを正す6つの方法

もしユーザが、いつもウェブサイトの間違えたセクションを開いているなら、ラベリングの改良から、構造の明確化まで、幅広い改善策がある。

私たちは最近、1 つの製品だけのために作られたウェブページのユーザテストを行った。1 製品専用サイトは、その焦点が明確なため、ユーザビリティが優れていることが多い。しかし、私たちが行ったテストでも判ったが、問題を抱えている場合もある。

テストが示した、大きな問題の 1 つは、サイト内の Foo の基本Foo の使い方という 2 つのセクションが、ユーザにとって紛らわしいということだった。( “Foo” は本当の製品の名前ではない。このプロジェクトはクライアントのプロジェクトだったので、詳細部分は伏せさせてもらう。)

私たちは 8 名のユーザたちに、沢山のタスクをやってもらった。その内 7 つは、「 Foo の基本」または「 Foo の使い方」のいずれかを開く必要があった。

下の表は、最初に開いたセクションをまとめたものだ。各タスクでの正しい選択肢のマスは、最初にクリックした選択肢が正しかったユーザの数によって、塗り分けられている。

  • は、最初に選択したリンクが正しかったユーザが全体の 2/3 以上いたことを示している。
  • 黄色は、最初に選択したリンクが正しかったユーザが全体の 1/3 から 2/3 いたことを示している。
  • は、最初に選択したリンクが正しかったユーザが全体の 1/3 よりも少なかったことを示している。
タスク Foo の基本 Foo の使い方 その他のセクション
A 4 4
(正しい選択肢)
0
B 6
(正しい選択肢)
2 0
C 2
(正しい選択肢)
6 0
D 3
(正しい選択肢)
1 4
E 0 8
(正しい選択肢)
0
F 0
(正しい選択肢)
2 6
G 2 2
(正しい選択肢)
4

ユーザが最初のクリックで、サイト内の正しいセクションを開くことができたのは、全 56 回中 25 回、たったの 45 %だけだった。(タスク自体の成功率は、ユーザが間違えたことに途中で気付いて、正しいセクションを見つけることができた場合もあったため、これよりも高かった。)

今回は、頻繁に起きているナビゲーションの間違いを見つけることによって、ユーザテストで情報アーキテクチャの問題を見つけることができた。もし前もって情報アーキテクチャに問題があることが判っていて、それに絞り込んで調べたいならば、 カードソーティングを使うとよい。そういった場合を除いては、前提や仮説を作らずに、スタンダードなユーザテストで全てのデザイン要素をテストしたほうがよいだろう。例えば今回のユーザテストの場合、言葉遣い、視覚デザイン、フォーム、エラーメッセージ、サービスなど、情報アーキテクチャ以外の部分でも理解しにくい要素が見つかった。

問題の分析

もし、ユーザがほとんどの場合、間違えたセクションを開いているようであれば、そのサイトは明らかに情報アーキテクチャ上の欠陥を抱えている。例にあげたサイトには、他にも情報アーキテクチャの欠陥があったが、大きな問題は上記した 2 つのセクションが原因になっていた。

  • 「 Foo の基本」には、Foo の基本的な情報や、その製品の優位点、機能原理などが載っていた。
  • 「 Foo の使い方」には、すでに Foo を持っている人たちが、もっと上手くそれを活用するための情報が載っていた。

これら 2 つのセクションの分け方は、理にかなっている。しかし、それは概念モデルをしっかりと理解していればの話であり、ユーザがそれを理解していることは、とても希だ。ほとんどのユーザは、クリックし始める前にサイト設計者の世界観を理解しようと時間をとることはないのだ。

6 つの修正方法

このような場合、サイト設計者は、ユーザの間違えた情報アーキテクチャの概念を修正するために、いくつかの方法を用いることができる。

1. 2 つのセクションをまとめることによって、1 つのまとまったエリアを作り、紛らわしい選択肢が原因の間違った選択をユーザがしてしまわないよう、防ぐ。改良前の情報アーキテクチャで「 Foo の基本」か「 Foo の使い方」を選んでいたユーザたちは、改良後は 1 つにまとめたセクションで、必ずしも探している情報に直接たどり着けないかもしれない。しかし、こうすることによって以前は 2 つの異なる選択肢を選んでいたのが、どちらの場合もこの新しい選択肢を開くようになり、成功率は 75 %になる。場合によっては、この新しいセクションは、タスク D、F、G でその他の選択肢を選んでいた人たちにとっても選びやすくなり、確率はまだ高くなる可能性がある。さらにいうと、気を付けなければ、このセクションに載っていない情報を探しているユーザたちまでもが、このセクションを選んでしまう可能性まで出てくる。そういったことを確認するためには、さらにユーザテストを重ねるしかない。

この方法の確かな欠点は、2 つのセクションを 1 つにまとめると、以前よりも大きく複雑なセクションができてしまうという点だ。この新しいセクションは、機能としては、分けられていた各セクションの 2 倍の役割を果たすことになる。その結果、ユーザたちが新しいセクションの中に入ってから迷子になる可能性は高くなり、セクション全体を見渡すことができる概観部分では、探している情報のある下層セクションをみつけるのにかかる時間は長くなってしまうことになる。

2. 既存のセクションの名称を変更する。異なるラベルを使えば、2 つのセクションの違いを明確化でき、ユーザたちが正しい選択を行える可能性が高まる。前述した例では、2 つのセクションの内容が本質的に類似しているため、ラベルを変えたところで、改善があまり望めない。だがそのような場合を除けば、情報の匂いが強いラベルを使えば、ユーザの成功率を、かなり高められる。この方法は、元のラベルが造語の場合、それをユーザが理解できる一般的な言葉で置き換えることができれば特に効果的だ。

3. 選択肢の説明をする。ラベルを書き換える代わり(または追加)として、リンクしているラベルの隣に追加情報をつけ加えることによって、ユーザを助けることができる。明らかに見た目が違う製品を複数扱っている場合などは、画像が役に立つ場合もある。そうでなければ、各選択肢にそれぞれの項目の説明書きを、1、2 行つけ加える。セクションの中身を展開して見せるだけになるが、多くの場合、各セクションで扱われている具体的な情報の例をいくつか書いておくのがよい。

もちろんユーザはオンラインで沢山読みたくないということが判っているので、簡潔性は必須だ。またこういった説明文は、ホームページにしか記述するスペースがないことが一般的だ。ナビゲーションメニューは、それ自身で独立して機能できなければならない。直リンクをたどって入ってくるユーザや、最初に行っていたタスクを終えて、引き続きサイトを使い続けようとするユーザたちにとって、明確なナビゲーションラベルは、必要不可欠だ。

4. サイトの構造を作り替える。例にあげたサイトでは、問題となっている 2 つのセクションを、ユーザがもっと理解しやすいように分類しなおすことが、できるかもしれない。または、もう 1 つの選択肢としては、サイト全体の構造を変えることも可能だ。そうすれば、タスク F のように、ほとんどのユーザが間違えたセクションを選んだ場合への対処もできる。もちろんサイト全体の再構築にかかる作業は、圧倒的に多いため、この方法がとられることは希だ。

5. 情報自体を移動する。タスク C のように、ほとんどのユーザが間違えたセクションを真っ先に選択している場合、目的の情報をユーザが探しに行った場所に移し替えることができる。この方法が抱える潜在的な欠点は、サイトの構造原理の一貫性を損ない、長い目でみるとユーザが構造を理解するのを妨げてしまう可能性がある。だが、その情報を移し替えても、構造原理上問題ない場合が多い。そのような場合、この方法をとるべきだ。

6. クロスレファレンス用のリンクをつけ足す。最終的に、全てのユーザが正しい選択を行えるような、完璧な情報アーキテクチャを構築するのが不可能だということが判ったとする。そういう場合は、複雑になってしまうことを承知の上で、ユーザが決定的惨事に追い込んでしまわないよう、一般的な間違いを回避するためのインターフェイス要素をつけ足すことができる。ウェブは、ハイパーテキストでできている。ならば、ユーザに大切な情報を見つけるための唯一の方法を提供しない理由はない。もし多くのユーザが、サイト内の間違えた場所に行ってしまっているということが判っているならば、クロスレファレンス用のリンクをつけ足そう。もちろん、新たにつけ足したリンクは、他の場所に行きたいと思っていないユーザたちからみれば、足手まといになる余計な機能だ。クロスレファレンスを行う場合は、それを自覚した上で注意深く行わなければいけない。

6 つの修正方法の内、どの方法を選ぶべきか。残念ながら、その質問に対する絶対的な答えというのは、存在しない。最善策は、複数の修正方法を組み合わせることである場合が多い。つまりラベルを修正し、いくつかの機能を移動し、それでも残ってしまう問題箇所を緩和するためにクロスレファレンスのリンクをつけ足すことだ。また時には、サイト全体の情報アーキテクチャを一部分的な変更で完璧にできるような、素晴らしい改善策を思いつくこともある。

こういった類のデザイン上のジレンマを解決するには、ユーザビリティの方法論が役立つ。チームミーティングを開いて、途方もない時間何をするべきか討論するのに費やすのではなく、一番機能しそうな案でペーパープロトタイプを 2、3 個作って、新たにユーザを集めてテストを行ってみるのがよい。これが、特定の状況に合わせて一番機能する解決法を見つけ出す、一番速くて簡単な方法だ。

2006 年 9 月 25 日