カードソーティング：
ユーザーに言葉合わせを乗り越えさせる
ユーザーテストであろうとカードソーティングであろうと、調査参加者が根本的な問題に取り組む代わりに刺激語を合わせることに集中してしまうと、彼らの意見は簡単に偏る。
ユーザビリティテストを台無しにする方法として、ユーザーに実際のコマンド名あるいは彼らが使うと思われるナビゲーションラベルの入った課題を与える、というのが昔からよくある。
例えば、ユーザーがExcelの「重複の削除」機能を見つけて、利用できるかどうかをテストしたいのなら、「以前にあなたのところの製品を買ったことのある企業のリストがあるのですが、リスト内に名前が複数回出てくる企業が数社あります。このような重複を削除しなさい」と言うべきではない。こうしたタスクそのままの表現を与えてしまうと、ユーザーは「削除」や「重複」という単語を含むラベルを見つけようとUIを探してしまいがちになるからだ。したがって、そのコマンドの機能をラベルが効果的に伝えているかどうかをテストしていることにはならないし、コマンド名とそれに対応したアイコンやツールチップの組み合わせによるコミュニケーション上のメリットをテストしていることにもならない。このテストでわかるのは、ただユーザーが用語同士をうまく合わせられるか、だけになってしまうのである。
（私が実際に見た、三流のユーザビリティ関係者によって書かれたさらに酷いタスクの説明はこうだった。「余分な企業名を取り除くために重複の削除コマンドを使ってください」。どの機能を使うかを言ってしまうと、調査参加者をそのソフトウェアに自然にアプローチさせることは絶対にできなくなる。彼らは言われたとおりにやるだけで、普段どおりに振る舞ってはくれなくなるからである）。
「重複の削除」というタスクについての優れた説明は以下のようものである。「以前にあなたのところの製品を買ったことのある企業のリストがあるのですが、リスト内に名前が複数回出てくる企業が数社あります。各企業の名前が一度しか現れないように、スプレッドシートを修正してください」。これでテスト参加者は自分のゴールと、それが筋の通ったシナリオ内で提示されていることがわかるようになる。しかし、キーワードをざっと探すだけではこの問題は解決できない。その代わりに、彼らはそのタスクを達成するために役に立ちそうなコマンドを探さなければならない。この方がアプリケーションのユーザーインタフェースがユーザーのゴールをサポートしているかどうかについて、ずっと良いテストになる。
（また、単一のコマンドでは解決できない、より広範囲なタスクもテストすべきである。優れたテストタスクの書き方についてのもっと詳しい情報は我々のユーザーテストに関する一日コースを、発見しやすくかつ理解しやすい機能を作るためのガイドラインに関してはアプリケーションユーザビリティの二日間コースを参照のこと）。
カードソーティングでのキーワード合わせ
カードソーティングのような他の調査手法も、キーワード合わせの問題によって台無しになってしまう場合がある。
最近実施した、あるクライアントの健康情報サイトのユーザビリティを改善するためのプロジェクトが良い例になるだろう。このサイトのゴールは関連するさまざまな病気とその対処法についての情報を提供するというものである。さらに厄介なことには、このサイトには一般の人と専門家の両方を対象にした情報がある。したがって、ここでの重要な課題は、どのような整理の原則が情報アーキテクチャ（IA）を構造化するために最適かを決定することだった。
カードソーティングは情報空間に対するユーザーのメンタルモデルをまず探るのに良い方法であることが多いし、実際、我々のプロジェクトでもIAに対する良い出発点となっていた。カードソーティング調査の後、我々はワイヤーフレームに関するユーザーテストを数回実施し、その構造とサイトの見せ方をさらに洗練させた。我々の得たデータが、そのサイトがターゲットとするヘルスケアについての論点にどのようにユーザーがアプローチするかによってではなく、ユーザーのキーワードを合わせるスキルによるものだとしたら、我々のこうした取り組みは全て無駄になっていただろう。
クライアントの機密保持のため、別の分野、例えば、農業の分野に移動して、問題と解決策の例を示すことにしよう。
架空のこの農業関連サイトの事例では、イチゴやラズベリー、トウモロコシ、小麦といったさまざまな作物を扱うものとする。また、種まき・植え付け、育成、収穫のようなさまざまな作業も対象となる。コンテンツは最終的にプロの農家と自宅の裏庭で何種類かの作物を育てているような人の両方に向けたものになる。
では一つめのオプションでは、サイトをまずは作物によって、次に作業によって整理することにしよう。これをIA #1と呼ぶことにする：
- イチゴ
- 種まき・植え付け
- 育成
- 収穫
- 小麦
- 種まき・植え付け
- 育成
- 収穫
- その他
もう一つのオプションでは、サイトをまずは作業によって、次に作物によって整理することができるだろう。これをIA #2と呼ぼう：
- 種まき・植え付け
- トウモロコシ
- ラズベリー
- イチゴ
- 小麦
- 育成
- トウモロコシ
- ラズベリー
- イチゴ
- 小麦
- その他
我々の最初のワイヤーフレームのための初期IAの決定に役立てるために、カードソーティング調査をしたとしよう。以下がこの場合考えられる2組のカードセットである：
| カードセットA | カードセットB |
|---|---|
| Strawberries Planting (イチゴの種まき・植え付け) |
Planting Strawberries (イチゴの種まき・植え付け) |
| Strawberries Growing (イチゴの育成) |
Growing Strawberries (イチゴの育成) |
| Strawberries Harvesting (イチゴの収穫) |
Harvesting Strawberries (イチゴの収穫) |
| Wheat Planting
(小麦の種まき・植え付け) |
Planting Wheat (小麦の種まき・植え付け) |
| Wheat Growing
（小麦の育成） |
Growing Wheat （小麦の育成） |
| Wheat Harvesting
（小麦の収穫） |
Harvesting Wheat （小麦の収穫） |
（訳注：英語の語順に注意！ セットAとBを日本語に訳すと区別ができなくなってしまうが、
この場合、英語では強調したい語を前に持ってくることで、書き分けが可能。）
どちらのカードセットをユーザーに与えるかで、ソーティングの実行にひどいバイアスがかかってしまうことは明らかである。セットAが与えられれば、たいていのユーザーはIA#1を作り出そうとして、「strawberry（イチゴ）」のカードを全てまとめて、「wheat（小麦）」のカードも全てまとめて、等々するだろう。同様に、セットBではほとんどのユーザーはカードを作業（「planting（種まき・植え付け）」、「growing（育成）」等）によってまとめようとするだろうから、結果的にIA#2になってしまうことが多いだろう。
解決策：同義語と非並列構造
より良い結果を得るために、カードソーティング調査ではカードに書かれたコンセプトにどのようにアプローチするかについて、ユーザーの作業を難しくして、本当に考えてもらう必要がある。
このことがユーザビリティにおける我々のゴールと正反対のものであることは明らかだ。ユーザビリティでは我々はタスクを容易にして、ユーザーの認知負荷を減らそうと考えることが多いからである。しかし、思い出して欲しいのは、カードソーティング自体がユーザーインタフェースデザインというわけではなく、ユーザーのメンタルモデルを発見するために認識を引き出す作業だということだ。したがって、カードのユーザビリティを下げることには問題がない。なぜならば、現実のUIでそれを実際に利用するわけではないからである。
（もちろん、テストの参加者が全く理解できなくなってしまうほど、カードのユーザビリティを下げてしまうことはできない。なぜならばそうなるとこのソーティング結果が誤った方向に導いてしまうことになるからである）。
参加者が単純なキーワード合わせをさせないようにするには、1つのコンセプトに対して異なる複数の単語を使うのも1つの方法だ。つまり、同義語を使うようにすればよい。例えば、「harvesting strawberries（イチゴの収穫）」と言う代わりに、「picking strawberries（イチゴを摘むこと）」と言うことが可能だろう。
さらにまぜこぜにするためには、イチゴの科学的な属名を使って、「picking Fragaria（イチゴ属を摘むこと）」というカードを用意することもできるだろう。実際には、専門家である植物学者を対象としたサイトの調査以外にはこのカードは使わないだろうが、（我々の実際のクライアントのプロジェクトである）ヘルスケアサイトの例では、同じ条件にある異なったカードに対して、一般名と医学上の呼称を使用し、それはほとんどのユーザーに理解されていたと思われる。
ユーザーに単純なキーワード合わせをさせない他のやり方としては、非並列の説明構造を採用するというのもある。例えば、あるカードに「Planting Corn（トウモロコシの種まき・植え付け）」と書く一方で、別のカードには「Wheat Planting（小麦の種まき・植え付け）」と書けばよい。
こうした戦術を用いることは、従来からあるウェブのライティングのガイドラインの1つ、並列構造は流し読みが早くでき、比較対照がより簡単になるので、アイテムをリストとして提示する際に使った方が良い、という原則に違反することになる。もう一度言うが、ここでは「悪いデザイン」でも構わないのである。なぜならば我々が狙っているのは、カードの最適なユーザビリティではないからだ。我々がユーザーに望むことは、立ち止まって考えてもらうことであり、単にさっさとタスクを終わらせてもらうことではないのである。
調査のバイアスを避ける
ユーザーテストは簡単であると私はよく言う。要は実際の顧客を捕まえて、彼らがあなたのサイトやアプリケーションを利用するのを見ればいいからだ。しかし、この記事では優れた調査を実施する際に問題になることの1つ、バイアスを最小限にすることについて触れている。この課題を達成するには、参加者が自主的にどう振る舞うかを見る必要があり、あなた自身の考えを彼らに押しつけてはならない。後者では、彼らは単に言われたことをなぞるだけになってしまい、実生活での利用に向けてどうやってあなたがたのデザインを改善したらいいかは学べない。
私はユーザビリティの手法を長い間教えることによって、ユーザビリティでの最大の課題は優れたテストタスクを書くことと、中立的にテストセッションを進めることの2つにあると学んできた。我々の今回の（不適切な部分を削除した）ケーススタディが示すように、カードソーティング調査でユーザーにバイアスをかけないようにすることも難しい点であると言えよう。
ユーザビリティのすばらしさは、その手法がしっかりとしているため、仮にその手法を間違ったふうに使っても、役に立つ発見があるということだ。これは特にユーザーテストには当てはまる。顧客を観察しさえすればいつでも、あなたのウェブサイトの収益性を高めるために学べることが何かしらあると言える。しかし、あなたがユーザビリティを正しく実行すれば、学べることはさらにもっと増えていく。そして、ユーザーの意見を偏らせる可能性を知っていれば、そうしたバイアスを減らして、結果的にあなたの調査の価値を高めることが可能になるのである。
