ハイライト
Apple の UX Writer チームは、インターフェイスのコピーを作成する際の思考フレームワークを共有しました。コピーは単なるつなぎテキストではなく、製品エクスペリエンスの核となる部分です。コピーライティングのないアプリは、道路標識のない街のようなものです。
主要内容
インターフェイスがほぼ完成した時点で、多くのアプリのコピーライティングが追加されます。ボタンにはラベルが必要で、ポップアップ ウィンドウには説明が必要で、空の状態にはプロンプトが必要です。このようにして書かれた文章は、最終的なインターフェイスを説明するだけで、デザインには参加できないことがよくあります。
このセッションの要点は簡単です。インターフェイスのコピーライティングもデザインの一部です。 Apple の UX Writer は、これを言語のレンズを通してデザインすることと呼んでいます。これらは、目的、期待、文脈、共感という執筆の枠組みを与え、これらが合わせて PACE となります。
これは API セッションではないため、公式のコード スニペットはありません。以下では、コードの代わりに実行可能なコピーライティング チェックリストを使用します。これはコードと同じことを行います。つまり、抽象的な原則を、すべてのインターフェイスで段階的に検証できるルールに変換します。
Interface copy review
- Purpose: この画面でいちばん重要なことは何か?タイトルと主ボタンが先にそれを伝えているか?
- Anticipation: ユーザーがここを読んだとき、次に知りたがることは何か?
- Context: ユーザーはどんな状況でこのテキストを見ているか?中断されているか、急いでいるか?
- Empathy: 異なる言語、能力、背景のユーザーに理解できるか?
キーポイント:
Purpose: どのテキストを残すかを決める前に、画面の目的を定義する。Anticipation: アプリのコピーを会話として考え、ユーザーの次の質問に先回りして答える。Context: 表示タイミング、デバイスの状態、ユーザーの注意の向きに合わせて書く。Empathy: ローカライゼーション、アクセシビリティ、包括的な表現に配慮する。
詳細
目的: 各画面は主なタスクを 1 つだけ実行します
(03:12) 目的は画面が存在する理由です。 Apple は例として、メッセージの名前とアバター共有ガイド ページを使用しています。タイトルには直接「名前と写真を友達と共有」と表示され、ボタンには「名前と写真を選択」と表示されています。ユーザーはタイトルとボタンをざっと見ただけでも、その画面が何であるかを理解できます。
これにより、タイトルとメインボタンを先に書いてから本文を書くという実践的な書き方が生まれます。ユーザーは必ずしも画面全体を順番に読む必要はないからです。タイトルとボタンは、情報階層の中で最も重要な役割を果たします。
Purpose checklist
1. この画面の目的を一文で書く。
2. タイトルがその目的を表しているか確認する。
3. 主ボタンが次の操作を表しているか確認する。
4. 現在の目的と無関係な説明は削除、移動、または後回しにする。
キーポイント:
- 1 行目は、設計上の問題を 1 つの目標に凝縮し、1 つの画面で一度に多くのことを説明することを防ぎます。
- 2 行目では、ユーザーが一目見た情報が役立つかどうかを確認します。
- 3 行目では、ボタンが独立してアクションを表現できるかどうかを確認します。
- 4 行目は冗長な情報を処理します。 Apple は、iPhone の温度警告の例からあまりにも多くの理由を削除しました。
(04:13) 温度警告の反例には、内容が多すぎます。おそらく、太陽の下、アプリの使いすぎ、緊急通報などです。最終バージョンには、「温度」というタイトル、「iPhone を使用するには冷却する必要があります」という文、および「緊急」ボタンのみが残されました。すでに写真から温度の高さが伝わってきますので、改めて文章を書く必要はありません。
(05:59) 複数ステップのプロセスもこの方法で処理する必要があります。 Apple Cash の家族共有設定の各ステップには異なる目的があります。つまり、誰が Apple Cash を使用できるかについて説明し、次に本人確認が必要であること、次にアクティベーションに数分かかる場合があることと通知が送信されることについて説明します。各画面では、現在のステップの質問にのみ回答します。
期待: インターフェースのコピーライティングを対話として扱う
(07:40) 期待とは、ユーザーが現時点で何を尋ねるかを予想することです。時計アプリの目覚まし時計の例で、ユーザーが週末に目覚まし時計を一時的に変更する場合、ユーザーが最も懸念するのは「明日の目覚まし時計だけを変更するか、週末の計画全体を変更するか」です。アクション シートでは、「この変更をこのスケジュールのすべての週末に適用しますか?」と直接尋ねられ、最初のオプションは「次のアラームのみ変更する」です。
この例は、コピーライティングが単にボタンの機能を説明するだけではないことを示しています。ユーザーの最も一般的な意図を予測し、デフォルトのパスを明確に説明する必要があります。
Anticipation checklist
1. ユーザーは直前に何をしたか?
2. ユーザーが今いちばん心配していることは何か?
3. ユーザーが次に取れる操作は何か?
4. 最も一般的な操作がいちばん理解しやすいか?
キーポイント:
- 行 1 は、コピーライティングをトリガーした前のアクションを記録します。
- 行 2 は、コピーをシステムの観点からユーザーの観点に移します。
- 確認インターフェイスの 3 行目では、オプションのアクションを指定します。
- 4 行目では、デフォルトのオプションが現時点でのユーザーの真の意図と一致するかどうかを確認します。
(09:06) Apple は音声とトーンも区別しています。アプリのサウンドは安定している必要がありますが、シーンに応じてトーンが変化することがあります。 Apple Watch は転倒を検出すると、「激しく転んだようです」と「大丈夫です」と言って落ち着かせます。アクティビティが連続移動を記録する場合、そのトーンはお祝いの雰囲気になる可能性があるため、感嘆符が使用されます。
(10:31) 書くときは、「次は何が来るの?」と問い続けてください。 Breathe アプリは、「じっとして、呼吸に注意を向けてください」という言葉で始まり、続いて「さあ吸い込んで…」「そして吐き出してください」と続きます。コピー、ビジュアル、タッチを組み合わせて、「どうやって始めればよいですか?」という質問に答えます。
文脈: 同じ文を使用シーンの判断に戻す必要がある
(11:47) コンテキストでは、まずアプリの外部の環境について考える必要があります。ユーザーは静かな家にいるのか、それとも空港にいるのか?歩いたり、運転したり、料理をしたり、画面に全神経を集中できていますか?
Apple Watchのエクササイズリマインダーの例はその典型です。デバイスはユーザーが屋外を歩いていることを検出しましたが、ワークアウトは記録されませんでした。現時点では、ユーザーは運動中であり、長いコピーを読むのには適していないため、インターフェースには「屋外散歩を記録」という大きなボタンのみが表示されます。エクササイズが終了すると、ユーザーの注意はさらに集中し、インターフェースには距離、ペース、アクティブカロリーが表示されます。
Context checklist
1. テキストが表示されるとき、ユーザーは別のことをしているか?
2. これはリマインダー、確認、エラー、空状態のどれか?
3. ボタンだけ読んだとき、結果が分かるか?
4. エラーの場合、テキストは修正の入口を示しているか?
キーポイント:
- 行 1 はコピーの長さと情報密度を決定します。
- 行 2 は、さまざまなインターフェイス タイプを区別します。アラート、エラー、空ステータスは同じトーンを使用できません。
- サブスクリプションのキャンセルの 3 行目の例: ボタンは単に「はい」と「いいえ」を言うことはできません。
- 請求問題の例の 4 行目: エラー メッセージは次のステップを示すものです。
(12:56) アラートは中断です。天気予報アプリが位置情報の許可を要求すると、アプリを開いたときにポップアップが表示され、その位置情報が地域の天気や関連する通知に使用されることが説明されるため、コンテキストに応じたものになります。
(13:44) 破壊的な操作はより具体的にする必要があります。デバイスを削除する場合のアラートのタイトルは「iPhone を削除しますか?」です。ボタンは「削除」と「キャンセル」です。サブスクリプションをキャンセルする場合の反例には、「キャンセルを確認する」、「キャンセルする」、「確認する」のみが含まれます。ユーザーにとって、どのボタンが実際に購読を終了するのかを判断するのは困難です。 「プラチナサブスクリプションをキャンセルしますか?」「サブスクリプションをキャンセルします」「サブスクリプションを維持します」に変更すると、ボタンを見るだけで決定できるようになります。
(15:29) エラーメッセージは同じです。反例 「おっと! それはできません」とエラー コード、および「もう一度お試しください」では、何が起こったのかがユーザーに伝わりません。より良いバージョンには、請求に問題があることを示すタイトル、新しい支払い方法を追加するというテキストがあり、メイン ボタンは単に「支払い方法を追加」です。
(16:38) 空のステータスはユーザーを教育できます。レストランアプリの「何か気になるものはありませんか?」遊び心のある口調ですが、この慣用句は翻訳が難しい場合があり、コンテンツがどのように表示されるかを説明していません。 Apple Podcasts の「保存されたエピソードはありません」と「後で聞きたいエピソードを保存すると、ここに表示されます」はより明確です。
共感: さまざまな言語、能力、背景に合わせて書く
(18:02) 共感はすべての人に向けて書かれています。 Apple は、単純で平易な言葉を使用し、慣用句やユーモアは翻訳されず、一部のユーザーを排除する可能性があるため、注意することを推奨しています。
ここでの中心的な問題はローカリゼーションです。英語をタイ語、オランダ語、ヘブライ語に変更すると、長さ、縦のスペース、読む方向が変わります。すべての言語でカレンダー内の曜日が 1 文字で省略されているわけではありません。カタルーニャ語では 2 文字が使用され、アラビア語では省略されません。
Empathy checklist
1. この文は慣用句、スラング、社内用語に依存しているか?
2. テキストが長くなったとき、レイアウトに収まるか?
3. 右から左の言語でも、画面の順序は明確か?
4. VoiceOver で読んだとき、ユーザーは十分な情報を得られるか?
5. 不要な性別、身元、文化の前提はないか?
キーポイント:
- 行 1 翻訳と理解のコストを削減します。
- 行 2 は、テキストの延長や行の折り返しを可能にするデザインを思い出させます。
- 3 行目は、ヘブライ語、アラビア語などの右から左に記述する言語のシナリオをカバーしています。
- 行 4 は、あたかも完全なエクスペリエンスであるかのように、アクセシビリティ ラベルを記述します。
- 5 行目は、不必要な ID 仮定を持つユーザーの除外を回避します。
(20:10) アクセシブルなコピーライティングも設計する必要があります。 VoiceOver を使用するユーザーは、アプリを理解するために要素タグに完全に依存している可能性があります。 Apple はミー文字ステッカーを例に挙げています。説明には、体の動きだけでなく、「まるで秘密を共有しているかのように」瞑想し、神経質になった人が爪を噛むなど、意図やシーンも含まれます。また、性別を不必要に指定しないように、「person」を使用します。
最後のステップ: 読み上げます
(22:47) 適切な単語が見つからない場合の Apple の最後のヒントは、それを声に出して読み上げることです。読み上げて、コピーが日常会話のように聞こえるかどうかをチェックしたり、繰り返し、文法上の誤り、タイプミスを検出したりできます。
このアドバイスは非常に実践的です。インターフェイスのコピーライティングは通常非常に短く、短い文章の問題は設計草案では簡単に明らかになりません。声に出して読むと、ぎこちない、長すぎる、システム ログのような文章がより顕著になります。
重要ポイント
-
やるべきこと: 各オンボーディング ページに目的行を書く。 実行する価値がある理由: セッションでは、各画面には明確な目的が必要であり、タイトルとボタンが先にその目的を伝えるべきだと繰り返し強調している。 開始方法: デザイン案の横に「screen purpose」列を追加し、目的、タイトル、本文、ボタンの順で書く。
-
やるべきこと: アプリ内の破壊的アラートを書き直す。 実行する価値がある理由: 購読解除の例は、曖昧な「Cancel」「Confirm」「Yes」「No」ではユーザーが結果を判断できないことを示している。 開始方法: タイトルを具体的な対象と動作にし、ボタンを「Delete File」「Keep File」のように結果を単独で表せる文言にする。
-
やるべきこと: エラーメッセージに修復アクションを追加する。 実行する価値がある理由: 請求問題の例では、エラー説明と「Add Payment Method」入口を並べており、ユーザーが次を推測する必要がない。 開始方法: 頻出エラーを列挙し、「何が起きたか」「なぜユーザーに影響するか」「次のボタン」を固定チェック項目にする。
-
やるべきこと: ローカライズのストレステスト用コピー集を作る。 実行する価値がある理由: セッションでは、オランダ語の長文化、タイ語の縦方向スペース、ヘブライ語の RTL などの差が示されている。 開始方法: 長い文字列、2 行ボタン、RTL プレビュー、Dynamic Type で主要フローを確認する。
-
やるべきこと: VoiceOver ラベルの説明文を見直す。 実行する価値がある理由: Apple の Memoji 例では、動作、意図、状況を説明に含め、不要な性別前提を避けている。 開始方法: アイコン、画像、チャート、カスタムボタンの accessibility label を 1 つずつ確認し、単独で意味が伝わるかを確かめる。
関連セッション
- iOS のナビゲーション デザインを探索する — ユーザーがアプリ情報アーキテクチャを理解できるように、使い慣れたナビゲーション構造を使用する方法を説明します。
- アラビア語向けのデザイン - アラビア語のシーンから始めて、ローカリゼーション、読み方、文化適応の詳細を補足します。
- 効果的なチャートをデザインする — チャート情報が明確でアクセスしやすい方法で表現される方法に焦点を当てます。
- 拡張された San Francisco フォント ファミリの紹介 — フォント ファミリ、フォント幅、言語拡張の観点からインターフェイス テキストの視覚的表現を補足します。
コメント
GitHub Issues · utterances