WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Make a big impact with small writing changes

Make a big impact with small writing changes

Design
元の動画を見る

ハイライト

Apple の UX Writer である Liv と Jennifer が、文案を最適化するための 4 つのアクションを提示します。無駄な言葉を削る、重複を排除する、メリットを前に出す、用語リストを作成する。

主要内容

海外出張中にレンタカーを借りて有料駐車場に停めたときの話です。支払い用の app を開くと、“Simply enter your license plate number to quickly pay for parking” という文言が表示されました。問題は、レンタカーのナンバープレートを把握していないことでした。車に戻って確認し、出口付近で圏内を探して app をダウンロードする必要がありました。この文案の “simply” や “quickly” は役に立たないだけでなく、かえって製品に不誠実な印象を与えています。

Liv Huntley と Jennifer Bush は Apple の UX Writer です。彼女たちはこのセッションでシンプルな原則を提示しています。app に最低文字数の要件はないので、書くべき内容は最小限にすべきです。Apple の新しいデザインシステムがクロスプラットフォームで展開されている今、app 内の文案を見直す絶好の機会です（00:20）。彼女たちが提示する 4 つの具体的な改善アクションは以下の通りです。無駄な言葉の削除（fillers）、重複の排除（repetition）、メリットの前置き（lead with the why）、用語リストの作成（word list）。いずれもアーキテクチャの再構築は不要で、1〜2時間程度で一通り対応できます。

詳細

無駄な言葉を削る（01:15）。Liv は 4 種類の一般的な無駄な言葉を列挙しています。副詞（easily、quickly）、形容詞（fast、simple）、感嘆詞（uh oh、oops、hooray）、定型表現（sorry、please、thank you）。判断基準はシンプルです。その言葉を削除しても意味が損なわれないかどうかです。駐車場 app の例から “simply” と “quickly” を削除すると “Enter your license plate number to pay for parking.” になりますが、情報量は変わりません（02:48）。

  • キーポイント：説明のための形容詞をデフォルトの装飾として扱わないこと。
  • キーポイント：例外は、形容詞が重要な機能情報を担っている場合です。ペット用給餌器 app の “Feed your pets automatically when you’re away” における automatically は「スケジュールに基づいて自動的に給餌する」という核心的な機能を説明しているため、削除できません（03:14）。
  • キーポイント：エラーメッセージ内の “uh oh”、“oops”、“oh no” は製品を問題に真剣に取り組んでいない印象にさせます。プッシュ通知の “We’re sorry”、“10 short minutes!” は謝罪と感嘆符を穴埋めとして使っており、主情報を希薄化しています（04:35）。

重複を排除する（06:11）。重複とは同じことを二度言うだけではありません。三通りの表現で同一の事象を伝えることも含みます。配達遅延の通知が原文でした。タイトルが “We’re running late”、本文が “Your delivery driver won’t make it on time”、その後に “in 10 minutes” と続きます——これら三か所で「遅れている」ことを伝えています。Liv はこれを “Delivery delayed 10 minutes.” に統合しました。一つの文で「遅延」と「どの程度」を同時に明確に伝えています（06:43）。

  • キーポイント：UX writing の本質は economy of language（言語の経済性）であり、空白を埋める必要はありません。
  • キーポイント：統合の判断基準は情報量です。新しい文と古い文の情報量が同等であれば、新しい文を採用します。

メリットを前に出す（07:13）。Jennifer が提示する公式は “To [メリットを得る], do [何かをする]” です。Apple News+ Puzzles の通知 “Keep your streak going by solving today’s crossword” が効果的なのは、why（連勝を維持する）が冒頭に置かれているからです（07:38）。レストラン app の例はより直接的です。原文 “Enter your phone number to get reservation updates” を “To get reservation updates, enter your phone number.” に変更します。文字数は同じですが、読者が最初に目にするのはメリットです（08:57）。

  • キーポイント：適用シーンはエラー通知、プッシュ通知、操作ガイドなど、ユーザーアクションを促す文案です。
  • キーポイント：通知を見たユーザーの第一反応は「これと自分の関係は？」であるため、その答えを前に出します。

用語リストを作成する（09:23）。これは app 外で実施する唯一のアクションです。Jennifer が推奨するフォーマットは 3 列のテーブルです。使用する用語 / 使用しない用語 / 定義。ゲーム内でプレイヤーのニックネームは alias と統一し、handle、user name、title は使いません。プレイヤーのライフは health と統一し、lives、hearts、energy、stamina は使いません（10:45）。用語リストのメリットは、app 開発に関わるすべての人が参照でき、設定、検索、通知で文案が一貫性を保てることです。

  • キーポイント：一度に完全な用語リストを作成しようとせず、出会ったものから一つずつ追加します。
  • キーポイント：参考の起点は Apple Style Guide です。

最後に Liv が最も実用的な提案をします。書き上げたら音読してください。音読すると「書いているときは問題ないが、読んでみると冗長に聞こえる」言葉が聞き取れます。

重要ポイント

  • 何をするか：次回のリリース前に 1〜2 時間を確保し、文案の見直し専用の時間を設けます。

    • なぜ価値があるか：文案の最適化にはほとんど技術コストがありませんが、ユーザーの認知には非常に直接的に影響します。一つのアクションで、ユーザビリティ、ブランド感、エラー処理体験を同時に改善できます。
    • どう始めるか：app 内のすべてのユーザー向けテキスト（ボタン、空の状態、エラーメッセージ、プッシュ通知）を列挙し、4 つの原則を一つずつ適用します。

  • 何をするか：すべてのエラーメッセージから “oops”、“uh oh”、“sorry” を完全に削除します。

    • なぜ価値があるか：これらの言葉は製品がエラー時に敷衍している印象を与えます。何が起きたか、ユーザーがどうすべきかを直接伝える方が、かえって尊重されていると感じられます。
    • どう始めるか：コードリポジトリで “oops” / “Sorry” / “uh oh” を grep し、一つずつ書き換えます。

  • 何をするか：すべてのプッシュ通知を「メリット前置き」に変更します。

    • なぜ価値があるか：プッシュ通知はユーザーの注意力が最も浅いシーンであり、最初の 5 文字で開くかどうかが決まります。
    • どう始めるか：既存の “Do X to get Y” 形式の通知を一つ見つけ、“To get Y, do X” 構造に変更し、A/B テストで開封率を確認します。

  • 何をするか：製品用語リストを作成し、最も使用頻度の高い 5 つの用語から始めます。

    • なぜ価値があるか：用語の不一致は、ユーザーに製品が同じチームによって作られていない疑念を抱かせます。一貫性は安価な信頼です。
    • どう始めるか：共有ドキュメントを開き、「使用する / 使用しない / 定義」の 3 列を用意します。最初のバッチは alias / username / アバター / アカウント / 購読 など、混用されやすい用語から記載します。

関連セッション

コメント

GitHub Issues · utterances