ラベリングは何をしますか？

ラベルとは、人がドアを開ける前に、ドアの向こうに何があるかを伝える言葉です。このスキルは、各遷移先、セクション、アクションにどのような名前を付けるか、そして各階層でどの命名システムを使用するかを決定するのに役立ちます。すべてのラベルのテスト基準：新規ユーザーがそのラベルの向こうに何があるかを予測できるか？

始める前に

必要なもの	不足している場合
現状のラベル（それぞれの背後にあるものと表示場所を含む）	ナビゲーションを読み取るか、依頼してください。まだ何もない場合は、空の `labels.csv` とテスト計画を提供します。
誰が読むのか、そして彼らが何をしようとしているのか	尋ねてください。回答がない場合は、冒頭で自分の仮定を明記します。
ユーザー自身の言葉：検索ログ、サポート質問、カードソートのグループ名、インタビュー、レビュー	類似製品のコンテンツと慣例から草案を作成し、すべてのラベルに `untested` とマークし、テスト計画を提供して言葉を検証できるようにします。推測をユーザーの言語として提示しないでください。

メソッド

コンテキスト内でラベルを一覧化します。 各ラベルのグループ（一緒に表示されるラベル）、遷移先、実際にその背後にあるものを記録します。兄弟ラベルなしでラベルを判断すると、重複を見逃す可能性があります。

ユーザーの言葉を収集します。 ユーザーの言葉が最初の候補であり、社内用語はそうではありません。

ソース	提供されるもの	注意点
検索ログ	入力された正確な単語、最も強いトリガーワード	ファインダビリティスキルのログレポートを実行し、量を推定しないでください
サポート質問	人々がニーズをどのように説明するか	困っている人は言葉の使い方が異なります
カードソートのグループ名	人々がクラスターを何と呼ぶか	最も一般的な単語を使用します
インタビュー（5〜10人）	語彙と単語の意味	彼らが促されずに使う単語に耳を傾けます
類似製品	人々がすでに学んだ言葉	なじみ深さは賢さに勝ります

階層ごとに1つのラベリングシステムを選択します。 1つのメニューでそれらを混在させると、各項目が異なる質問に答え、人々は比較できなくなります。

システム	例	機能する場合	機能しない場合
タスク	「注文を追跡」	人々がやるべきことを持ってやってくる	タスクが重複する、またはリストが長すぎる
オーディエンス	「開発者向け」	グループごとに異なるコンテンツが必要で、自分自身を配置できる	誰かが2つのグループに属する、またはどちらかわからない
トピック	「請求」	主題が人々の考え方と一致する	トピックが組織のものであり、ユーザーのものではない
フォーマット	「動画」、「テンプレート」	人々がフォーマットで選択する	彼らが最初に主題を気にしている
AからZ	用語集、ディレクトリ	人々が正確な名前を知っている	発見するためにブラウジングしている

以下のルールに従って候補を作成します。

ルール	弱い	強い
具体的でなじみ深く、謎の肉がない	リソース、ソリューション、発見	ガイドとテンプレート
兄弟間で並列構造	料金、はじめに、チーム向け	料金、セットアップ、チーム
区別する単語を前に出す	レポート設定、レポート履歴	設定、履歴（「レポート」の下）
1つのものには、どこでも1つの名前	メニューでは「チーム」、ページでは「メンバー」	1つを選び、ナビ、タイトル、パンくずでそれを使用する
ドアが部屋と一致する	「プラン」を開くと「サブスクリプションを選択」	リンクテキストとページ見出しが一致する
リンクテキストは得られるものを伝える	詳細を見る	オンボーディングチェックリストをダウンロード

内部名称をどう扱うかを決定します。

名称が	行うこと
チーム、部署、またはプロジェクトのコードネーム	絶対に表示しない。その人が来た目的の名前を付ける
ユーザーが学ばなければならない機能のブランド名	ナビゲーションで使用される場所では、プレーンな説明とペアにする
対象ユーザーが実際に使用する専門用語	たとえ部外者が知らなくても、そのまま保持し、そのユーザーでテストする
法的または規制上の用語	正確な用語を保持し、横にプレーンな説明を付ける
頭字語	対象ユーザーが頭字語で単語以上に検索する場合を除き、略さずに書く

