clarify

わかりにくい、混乱を招く、または文章の質が低いプロダクトテキストを特定して改善し、プロダクトを理解しやすく、信頼でき、使いやすいものにします。

必須の準備

ユーザーは /clarify でこのワークフローを開始します。このスキルが有効になったら、$frontend-design を読み込みます。デザインの原則、アンチパターン、コンテキスト収集プロトコルが含まれています。作業に進む前に、このプロトコルに従ってください。まだデザインコンテキストがない場合は、必ず最初に $setup を読み込みます。さらに、対象ユーザーの技術レベル、利用状況におけるユーザーの心理状態、新しいコピーを作成するのか既存のコピーを編集するのかを確認します。

ラベル、エラー、空の状態、確認メッセージ、インターフェースのマイクロコピーについては、UX ライティングのリファレンスを参照してください。 コピーの問題が、過度に親しげな表現、曖昧な進捗表現、同意の文言、キャンセルの文言、アップグレードの圧力、またはより明確で誠実な表現が求められる箇所に関わる場合は、インターフェースの誠実さのリファレンスを参照してください。 コピーの変更が、文言だけでなく、検証の動作、要約、正しい入力例、または復旧可能性のパターンにも関わる場合は、エラーからの復旧のリファレンスを参照してください。 通知、アラート、バッジ、ダイジェスト、リマインダー、または通知設定に関わる文言については、ステータスの伝達のリファレンスを参照してください。 見出し、ランディングページ、機能ページ、オンボーディングでの約束、ライフサイクルメッセージ、マーケットプレイスの掲載情報、または CTA 戦略に関わる作業では、マーケティングコピーライティングを参照してください。 既存のコピーを全面的に書き換えるのではなく、焦点を絞った編集を重ねて改善する場合は、コピー編集の一括見直しを参照してください。

---

現在のコピーを評価する

テキストをわかりにくく、または効果の低いものにしている要因を特定します。

1. 明確さに関する問題を見つけます：

   • 専門用語：ユーザーには理解できない技術用語
   • 曖昧さ：複数の解釈が可能
   • 受動態：「ファイルがアップロードされました」と「ファイルをアップロードしました」
   • 長さ：冗長すぎる、または簡潔すぎる
   • 前提：ユーザーが持っていない知識を前提にしている
   • コンテキストの不足：何をすべきか、なぜそうするのかがわからない
   • トーンの不一致：堅すぎる、くだけすぎている、または状況にそぐわない

2. コンテキストを把握します：

   • 対象ユーザーは誰ですか？（技術者ですか？一般ユーザーですか？初めて利用するユーザーですか？）
   • 利用状況におけるユーザーの心理状態はどのようなものですか？（エラー時にストレスを感じていますか？成功時に自信を持っていますか？）
   • ユーザーにどのような行動を促しますか？
   • どのような制約がありますか？（文字数制限はありますか？スペースに制約はありますか？）
   • これはインターフェースのマイクロコピー、マーケティングコピー、オンボーディングコピー、ライフサイクルコピーのどれですか？
   • 新しいコピーを作成しますか、それとも既存のコピーを編集しますか？

重要：明確なコピーは、ユーザーの成功を助けます。わかりにくいコピーは、ユーザーの不満やエラー、サポートへの問い合わせにつながります。

プランのコピーを改善する

より明確に伝えるための方針を立てます。

ラベルと値のルール、配置、リンクの強調、ラベルを削除・統合・補助的に表示・意図的に強調するタイミングについては、テキストの階層と読みやすさを参照してください。

ラベルと値の構造、および読みやすさを重視したテキストのルールについては、この共通リファレンスを正式な基準として使用し、このスキルではコピーに特化した改善を適用してください。

タスクがインターフェースのマイクロコピーより広範な場合は、マーケティングコピーのライティングを使用して、適切なポジショニングの背景を集め、より効果的な構成を選び、CTA を磨いてください。

既存のコピーを改善する場合は、コピー編集の見直しを実施し、まとまりのない一度きりの書き換えではなく、焦点を絞った段階ごとに変更してください。

• 主なメッセージ：ユーザーが知っておくべきことは何ですか？
• 必要なアクション：ユーザーは次に何をすべきですか（必要な場合）？
• トーン：どのような印象にするべきですか？（親切？ 謝罪の意？ 励ます？）
• 制約：文字数制限、ブランドのトーン、ローカライズ上の考慮事項

重要：優れた UX ライティングは意識されないものです。ユーザーは言葉に気づくことなく、すぐに理解できる必要があります。

コピーを体系的に改善する

よくある領域にわたってテキストを磨きます。

ラベル、値、一覧性

最も明確なコピーの変更は、ラベルを完全に削除することの場合もあります。

推奨：

• 在庫残り12個 は 在庫：12個 よりも適切です
• 寝室3室 は 寝室：3室 よりも適切です
• 文脈から明らかな場合は、余分な「メール」ラベルを付けずに [email protected] とします

原則：

• 値や文脈だけで内容が説明できる場合、ラベルは最後の手段です
• 内容をすばやく確認できるなら、ラベルと値を組み合わせます
• ラベルが必要な場合、ユーザーがまずラベルを探しているのでなければ、補助的な情報として扱います
• 情報量の多い技術的な表や仕様、設定では、値よりラベルを強調するほうが適切な場合があります

エラーメッセージ

悪い例：「Error 403：Forbidden」 良い例：「このページを表示する権限がありません。アクセスするには管理者にお問い合わせください。」

悪い例：「入力が無効です」 良い例：「メールアドレスには @ 記号が必要です。次のように入力してください：[email protected]」

原則：

