インターフェース向けライティング

優れたインターフェース文は目立たない。言葉がデザインとシームレスに機能すれば、ユーザーは言葉に気づかない。

文章はプロセスの最後に埋め込むものではなく、デザインプロセスの最初から含めるべきである。レイアウト、インタラクション、ビジュアルデザインと一緒に言葉を検討すれば、結果はシームレスに感じられる。後付けすれば、プロダクト体験がぎこちなく見える。

インターフェース内のテキストはすべて、小さなコミュニケーション行為である。ユーザーの時間を尊重し、ユーザーがいるところで出会い、前に進むのを助けるべきである。

---

トリガーされたとき

ステップ1：声（ボイス）と個性を確立する

声は基盤である。すべてのコピー決定（何を言うか、どう言うか、何を省くか）は、このプロダクトが何か、誰のためか、どのように聞こえるべきかについての明確な理解から生まれる。明確な声が定義されていなければ、コピーは一貫性を欠き、プロダクトはまとまりを失う。

既存の声の定義を探す。 以下をチェック：

• 声やトーンを定義した CLAUDE.md、AGENTS.md、またはこれに類似したプロジェクト設定
• スタイルガイド、デザインシステムドキュメント、またはブランドガイドライン
• 用語リストまたは用語参照

声の定義が存在する場合、すべてのコピー作業のレンズとして使用する。作業中のコピーがそこから外れていれば、矛盾をフラグする。

声の定義が存在しない場合、既存のコピーから現在の声を推測する。パターンを探す：フォーマルですか、それはカジュアルですか？技術的ですか、それとも平易ですか？温かみがありますか、それは淡々としていますか？コピーが矛盾しているか不十分な場合は、ユーザーが執筆前に声を確立するのを支援する。

対話を通じた声の確立

ユーザーにこれらの質問を通じて導く：

1. プロダクトは何をしているか、誰が使うか？ 専門家向けの銀行アプリと子ども向けの貯金アプリは似た目的を果たすが、まったく異なる音声を持つべきである。対象者は語彙、複雑さ、言語レベルを決定する。

2. 人々がそれを使う理由は何か、どこで使うか？ 健康アプリを危機的状況で使う人は落ち着いた明確さが必要。家でゲームを閲覧する人は遊び心を扱うことができる。使用のコンテキスト — 物理環境、感情状態、競合する注意 — はユーザーがどれだけのテキストを吸収できるか、どのトーンが適切かを形成する。

3. プロダクトを人間として想像する。それを唯一にする3〜4つの個性特性は何か？ 自由に発想し、似た言葉をテーマにグループ化し、テーブルステークス特性（「分かりづらくない」）を破棄し、プロダクトの個性を本当に差別化するものを保持する。

4. 生産的な緊張を探す。 最高の声の定義には互いに押し合う特性がある。「親しみやすい」と「簡潔」は有用な緊張を作成する — これらはさまざまな状況に合わせてトーンを調整するときに回転させるダイアルになる。

5. キャプチャする。 ユーザーが声の定義をどこか永続的な場所（AGENTS.md、CLAUDE.md、またはスタイルガイドドキュメント）に保存することをお勧めし、セッション全体で存続するようにする。用語リストはこれとよくペアになり、同じファイルに保存すべき。

ステップ2：リクエストを評価する

必要なコピー作業の種類を特定：

• 新規コピー：スクリーン、フロー、またはコンポーネント用に最初から執筆。
• レビュー：既存コピーの明確性、一貫性、トーンを評価。
• 書き直し：機能していない特定のテキストを改善。
• 用語：用語リストの構築または維持。

その後、関連するインターフェースパターンを特定し、関連セクションについて references/patterns.md を参照。

ステップ3：声を適用し、その後に原則を適用する

すべてのコピーについて、この順序で作業：

1. 声のように聞こえるか？ 3〜4の特性に対してそれを読む。それを声に出して読んだら、このプロダクトから来ていると認識するか？
2. この状況のためにどの特性を上げ下げする必要があるか？ 各声の特性をダイアルと考える。祝賀のモーメントは温かさを上げる；エラーは明確さと親切さを上げ、親しみやすさを下げる。
3. コア原則を適用（目的、先読み、コンテキスト、共感 — 以下詳述）。
4. 工芸ルールを適用（埋め込みを削除、繰り返しを回避、具体的にする — 以下詳述）。

順序は意図的で優先チェーンをエンコード：明確性 > 声 > 工芸ルール。 明確性は常に勝つ — 声が誰かが何をするかを理解する妨げになれば、それを削減。声は次 — それはどのように聞こえるかを形成し、工芸ルールは確立された声を損なう方法で単語を切ったり句を再構成したりすべきでない。工芸ルールは声フィルター済みヒューリスティック、絶対ではない。常に声に対して工芸編集をクロスチェックしてからコミットする前に。

