この記事の内容
カードソーティングは、内容を表すカードを参加者にグループ分けしてもらうUXリサーチの手法です。利用者がどの情報を関連付けて捉えているかを知りたいときに使います。すでに構成が決まっていて、目的の情報へたどり着けるかを確かめたい場合は、別の検証が必要です。
カードソーティングの結果から得たいのは、情報構造の案と、その案にした理由です。例えば「請求書の送信先メールアドレスを変更する」は、支払い設定とアカウント情報のどちらに置くとよいでしょうか。分類結果はメニューを考える材料になりますが、実際にその項目を見つけられるかまではわかりません。分類案をUXデザインとプロトタイプのレビューにつなげ、具体的なタスクで確かめます。

オープン・クローズド・ハイブリッドを使い分ける
オープン型では、参加者がグループを作り、自分で名前を付けます。クローズド型では、あらかじめ用意されたカテゴリーにカードを振り分けます。ハイブリッド型では、一部のカテゴリーを用意しつつ、新しいグループも作れます。NN/gのカードソーティング解説(英語)は、こうした違いと限界を説明しています。カテゴリーを先に示せば分類に影響します。また、参加者が付けた名前が、そのまま使いやすいナビゲーションのラベルになるとは限りません。
手法は、まだ解けていない問いに合わせて選びます。現在のカテゴリーに確かな根拠がないなら、オープン型で別のまとめ方を探れます。構成の一部だけを固定する必要があるなら、ハイブリッド型で残りを検討できます。ただし、固定したカテゴリーが結果に与える影響は、解釈するときにも考慮します。クローズド型では、用意したラベルに参加者がどの項目を当てはめるかを見られますが、実際のメニューで通る経路はわかりません。
以下では、サブスクリプション型サービスのヘルプセンターを改善する例を使います。知りたいのは、利用者が支払い、ログイン、チーム管理をどのように分けるかです。この問いにはオープン型が適しています。以降の参加者の反応や集計は説明用の架空例であり、Pixsoが実施した調査結果ではありません。
粒度をそろえてカードを作る
会社の部署ではなく、利用者が必要とする情報から始めます。「経理」「契約を管理する」「請求書をダウンロードする」は、それぞれ粒度が異なります。これらを混ぜると、具体的な回答を大きなタスクの中に入れるような分類になり、グループ同士を比較しにくくなります。
この例では、12枚のカードを用意します。IDは結果を追跡するためのもので、カテゴリーを示す手掛かりには使いません。各カードには一つのヘルプ項目を書きます。調査に使う前に、その情報が実際に存在するか、具体的な作成予定があることを確かめます。
| ID | カードに書く内容 | ID | カードに書く内容 |
|---|---|---|---|
| C01 | 請求書をダウンロードする | C07 | 2段階認証を有効にする |
| C02 | 支払い用カードを変更する | C08 | チームメンバーを招待する |
| C03 | 返金状況を確認する | C09 | チームメンバーを削除する |
| C04 | 請求書の送信先メールアドレスを変更する | C10 | ワークスペースの所有権を移す |
| C05 | ログイン用メールアドレスを変更する | C11 | 受け取る通知を選ぶ |
| C06 | 忘れたパスワードを再設定する | C12 | ワークスペースを完全に閉鎖する |
C04とC05では、請求の連絡先とログイン情報を意図的に区別しています。両方を「メールアドレスを変更する」と書くと、この違いが見えなくなります。なじみのない項目には短い説明を添えても構いません。ただし、どこに分類すべきかを誘導せず、その情報が何を扱うかを説明します。
カードの見た目もそろえます。支払いのカードだけ青くすると、見つけたいカテゴリーを先に教えることになります。最初の配置を中立にし、参加者ごとに順番を変えれば、初期画面が特定のグループ分けを暗に示すことを避けられます。
チームで結論を出す前に、個人ごとの分類を集める
内容に関わる役割の人に参加してもらいます。一般メンバー、ワークスペースの所有者、請求を担当する人では、情報を探す経路が異なるかもしれません。回答とともに、解釈に必要な役割を記録します。契約を管理する人と、請求設定を見たことがない人との意味のある違いを、平均化して消さないようにします。
本調査の前に短い予備調査を行うと、わかりにくいカードや操作しづらい点に気付けます。参加人数は、理解したい利用者層と、判断に必要な確かさに合わせて決めます。少人数の例示的なセッションから、利用者全体の傾向を数値で推定することはできません。
参加者には、自分が理解しやすいように項目をまとめ、グループに名前を付けてもらいます。途中で考えを変える、知らない項目を脇に置く、二つの場所に合う理由を説明するといった反応も認めます。すべてのカードをきれいに収めるよう促すのではなく、迷いや保留も記録します。
進行役がいる場合は、「この項目にはどのような共通点がありますか」「ここに置いたとき、何を考えていましたか」のように、具体的で中立な質問をします。「これは請求のカテゴリーではありませんか」と聞くと、答えを示してしまいます。完成したボードは整って見えても、参加者の元の理解を表していない可能性があります。
各参加者は、誰も分類していないカードセットから始めます。複数人が同じボードを一緒に整理すると、議論や他者の選択の影響を受けたワークショップの成果になります。チームの認識合わせには役立ちますが、独立した利用者の分類を複数集めたことにはなりません。
元の分類と、分析者の解釈を分けて残す
各セッションでは、グループに含まれるカードID、参加者が付けた名前、未分類のカード、関連する発言を残します。共有する分析ボードには個人を特定できる情報を載せず、参加者コードを使います。
ある人が「お金」、別の人が似たグループを「支払い」と名付けたとします。分析では両方に「支払いに関する項目」というラベルを付けてもよいですが、元の名前とカード構成は保持します。「アカウント」という名前のグループをすべて統合するのは避けます。一人はログイン情報を、もう一人はワークスペース全体を指しているかもしれません。
C04では、この違いが特に重要です。次の表は、あり得る三つの説明を示した架空例です。分類結果の読み方を説明するためのもので、実際のサブスクリプション利用者についての知見ではありません。
| C04の置かれた場所 | 参加者の説明 | デザインで検討する問い |
|---|---|---|
| 請求書や支払い用カードと同じグループ | 「支払いの書類が届く先だからです」 | 請求のカテゴリーに置くと、用途が伝わるか。 |
| ログイン用メールアドレスやパスワードと同じグループ | 「自分のメールアドレスはアカウントで変えると思います」 | 請求の連絡先と、本人のログイン情報を区別できる説明か。 |
| 支払いとチーム関連の項目の間で保留 | 「チームの別の人が受け取っています」 | 管理者が別の担当者の連絡先を変更するための入口が必要か。 |
これらは、それぞれ異なる内容やナビゲーションの必要性を示しています。すべてを「アカウント設定」と名付ければ図上の違いは消えますが、利用者の迷いが解消するわけではありません。
分類の傾向を数えても、操作の成功率には置き換えない
少数の分類を手作業で記録した場合は、二つのカードが同じグループに置かれた回数を表計算で集計できます。集計値の背景にあるグループを調べられるよう、元の記録を残します。規模が大きい調査では、データ収集や分析に対応した専用のカードソーティングサービスを検討できます。
計算の架空例として、6人全員がC01とC02を分類し、そのうち5人が同じグループに置いたとします。同じグループに置かれた割合は6件中5件です。請求書と支払い用カードを共通のカテゴリーに置く案を検討する材料になります。ただし、これはナビゲーションの成功率83%を意味しません。提案したメニューから請求書を探すタスクは、まだ誰も試していないからです。
どちらかのカードを未分類にした参加者がいれば、その状態を記録し、分母にどう扱うかを定めます。未分類のカードを、別のカテゴリーに置くべきという証拠として扱わないようにします。また、二枚ずつの組み合わせだけで階層全体は決まりません。いくつかの組み合わせがまとまりを作る一方、一つの項目が大きな二つのテーマに関わる場合もあります。
繰り返し現れるグループ、置き場所が分かれる項目、役割による違いを見つけたら、参加者の説明に戻ります。多く選ばれた分類は案の根拠になりますが、最適なラベル、メニューの階層数、入口をどの程度目立たせるかまで決めるものではありません。
Pixsoで分類の実施と結果の整理を進める
Pixsoのオンラインホワイトボードでは、付箋、文字、図形を共有キャンバスに配置できます。これらを使い、進行役がいるカードソーティングや、結果をもとにしたチームでの構造検討を行えます。参加者の募集、調査記録、統計分析は、リサーチの中で別途行います。付箋をグループ化したボード自体に、カードソーティングの自動分析機能が備わるわけではありません。
カードセットから同じ大きさの付箋を作り、作業する範囲をわかりやすく用意します。参加者ごとにボードを複製し、他の人の結果が見えないよう共有範囲を設定します。カードをドラッグしづらい人には、進行役へ配置を指示してもらう方法もあります。その場合は、回答を比較するときにわかるよう、実施方法を記録します。
収集後も元の分類は変更せず、別の分析用ボードを作ります。「繰り返し現れるまとまり」「分類が分かれる項目」「ナビゲーション案」の三つに分け、提案の横にカードIDと個人を特定しない観察記録の参照を添えます。参加者の言葉、繰り返された配置、製品上の制約のどれを根拠にした案かが、レビューする人にも伝わります。

