clarify

わかりにくい、混乱を招く、または書き方が不適切なインターフェーステキストを特定して改善し、製品をより理解しやすく、使いやすくします。

必須の事前準備

/impeccable を実行してください。デザイン原則、アンチパターン、コンテキスト収集プロトコルが含まれています。作業に進む前にこのプロトコルに従ってください。デザインコンテキストがまだない場合は、必ず先に /impeccable teach を実行してください。さらに、対象ユーザーの技術レベルと、利用状況におけるユーザーの心理状態も把握してください。

---

現在のコピーを評価する

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

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

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

2. コンテキストを理解する：

   • 対象ユーザーは誰ですか？（技術者？一般ユーザー？初めて利用するユーザー？）
   • ユーザーはどのような心理状態ですか？（エラー時にストレスを感じている？成功時に自信を持っている？）
   • 求める行動は何ですか？（ユーザーに何をしてほしいですか？）
   • 制約は何ですか？（文字数制限？スペースの制約？）

重要：わかりやすいコピーは、ユーザーが目的を達成する助けになります。わかりにくいコピーは、ユーザーの不満やミス、サポートへの問い合わせにつながります。

コピー改善の方針を立てる

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

• 主なメッセージ：ユーザーが知る必要がある最も重要なことは何ですか？
• 必要な行動：次にユーザーは何をすべきですか（何もする必要がない場合も含む）？
• トーン：どのような印象にすべきですか？（親切？謝罪？励ます？）
• 制約：文字数制限、ブランドのトーン、ローカライズに関する考慮事項

重要：優れたUXライティングは意識されません。ユーザーは言葉に気づくことなく、すぐに内容を理解できるはずです。

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

次のような一般的な箇所のテキストを見直します。

エラーメッセージ

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

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

原則：

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

フォームのラベルと入力方法

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

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

原則：

• 汎用的なプレースホルダーではなく、明確で具体的なラベルを使う
• 例を使って入力形式を示す
• 入力を求める理由が明らかでない場合は説明する
• 入力欄の後ではなく、前に説明を置く
• 必須項目の表示を明確にする

ボタンとCTAのテキスト

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

原則：

• 操作内容を具体的に示す
• 能動態を使う（動詞＋名詞）
• ユーザーのメンタルモデルに合わせる
• 具体的にする（「保存」は「OK」より適切）

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

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

原則：

• 価値のある情報を加える（ラベルを繰り返すだけにしない）
• 暗黙の疑問（「これは何？」や「なぜ必要？」）に答える
• 簡潔かつ十分な説明にする
• 必要に応じて詳細ドキュメントへのリンクを追加する

空の状態

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

原則：

• 空である理由を説明する（自明でない場合）
• 次に行う操作を明確に示す
• 行き止まりではなく、歓迎する印象にする

成功メッセージ

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

原則：

• 何が起きたかを確認できるようにする
• 関連する場合は、次に起きることを説明する
• 簡潔かつ十分な内容にする
• ユーザーの感情に合った表現にする（大きな成果は一緒に喜ぶ）

読み込み状態

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

原則：

• 所要時間の目安を伝えます。
• 何が行われているかを説明します（見ただけではわからない場合）。
• 可能であれば進行状況を表示します。
• 適切であれば、処理を中断する方法（「キャンセル」）を用意します。

確認ダイアログ

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

原則：

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

ナビゲーションと現在地の案内

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

原則：

• 具体的でわかりやすくします。
• ユーザーが理解できる言葉を使います（内部用語は使いません）。
• 階層を明確にします。
• 情報の手がかり（パンくずリスト、現在地）を考慮します。

明確さの原則を適用する

すべての文言で、次のルールに従います。

1. 具体的にする：「値を入力」ではなく「メールアドレスを入力」
2. 簡潔にする：不要な言葉を削ります（ただし、わかりやすさを損なわないようにします）。
3. 能動態にする：「変更を保存します」ではなく「変更が保存されます」
4. 人間らしくする：「システムエラーが発生しました」ではなく「問題が発生しました」
5. 役立つ内容にする：何が起きたかだけでなく、次に何をすべきかを伝えます。
6. 一貫性を保つ：全体を通して同じ用語を使います（変化をつけるために言い換えません）。

絶対に避けること：

• 説明なしに専門用語を使う
• ユーザーを責める（「エラーが発生しました」ではなく「この項目は必須です」）
• 曖昧な表現を使う（説明なしに「問題が発生しました」とだけ伝える）
• 不必要に受動態を使う
• 長すぎる説明を書く（簡潔にします）。
• エラーにユーモアを使う（代わりに共感を示します）。
• 技術的な知識があることを前提にする
• 用語を使い分ける（用語をひとつ選び、統一します）。
• 情報を繰り返す（見出しで導入文を言い換える、説明を重複させる）。
• プレースホルダーだけをラベルとして使う（ユーザーが入力すると消えてしまいます）。

改善を検証する

文言の改善が機能するか、次の点をテストします。

• 理解しやすさ：ユーザーは前後関係がなくても理解できますか？
• 行動のしやすさ：ユーザーは次に何をすべきかわかりますか？
• 簡潔さ：明確さを保ちながら、できるだけ短くなっていますか？
• 一貫性：ほかの箇所の用語と一致していますか？
• トーン：状況に適した表現になっていますか？

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