プロダクトチームがサブスクリプションをそこで管理しているからという理由で、請求書が「アカウント」の下に置かれていることがあります。しかし、それを探しているユーザーは「請求」というセクションにあるはずだと考えます。どちらの配置も特段不自然ではありませんが、その認識のズレだけで、いつものダウンロードが複数のメニューを探し回る作業へと変わってしまいます。チームにとってはあまりに自明な場所に見えるため、ユーザーから問い合わせが来るまで議論の俎上にすら載らないことも少なくありません。

カードソートは、プロダクトの情報設計（IA）を見直す余地がまだある段階で、こうしたズレを探る手段になります。コンテンツや機能を表すカードをグループ分けしてもらうことで、リサーチャーは「何と何が同じグループに属しているように見えるか」、そして「ユーザーがそれらの関係性をどう表現するか」を探究できます。Nielsen Norman Groupによるカードソートの解説では、この手法と、構造を作り上げていく上での役割が説明されています。その結果は、チームが見慣れたカテゴリを捉え直すきっかけになりますが、それを使いやすいナビゲーションへと落とし込むには、参加者がなぜその選択をしたのかを理解する必要があります。

カードソートの進め方：オープン、クローズド、ハイブリッド

たとえば、ある架空のソフトウェア企業がヘルプセンターの再編を検討しているとしましょう。そこには請求書、支払い情報、招待、権限、レポートといった記事が並んでいます。これらの記事は別々の部門によって管理されており、それぞれ異なる用語や役割分担を持っているかもしれません。そうした部門構成に沿ってヘルプセンターを整理すれば管理はシンプルになりますが、それは答えを見つける前にユーザーに対して社内事情を理解するよう強いることにもなります。

オープンカードソートでは、参加者自身が自由にグループ分けを提案できます。ある人は請求書と支払い情報を「お金」にまとめ、招待と権限を「ユーザー」の下に置くかもしれません。そうした名称が完成版のサイトには少し大まかすぎるとしても、チームにとっては貴重な手がかりになります。つまり、ユーザーの関心事に基づいて整理されたコンテンツ像が見えてきて、自社がすでに使っている構造と比較できるようになるのです。

どの形式を選ぶかによって、参加者が別の構成を提案できる自由度が変わります。クローズドカードソートではあらかじめ決められたカテゴリの中で作業してもらうため、用意された選択肢のどこに特定の項目が入ると期待されるかを探るのに適しています。ハイブリッドカードソートでは、用意されたカテゴリを使いながら、新しいカテゴリを追加することも可能です。ただし、提示されたカテゴリ自体が結果に影響を与える可能性は残ります。たとえばチームが「アカウント管理」という選択肢を用意した場合、完了したソートにそれが入っていたとしても、ユーザー自身が自然にそのカテゴリを選んだという証拠にはなりません。

カードソートの結果をどう読み解くか

もっとも示唆に富む問いは、ある項目が複数のまったく異なる場所に分類されたときに生まれます。ヘルプセンターの例でいえば、「レポートのエクスポート」を、ある参加者は請求書と一緒にし、別の参加者はチームの権限設定と一緒にグループ分けするかもしれません。これを単に「ナビゲーションについての意見の相違」として片付ける前に、リサーチャーはそれぞれがそのレポートに何が含まれていると想定していたかを確かめる必要があります。財務諸表をイメージした人と社員リストをイメージした人とでは、収まるべき場所が違って当然だからです。

もし言葉の選び方が混乱の原因だった場合、単に一番人気のあったカテゴリに記事を移動したところで問題は解決しません。代わりに、チームは「月ごとの支出レポートをエクスポート」のように具体的なラベルを試し、ユーザーが中身を正しく理解して配置できるようになったかを検証できます。曖昧な選択を深掘りすることで、それが「名前の付け方の問題」なのか「グループ分けの問題」なのかを切り分けることができます。それぞれのアプローチによって、デザインで取るべき対応が異なるからです。