争点となっているラベルごとに2〜3の選択肢を提供し、 それぞれの利点と欠点を示し、1つを推奨します。単一の回答では決定が隠れてしまいます。
ラベルの周りの情報の香りを強化します。 短い説明、アイテム数、パンくずリスト、アクティブ状態は、単語だけでは伝えきれないものを補います。ラベルが単独では問題ないが、それでもユーザーが離脱する場合は、references/information-scent.md を参照してください。
予測可能性をテストします。 一方方向ではラベルのみを表示し、その背後に何があると予想するかを尋ねます。もう一方の方向では、目標を与え、どのラベルを選ぶかを尋ねます。最初のパスとしては、コールドリーディング（遷移先を隠し、自分が期待するものを書き、比較する）も可能です。それを自分の読みとして報告し、調査としてではありません。references/predictability-test.md に計画とスコアリングがあります。
他の言語をチェックします。 ラベルが翻訳される場合は、確定する前に references/locales.md を読んでください。単語単位ではなく意味で翻訳し、その市場の人々と再テストします。

成果物

ユーザーが他のファイルを指定しない限り、以下を作成します。

labels.csv、1行に1ラベル：group,label,destination,system,was,evidence,status。evidence はその単語の出典（検索ログ、サポート、仮定）を示します。status は kept、renamed または new に加え、tested または untested をセミコロンで区切って指定します（例：renamed; untested）。
labels.md、以下の順序で記述：推奨事項（2〜3文）；各階層で選択したシステム；争点となったラベル（選択肢、トレードオフ、選択とその理由）；内部名称とそれぞれの処理方法；テスト方法；前提と未解決の質問。完全なリストは labels.csv のみに存在するため、両者が矛盾することはありません。

ジョブ	返すもの
1つのものを改名	トレードオフを含む3つの選択肢、1つの選択、1つのテスト質問を返信で
1つのメニューをレビュー	`labels.csv` の行と変更点の短いリスト
サイト全体またはアプリ全体	両方のファイル

長いドキュメントがより詳細なドキュメントというわけではありません。

チェックする

機械的チェックを実行し、そのカウントを使用します：

node "${CLAUDE_SKILL_DIR}/scripts/label-check.mjs" labels.csv

これにより、曖昧な単語、グループ内の重複、同じ単語で始まる兄弟、文法形式が混在するグループ、1つのラベルに複数の遷移先、1つの遷移先に複数のラベルが見つかります。形式チェックは明確なパターンに対してのみ発動するため、自分でも各グループの並列構文を確認してください。次に、以下を確認します：

すべてのグループが1つのラベリングシステムを使用しており、labels.md にそれが記載されている。
すべてのラベルが tested または untested とマークされている。スクリプトが正常に実行されたことは、理解を証明するものではありません。
各ラベルの evidence が実際のものである。仮定の場合は、行にその旨が記載されている。

ここでClaudeにできないこと

ラベルを自分で読んだだけで、実際のユーザーが何を理解するかを学ぶことはできません。また、組織の戦略、ブランドコミットメント、政治を指示されなければ知ることはできません。使用数、検索ボリューム、テスト結果、引用を決して捏造しないでください。トレードオフを伴う代替案を提案し、1つを推奨し、その理由を述べてください。名前がブランドや法的な重みを持つ場合、特に決定は人間が行います。

引き継ぎ先

次のニーズ	スキル
グループ自体が間違っているように見える	card-sort, sitemaps
どのラベルをどのメニューに置くか	navigation
タグ付けとフィルターの用語	taxonomies
改名されたセクションのアドレス変更	url-structure, redirect-maps
階層内でのラベルテスト	tree-tests
改名しても「見つけられない」問題が解決しない	findability
まず何が存在するかのリスト	content-inventory
テンプレートの背後にあるフィールド	content-models
サイト全体の再構築、またはどこから始めればよいか不明	information-architecture

ラベリング