ステップ4：変更を配信する

コピー要素ごとに作業 — タイトル、本文、ボタン、ラベル — 元のものを表示してから書き直し、簡潔な理由が声と原則に関連付けられている。ユーザーを混乱させたりブロックする変更を磨きの前に優先。フロー全体をレビューするときは、用語の矛盾をフラグし、最後に用語リストエントリを提案。

---

声とトーン

声 対 トーン

声はプロダクトの一貫した個性 — それがどのように常に聞こえるかを定義する3〜4の特性。これらは変わらない。

トーンは声がどのように状況に適応するか。各声の特性をダイアルと考え、モーメント次第で上下に回転できる：

• マイルストーンを祝っているか？温かさを上げ、簡潔さを下げ。
• エラーを報告しているか？明確さと親切さを上げ、親しみやすさを下げ。
• 新規ユーザーをオンボード中か？親切さと温かさのバランス。
• 破壊的なアクションを確認しているか？直進性を上げ、冷静で簡潔に保つ。

実際にトーンを適用する

各状況について、どの声の特質を強調し、どれが後退するべきかを決定。

例：ネットワークに接続できないエラーの場合、明確さと親切さは大幅に上がる。シンプルさは適度に保たれる、彼らは最も重要な詳細が必要だから。親しみやすさは下がる、なぜなら彼らを動かすことは温かく聞こえることより重要だから。

個性がどこに属するか

個性は余地がある瞬間で輝く — ウェルカムスクリーン、マイルストーン、空の状態。エラーメッセージ、破壊的なアクション、重大なフローでは、声を下げ、明確さがリードしさせる。ステップ3からの優先チェーンが適用：明確性が最初、常に。

---

コア原則

目的、先読み、コンテキスト、共感 — 何を書くか、どう書くか、いつを書くかのためのフレームワーク。声のレンズを通じて適用。

1. 目的

執筆する前に、答える：この人が今知る必要のある最も重要なこと一つは何か？

• 情報階層を使用。 見出しとボタンは主要メッセージを伝える；サポートテキストは詳細を埋める。誰かが見出しとボタンだけを読む場合、彼らは状況を理解すべき。
• このモーメントに奉仕しないものを切る。 それを別の場所に移すか削除する。スクリーンがやりすぎようとするときは、その目的に戻り、他のすべてを削除。
• 人々に目的を伝える。 機能を導入するときは、それが存在する理由とそれが彼らにとって重要な理由を伝える。

2. 先読み

インターフェースを会話として考える。あらゆる良い会話には自然な前後 — 聞く、応答する、相手が次に聞く必要があることを予測する — があります。

• 誰かに問題について伝えた後、それを修正する方法を伝える。「Wi-Fiに接続できません」 → 「Wi-Fiに接続できません。接続を確認してもう一度試してください。」
• 誰かに何かをするように求めた後、どうするかを明白にする。「身元を確認してください」 → 「身元を確認してください」明確なボタンまたはリンク付きでプロセスを開始。
• 誰かが何かを完了した後、それを認め前に指す。「パスワードが変更されました」 → 「パスワードが変更されました。新しいパスワードでサインインできます。」
• 「理由」で始める。 利益または理由を指示の前に置く：「[利益]するには、[指示]。」前もって動機付けを置くことは、指示が要求ではなく合理的な要望に感じさせます。

3. コンテキスト

人々はワイルドに異なる状況でプロダクトを使用する。使用コンテキストは執筆を形成。

• アプリの外を考える。 物理的および感情的な状況を検討。
• 利用可能な注意に密度をマッチさせる。 ミッドタスクテキストは超短いべき。セットアップフローはより多くを許容できる。
• タイミングは重要。 前にではなく関連するときに情報を表示。ユーザーが見ている場所に指示を配置。
• デバイス用に執筆。 ジェスチャーを正しく説明（「クリック」ではなくタッチで「タップ」）。携帯電話は簡潔さを要求；共有スクリーン（TV）は大きく、スキャン可能なテキストが必要。

4. 共感

異なる能力、言語、文化、技術的流暢性、感情状態を持つ誰もが使用するかもしれないプロダクト向けに執筆。

• 平易で直接的な言語を使用。 専門用語、イディオム、文化的に固有のリファレンスを回避。
• 最初からアクセシビリティ用にデザイン。 ラベル、説明、代替テキストは後付け — いくつかの人にとって全体の経験。詳細なガイダンスについてはパターン参照を参照。
• 包括的で中立的な言語を使用。 性別、年齢、または能力への不要なリファレンスを回避。
• ローカライゼーションを検討。 圧縮された長いコピーではなく短いコピーを執筆。テキスト拡張とRTL言語を考慮。