だからこそ、結果のデータだけでなく、その理由（説明）もあわせて手元に残しておく価値があります。2枚のカードがどれくらいの頻度で同じグループにまとめられたかを示すサマリーはパターンの特定に役立ちますが、そのパターンを意味あるものにしている背景までは捉えきれません。サブスクリプションを管理する管理者と、経費を精算する従業員とでは、同じ請求書に対するアプローチが異なる可能性があります。双方がヘルプセンターを利用するのであれば、整理の方法を議論する際にも、それぞれのニーズが見える状態にしておくべきです。

カードの準備と参加者の選定

こうした解釈の難しさは、リサーチャーが選ぶ素材そのものから始まります。「請求設定」「請求履歴」「請求担当者」と書かれたカードを用意すると、参加者にはそれらをひとまとめにすべきだという強い言葉の手がかりが与えられてしまいます。いずれにせよそう分類された可能性はありますが、同じ単語が繰り返されていると、それが自発的な判断なのかどうか判断がつきにくくなります。大切なのは、調査で確かめたいはずのカテゴリを暗に提示することなく、中身がきちんと伝わる程度に明確に各項目を説明することです。

想定ターゲット層に近いユーザーを対象にしたパイロットテスト（予備調査）を行うと、そのバランスが崩れている部分を見つけやすくなります。見慣れないラベルが何を意味するように思えるかを尋ね、説明が必要な項目に気づき、より多くの回答を集める前にカードをブラッシュアップしましょう。直感的に分類しやすいものだけでなく、置き場に迷うようなコンテンツも含めることが大切です。わかりやすい項目ばかりでテストを組んでしまうと、ヘルプセンターの中で本当に見直しが必要な部分について、チームはほとんど何も学べなくなってしまうからです。

調査を進めながら、カードの文言や案内の変更履歴を記録しておき、セッション間の差異を正しく解釈できるようにしておきましょう。参加者の職務や経験レベルが異なる場合は、結果を合算する前にそれぞれの回答を比較してみてください。目指すべきは、ひとつのカテゴリだけでは全員のニーズを均等に満たせないケースも含め、サイトが対応すべき多様な構成を理解することです。

提案したナビゲーションを検証する

結果をもとに構造のベースが定まったら、次にもうひとつの問いに答える必要があります。「ユーザーは本当にその中から必要なものを見つけられるか？」という点です。カードソートはコンテンツを提示して整理してもらう手法ですが、実際のヘルプセンターの利用は、ある目的（タスク）とナビゲーションのラベルから始まります。請求書と支払い情報を同じグループにまとめた人であっても、デザイナーが最終的にそのセクションに付けた名前を見落としてしまうことは十分にあり得ます。

ツリーテストを使えば、提案中のナビゲーションをテキストベースで表現し、参加者に特定の項目を探してもらうことでこの点を検証できます。先ほどの架空の企業であれば、選ばせたいカテゴリ名を明かさずに「先月の請求書を見つけてください」と指示を出し、ユーザーがどこに進み、どこで迷ったかを観察することができます。その後にインターフェースのテストを行うことで、レイアウトや検索、視覚的な強調といった要素の影響を組み込むことができます。これらはグループ分けの調査単体では検証できないものです。

検証結果から、提案したカテゴリ構成自体は支持されつつも、請求書にはサブスクリプションのページから直接リンクを貼る必要があると判明することもあります。その場合、カードソートはチームがコンテンツ同士の関係性を理解するのに役立ち、その後のテストは必要な瞬間にアクセスしやすくする方法を教えてくれたことになります。これらが合わさることで、ユーザーは企業の都合で決められた分類ルールを学ばなくても、請求書へスムーズにたどり着けるようになります。

Ballparkでカードソートを実施する

実際にリサーチを実施してみる準備ができたら、Ballparkのカードソート機能ページで利用可能なフォーマットをご確認ください。また、分析機能の詳細については、カードソートデータのAI要約に関するプロダクトアップデートでカバー範囲を詳しく紹介しています。サマリーは結果をレビューするための起点として捉え、デザインの意思決定を行う前に、参加者によるグループ分けやその理由と照らし合わせて確認することをおすすめします。