分類結果からナビゲーション案を作る
このヘルプセンターでは、最初の案として「請求」「ログインとセキュリティ」「ワークスペースのメンバー」を置けます。架空の参加者が付けた名前をそのまま使ったのではなく、結果を踏まえたデザイン案です。C11とC12の配置には、まだ根拠が必要です。メニューを完成させるためだけに、判断しにくい項目を「その他」へ入れないようにします。
C04の記事は請求のカテゴリーを主な掲載場所とし、ログイン用メールアドレスの記事から関連リンクを置く案が考えられます。二つの入口から、同じ管理された回答へ案内できます。似たタイトルでヘルプ本文を複製することとは異なります。請求の連絡先を変更できる役割も確認し、分類だけでなく実際の操作に答える説明にします。
次に、ツリーテストでナビゲーション案を確かめます。例えば「今後の領収書を経理担当者が受け取るようにしたいとします。変更方法はどこで調べますか」と尋ねれば、カテゴリー名を教えずに情報を探してもらえます。リンク先では、到達先だけでなく、選ばれた経路の読み方も説明しています。
階層に見通しが立ったら、実際のパソコン用とモバイル用の画面に組み込みます。メニューの見せ方、検索、関連リンク、ページの内容によって、利用者の行動は変わります。カードソーティングで根拠のある構造案を作り、次の検証で、その構造がタスクの達成に役立つかを確かめましょう。