---

ライティング工芸

コピーを締める実用的な編集の動き。声とトーンが正しいことを確認した後に適用。

埋め込み単語を削除

インターフェーステキストは最小ワード数を持たない。すべての単語がその場所を獲得する必要がある。しかし単語を切る前に、それが声の仕事をしているかチェック。一般的な工芸ルールによる「埋め込み」かもしれない単語は声のために負荷がかかる — 「まだ」は「Nothing here yet」で運ぶ温かさと落ち着き、削除するとより空の状態がぶっきらぼう。テスト： 単語を削除；意味もまたは意図的なトーンも変わらなければ、それを切る。

• 副詞/形容詞：「Simply enter your license plate」 → 「Enter your license plate。」 「simply」「quickly」「easily」「just」「successfully」のような単語はしばしば保証できないことを約束する。本当に明確にする単語を保持（「Feed your pets automatically」）。
• 感動詞：「Oops!」「Uh oh!」エラーの問題を軽視。削除。
• 社交辞令：「Sorry」と「please」は自動メッセージで不誠実に聞こえる。本当に温かさを加えるときだけ使用。
• 句読点：
  • 感嘆符：稀。本当に祝賀のモーメントのために予約。
  • ダッシュ（エン/エム）：インターフェースコピーで回避。スキャンを中断。代わりに別の行または文に分割。
  • 省略記号：プロセスが進行中のときだけ（「Loading...」）、後続する考えではなく。

繰り返しを回避

重なるアイデアを1つの明確なステートメントに合わせる。スクリーン上のすべての要素は新しい情報を追加すべき。見出しと本文が異なる言葉で同じことを言うときは、それらを折りたたむ。

「We're running late. Your delivery driver won't make it on time. They'll be there in 10 minutes.」 → 「Delivery delayed 10 minutes. Check the app for your driver's location.」

具体的に、曖昧でなく

• 事柄を名前付け：「Can't open 'Quarterly Report.pdf'」ではなく「Can't open this file。」
• アクションを名前付け：「Cancel Subscription」/「Keep Subscription」ではなく「Yes」/「No。」
• 実情報を与える：「Your card ending in 4242 was declined」ではなく「There was a payment error。」

用語リストを保持

何を呼ぶかを決定し、それに固執。あるスクリーンで「alias」なら、別のスクリーンで「username」を使用しない。用語リストはシンプルなテーブル：使用 / 使用しない / 定義。ボタンラベルは特に良いエントリ — 「Next」がフローを通じて進む場合、どこでも「Next」を使用。

代名詞と視点

「Favorites」は「Your Favorites」と同じメッセージを伝える。「we」を回避 — それは実際に何が起こったかを曖昧にする（「We're having trouble...」 → 「Unable to load content」）。

詳細に汗をかく

正しいスペル、文法、句読点は信頼を構築。声と整列する大文字使用ルール（タイトルケース = フォーマル、文ケース = カジュアル）を採用し、一貫して適用。利用可能なスペースのために執筆 — コピーが短い必要があれば、短い文を書く、長いものを圧縮しない。

ダイナミックコンテンツ向けに執筆

テンプレート文字列（"${count} items selected"）はインターフェースコピーも。すべての可能な出力が自然に読むように書く：

• ゼロ、1、および多くを処理。 「No results,」「1 result,」「24 results」 — 「0 results found」を生成する単一のテンプレートでない。
• 実際の値と一緒に読む。 短いおよび長い名前、小さいおよび大きい数を置換。「Welcome back, Christopher-Montgomery!」はレイアウトを崩すかも；「3 seconds ago」および「2 days ago」は両方とも自然に読むべき。
• テンプレートをシンプルに保つ。 文字列が良く読むために複雑な枝分かれが必要なら、デザインは単一要素に多くを求めるかもしれない。

言語パターンを構築

共通のモーメント用パターンを定義 — フローがどのように始まるか（「Get Started」）、進む（「Next」または「Continue」 — 1つ選ぶ）、終わるか（「Done」）。一貫して使用。

---

最もシンプルなテスト

あなたの執筆を声に出して読む。友人に何かを説明する方法のように聞こえたら — 明確、自然、埋め込みなし — それはおそらく良い。ロボット、法的文書、またはエッセイのように聞こえたら、改良を続ける。

---

パターン参照

アラート、エラー、空の状態、オンボーディング、通知、アクセシビリティラベル、破壊的なアクション、ボタン、および指導コピーに対する詳細なガイダンス — references/patterns.md を参照。