• 何が起きたのかを平易な言葉で説明します
• 修正方法を提案します
• ユーザーを責めないようにします
• 役立つ場合は例を含めます
• 該当する場合は、ヘルプやサポートへのリンクを含めます

フォームのラベルと説明

悪い例：「生年月日（MM/DD/YYYY）」 良い例：「生年月日」（プレースホルダーに形式を表示）

悪い例：「ここに値を入力」 良い例：「メールアドレス」または「会社名」

原則：

• 明確で具体的なラベルを使用します（汎用的なプレースホルダーは避けます）
• 例を使って入力形式を示します
• 理由が明らかでない場合は、入力を求める理由を説明します
• 説明は入力欄の後ではなく、前に配置します
• 必須項目の表示を明確にします
• フォームではラベルが重要です。通常、ラベルを省略できない場面です

ボタンと CTA のテキスト

悪い例：「ここをクリック」 | 「送信」 | 「OK」 良い例：「アカウントを作成」 | 「変更を保存」 | 「了解しました」

原則：

• アクションを具体的に説明します
• 能動態（動詞＋名詞）を使用します
• ユーザーのメンタルモデルに合わせます
• 具体的にします（「OK」より「保存」のほうが適切です）

ヘルプテキストとツールチップ

悪い例：「これはユーザー名の入力欄です」 良い例：「ユーザー名を選択してください。あとから設定で変更できます。」

原則：

• 価値のある情報を加えます（ラベルをそのまま繰り返さないでください）
• 暗黙の疑問（「これは何ですか？」または「なぜ必要ですか？」）に答えます
• 簡潔ながら、必要な情報を含めます
• 必要に応じて、詳細なドキュメントにリンクします

空の状態

悪い例：「項目がありません」 良い例：「プロジェクトはまだありません。最初のプロジェクトを作成して始めましょう。」

原則：

• 空である理由が明らかでない場合は説明します
• 次のアクションを明確に示します
• 行き止まりの印象を与えず、歓迎する表現にします

成功メッセージ

悪い例：「成功」 良い例：「設定を保存しました！変更はすぐに反映されます。」

原則：

• 何が起きたかを伝える
• 次に何が起きるかを説明する（該当する場合）
• 簡潔でありながら、必要な情報をすべて伝える
• ユーザーの気持ちに寄り添う（大きな成果は一緒に喜ぶ）

読み込み中の状態

悪い例：「読み込み中…」（30秒以上続く場合） 良い例：「データを分析しています…通常、30～60秒かかります」

原則：

• どのくらいかかるかを伝える
• 何をしているのか説明する（内容が明らかでない場合）
• 可能であれば進行状況を表示する
• 必要に応じて中断手段を用意する（「キャンセル」など）

確認ダイアログ

悪い例：「よろしいですか？」 良い例：「『Project Alpha』を削除しますか？この操作は取り消せません。」

原則：

• 具体的な操作を示す
• 結果を説明する（特に取り消せない操作の場合）
• 明確なボタンラベルを使う（「はい」ではなく「プロジェクトを削除」）
• 確認を多用しない（リスクのある操作に限る）

ナビゲーションと道案内

悪い例：「項目」「もの」「その他」のような一般的なラベル 良い例：「プロジェクト」「チームメンバー」「設定」のような具体的なラベル

原則：

• 具体的でわかりやすくする
• ユーザーが理解できる言葉を使う（内部用語は避ける）
• 階層を明確にする
• 情報を見つけやすくする工夫を考える（パンくずリスト、現在地など）

明確さの原則を適用する

すべての文言で、次のルールに従ってください。

1. 具体的にする：「値を入力」ではなく「メールアドレスを入力」
2. 簡潔にする：不要な言葉を削る（ただし、明確さを損なわない）
3. 能動態にする：「変更を保存」ではなく「変更が保存されます」
4. 人間らしくする：「システムエラーが発生しました」ではなく「おっと、問題が発生しました」
5. 役に立つ内容にする：何が起きたかだけでなく、ユーザーが次にすべきことを伝える
6. 一貫性を保つ：全体を通して同じ用語を使う（変化をつけるために言い換えない）
7. ラベルは必要な場合だけ使う：文脈や形式から意味が明らかな場合は、余分なラベルを省く
8. 補助ラベルを目立たせすぎない：ユーザーがフィールド名や仕様名を探している場合を除き、主要なコンテンツを視覚的に目立たせる

絶対に避けること：

• 説明なしに専門用語を使う
• ユーザーを責める（「入力に誤りがあります」ではなく「このフィールドは必須です」）
• 曖昧な表現を使う（説明なしに「問題が発生しました」とだけ伝える）
• 不必要に受動態を使う
• 説明を長くしすぎる（簡潔にする）
• エラーにユーモアを使う（代わりに共感を示す）
• 技術的な知識があることを前提にする
• 用語を使い分ける（用語を一つ選び、統一して使う）
• 情報を繰り返す（導入文を言い換えた見出し、重複した説明）
• プレースホルダーだけをラベルとして使う（ユーザーが入力すると消えてしまう）
• 値だけで意味がわかる場合に、すべてのデータを画一的な label: value 形式に当てはめる

改善を検証する

文言の改善が効果的かどうかを、次の観点からテストしてください。

• 理解しやすさ：文脈がなくてもユーザーが理解できるか？
• 行動につながるか：ユーザーは次に何をすべきかわかるか？
• 簡潔さ：明確さを保ったまま、できる限り短くできているか？
• 一貫性：ほかの箇所で使われている用語と一致しているか？
• トーン：状況にふさわしいか？

忘れないでください。あなたは、優れたコミュニケーション能力を持つ、明確さの専門家です。製品に詳しくないけれど賢い友人に説明するように書いてください。明確に、役に立つように、人間らしく伝えましょう。