今日の問い
初めて来た人は、あなたの分類名から中身を予測できますか。
30秒でつかむ
分類は似た項目をまとめる規則、ラベルはそのまとまりの名前、階層は親子関係です。三つを同時に決めると、社内用語をきれいに並べただけの構造になりがちです。
まず前回の棚卸し項目を、利用者の用事でまとめます。次に中身を予測できる名前を付け、最後に必要な深さだけ親子関係を作ります。
30秒図解 · LESSON 14
分岐図
利用者の言葉で、迷わない分類を作る
分類軸、ラベル、階層の深さを別々に検証します。
利用者の目的
- 分類軸
- 一貫したラベル
- 適切な階層
- 利用者テスト
CLUE · 見抜く手掛かり
兄弟項目が同じ粒度か
TRAP · ありがちな罠
社内用語をそのまま見出しにする
原則
分類の目的は、情報を整頓することではありません。利用者が次に探す場所を予測できることです。担当部署が違っても、同じ用事で使う情報なら近くに置く候補になります。
カードソーティングは、項目名を書いたカードを参加者にまとめてもらう調査法です。分類の正解を多数決で決めるものではありません。どの項目で迷ったか、なぜ一緒にしたかを聞くと、作り手と利用者の考え方の差が見えます。
ラベルには、中にある情報を具体的に予告する語を使います。「サービス」「その他」のような広すぎる語は、押すまで内容が分かりません。「予約の確認と変更」なら、そこでできることを予測できます。
階層を深くすれば整理されて見えますが、利用者が毎回正しい枝を選べるとは限りません。一つの項目が複数の場所に見える設計もあり得ます。ただし正本は一つにし、重複ページを作らずリンクで到達経路を増やします。
content-inventory.csvに group、label、parent_id の三列を加えましょう。迷った項目は無理に確定せず、notesに迷いの理由を書きます。
利用者が項目をまとめる過程から、分類に対する利用者の捉え方を調べる方法と、その限界を支える。
良い例と惜しい例
分類名の決め方
AIへの指示例
目的: content-inventory.csvの項目を、利用者が予約を変更するときの用事で仮分類する
制約: 既存idとstatusを変えない。組織名を分類名にしない。判断が割れる項目は一つに決めつけない
参照: content-inventory.csv、対象利用者のインタビューメモ
受入条件: group、label、parent_id、notesを追記し、各ラベルの根拠を利用者の発言またはタスクで説明する
確認問題
セルフチェック
1. 参加者が『予約確認』を二つのグループの間で何度も動かしました。次の判断として適切なのはどれですか。
最終制作へ反映する
分類とラベルを加えたコンテンツ一覧
前回の一覧へgroup、label、parent_idを追加し、主要タスクに関わる全項目を仮分類する。迷いはnotesへ残す。
Acceptance criteria
- 各項目の分類名から中身または利用者の用事を予測できる
- 迷った項目に、迷いの理由と確認方法が記録されている
今日のまとめ
- 分類、ラベル、階層は別の判断として扱う
- 利用者が迷う場所には、改名や複数経路の手掛かりがある
- 次は、確かめたまとまりをサイト全体の構造へ移す