03 ・ 体験と画面
UXライティング
画面の文言を、表示される条件と一緒に見直すガイドです。利用者が、何が起きたか、次に何をすればよいかを理解できる文にし、採用した表現と使い分けを記録して管理元へ反映します。
UXライティングの工程と判断
概要
UXライティングで扱うのは、ボタン、見出し、説明、エラー、完了など、操作の途中で読まれる文言です。ネーミング・コピーのガイドは名前や訴求の言葉を作り、印象と覚えやすさを扱います。UXライティングは機能の状態を正確に伝えることを優先し、UI画面のガイドが決めた置き場所と文字数の中で内容を決めます。
言い回しを考える前に、その文が何を伝えるのかを明らかにします。そのため最初の二つの工程は文言を書かずに調べ、工程03で案を作り、人が内容と言葉遣いを選びます。選んだ文言は画面に入れて読み、最後に表記ルールとしてまとめ、管理元へ反映する担当を決めます。
向いている場面
- 機能の変更で、状態や表示条件が増えたとき
- 操作の誤りや問い合わせが、文言の分かりにくさから起きていそうなとき
- 呼び名や言い方が、画面ごとに揃っていないとき
このガイドで扱わないこと
- 名前や訴求の言葉そのもの。ネーミング・コピーのガイドで扱います。
- 文言の置き場所と、文字数の上限の決定。UI画面のガイドで扱います。
- 機能の仕様の決定。分からない点は、機能の責任者に確認します。
全体の流れと分担
工程は01から05へ進みます。工程03で人が内容と言葉遣いを選びます。仕様と文言を整理したあとは、初めて読む人の立場での確認を、確認担当に並行して任せられます。工程04で画面に入れて読み、伝わらない文言は工程03へ戻して案を作り直します。表示の規則を変える必要があれば、UI画面のガイドへ渡します。
工程ごとの分担
| 担い手 | 01文言と条件 | 02伝わりにくい箇所 | 03文言の案 | 04画面で読む | 05記録と反映 |
|---|---|---|---|---|---|
| 人 | 分からない表示条件を、機能の責任者に確認する | 判断：直す対象を選ぶ | 判断：内容と言葉遣いを選ぶ | 判断：全ての状態を読み、機能と説明が一致するか確かめる | 判断：記録を確定し、反映の担当を決め、読み戻す |
| AI | 文言と表示条件を一覧にする | 観点ごとに、伝わりにくい箇所の候補を挙げる | 内容の案と言葉遣いの案を分けて作る | 環境があれば、文言を入れた表示を作る | 記録を下書きする。環境があれば管理元へ反映する |
| 確認担当 | なし | 初めて読む人の立場で読み、分からない箇所を伝える（並行） | なし | なし | なし |
| デザイナー | なし | なし | なし | AIに編集の環境がなければ、文言を画面へ入れる | デザインファイルへ反映する |
| 開発担当者 | なし | なし | なし | なし | 文言の管理ファイルやコードへ反映する |
迷ったときの参照先
手元の状況に近いものから、該当する節を開いてください。
015工程のうち1
今の文言と表示条件を調べる
画面の文言を、表示される条件（いつ、どの状態で、誰に）と対にして一覧にし、各文が伝える内容を一文で書きます。
考え方
文言は単独で読むと正しく見えても、表示される状態と合わないことがあります。例えば「保存しました」が、保存の途中でも表示されている場合です。文言と表示条件を対にして並べると、このような食い違いが見つかります。
各文言には、伝える内容を一文で書きます。何が起きたか、利用者が次に何をすればよいか、の二点が基本です。あわせて画面ID、文中に入る変数（件数や名前など）、表示できる文字数の上限を記録します。これらは工程04で画面に入れて読むときと、工程05で反映するときに使います。
推奨と理由
文言ごとに、表示条件と伝える内容を書く
理由伝える内容が決まらないまま案を作ると、案の違いが言い回しの好みだけになり、選ぶ基準がなくなります。
仕様から分からない条件は空欄のまま残し、責任者に確認する
理由書き手やAIが条件を推測で埋めると、機能の実際の動きと違う説明が採用されます。
次へ進む目安
- 全ての文言に、表示条件がある
- 変数と文字数の上限が記録されている
- 分からない条件が、確認先とともに一覧になっている
具体例
写真のアップロード画面
説明のための架空の例です。写真を共有するアプリで、写真を選んで送る「アップロード」の画面と、その途中や結果に出る文言を見直します。以降の工程でも同じ例を使います。
- 一覧にした結果
- アップロード画面の文言14件を一覧にした。「処理中です」という文言が、写真を送っている間と、送った写真を変換している間の両方で表示されていることが分かった。
- 確認すること
- 変換にかかる条件は仕様に書かれていなかったため、人が開発の責任者に確認することにした。
025工程のうち2
伝わりにくい箇所を探す
文言一覧から、利用者が状況や次の行動を判断できない箇所を特定し、何が分からないのかを書きます。
考え方
候補を探す観点は五つです。誰が何をしたかが分からない、次の行動が書かれていない、社内の呼び名や専門用語が使われている、同じものに複数の呼び名がある、表示の状態と合わない、です。
仕様と文言の一覧がそろったあとは、初めて読む人の立場での確認を別の担当に任せられます。機能をよく知る人は、社内の呼び名を説明なしで理解できるため、分からない箇所に気づきにくくなります。
推奨と理由
社内の呼び名と利用者の呼び名を対照表にする
理由対照表があると、同じものを指す呼び名の揺れを一度に揃えられ、新しい文言を書くときにも同じ呼び名を選べます。
初めて読む人には、機能を説明せずに読んでもらう
理由説明を聞いたあとでは、文言だけで理解できるかどうかが分からなくなります。
次へ進む目安
- 直す箇所ごとに、何が分からないのかが一文で書かれている
- 呼び名の揺れが対照表にまとまり、揃える候補が書かれている
具体例
写真のアップロード画面
- 呼び名の揺れ
- 画面には「アセット」「写真」「ファイル」が混在していた。初めて読む人は、「アセット」が写真を指すと分からなかった。
- 状態と合わない文言
- 「失敗しました」は、写真のサイズが上限を超えたときと、通信が途切れたときの両方で表示され、理由も次の行動も書かれていなかった。二つの状態は、仕様で別々に判定されていることを確認した。
- 人の判断
- 呼び名の揺れと「失敗しました」の二つを直す対象に選んだ。
035工程のうち3
文言の案を作る
直す箇所ごとに案を作り、人が伝える内容と言葉遣いを選びます。
考え方
選ぶことは二つあります。一つは内容で、原因、次の行動、影響の範囲のうち何を伝えるかです。もう一つは言葉遣いで、丁寧さや語の選び方です。内容を先に決め、そのあとで言葉遣いを選びます。
判断の材料は、工程01で書いた伝える内容、文字数の上限、既存の表記ルール、仕様です。表示される状態と内容が一致し、次の行動が分かり、仕様にない時間や数値が入っておらず、既存の表記ルールと揃っている案を合格とします。同じ文言が複数の状態で表示されている場合は、状態ごとに伝える内容が同じかを先に確かめ、違えば状態ごとに文言を分けます。
推奨と理由
内容の案と言葉遣いの案を分けて比べる
理由一つの案の中で内容と言葉遣いが同時に変わると、どちらの違いで選んだのかを後で説明できず、似た文言を書くときに基準として使えません。
所要時間、成功の条件、原因は、仕様で確かめられる範囲だけ書く
理由推測で書いた「すぐに」「数秒で」は、条件の違う利用者に誤った期待を与え、問い合わせの原因になります。原因を書く場合も、その状態だと判定できているときに限ります。
次へ進む目安
- 表示される状態と、文言の内容が一致している
- 次の行動が必要な文言には、その行動が書かれている
- 仕様にない時間、数値、原因が含まれていない
- 文字数の上限に収まっている
具体例
写真のアップロード画面
- 状態の分け方
- 「失敗しました」は、仕様で別々に判定されているサイズ超過と通信の途切れの二つの状態に分けて文言を作ることにした。
- AIの案
- サイズの上限を超えたと判定された状態について、原因だけを伝える案、原因と次の行動を伝える案、次の行動だけを伝える案を作った。
- サイズ超過の文言
- 人は原因と次の行動を伝える案を選び、言葉遣いを整えて「写真を送れませんでした。1枚20MBまでです。サイズを小さくしてから、もう一度送ってください。」とした。1枚20MBまでという上限は仕様で確かめた値で、この文言はサイズの上限を超えた状態だけに表示する。
- 通信の途切れの文言
- 原因がサイズではないため、サイズを小さくする指示は含めず、「写真を送れませんでした。通信の状態を確かめてから、もう一度送ってください。」とした。
- 外した表現
- AIの案にあった「通常は数秒で完了します」は、仕様に根拠がないため外した。
045工程のうち4
画面に入れて読む
選んだ文言を実際の画面と状態に入れ、周りの文言と続けて読みます。
考え方
一文ずつは適切でも、見出し、説明、ボタンが同じことを繰り返したり、ボタンの言葉と押したあとの画面の見出しが違ったりすることがあります。画面に入れて、操作の順に続けて読みます。
読む対象には、データがないとき、エラー、完了の表示も含めます。変数を含む文は、最長、最短、0、1の値を入れて読みます。折り返しや省略の扱いを変える必要があれば、UI画面のガイドの表示の規則の変更として共有します。読んで伝わらない文言は、工程03へ戻して案を作り直します。
推奨と理由
ボタンの言葉と、押したあとの画面の見出しを続けて読む
理由二つの言葉が揃っていないと、利用者は押した操作が完了したのかを判断できません。
変数に最長、最短、0、1の値を入れて読む
理由件数が1のときの言い方や、長い名前が入ったときの折り返しは、仮の値だけでは確かめられません。
次へ進む目安
- 工程01の一覧にある全ての状態を、画面上で読んだ
- 変数の全ての値の例で、文が成立している
- 表示の規則の変更が必要な箇所が、UI画面の担当に共有されている
具体例
写真のアップロード画面
- 言葉の揃え
- 「送る」ボタンを押すと、完了の画面に「アップロード完了」と表示されていた。言葉を揃えるため、見出しを「写真を送りました」に変えた。
- 変数の確認
- 「{n}枚の写真を送りました」は、1枚のときも自然に読めた。
- 表示の規則
- 長いファイル名が入ると、2行目に「ました」だけが残った。ファイル名を途中で省略する表示の規則を、UI画面の担当に共有した。
055工程のうち5
表記ルールと例をまとめる
採用した文言、使い分けの理由、呼び名の対照表を記録し、管理元へ反映して画面で読み戻します。
考え方
記録には、画面ID、表示条件、採用した文言、変数、文字数の上限、使い分けの理由、呼び名の対照表を含めます。使い分けの理由は、次に新しい文言を書く人が、似た状況で同じ判断をするために使います。
反映の前に、文言の管理元がどこかを確かめます。デザインファイル、文言の管理ファイル、コードのどれが元になっているかで、反映する担当が変わります。反映したあとは、管理元と画面の間で変換や省略が起きていないかを、画面で読み戻して確かめます。
推奨と理由
使い分けの理由を残す
理由理由が残っていないと、次に文言を足す人が似た状況で別の言い方を作り、工程02で揃えた呼び名がまた揺れます。
反映後に、画面で読み戻す
理由管理元に正しく書いても、変数の置き換えや表示の省略で、画面に出る文が変わることがあります。
次へ進む目安
- 採用した全ての文言に、反映先と反映の担当がある
- 呼び名の対照表が、表記ルールに加わっている
- 反映後の画面を読み戻し、文言一覧と一致している
具体例
写真のアップロード画面
- 呼び名
- 「写真」に統一し、「アセット」は社内の呼び名として対照表に残した。
- 表記ルール
- エラーの文言は「できなかったこと、理由、次の行動」の順で書き、理由は判定できた状態についてだけ書く型として加えた。
- 反映と読み戻し
- デザイナーがデザインファイルへ、開発担当者が文言の管理ファイルへ反映した。反映後、人がアップロード画面の全ての状態を読み戻した。
成果を渡す先
このガイドの成果や、作業の途中で見つかった課題は、次のガイドへ渡します。渡す内容をそろえておくと、受け取った側が文言の意図を推測せずに済みます。
| 渡す先 | 渡すもの | 渡す時点 |
|---|---|---|
| UI画面 | 変更が必要な画面IDと、文言の最長の例 | 工程04で、折り返しや省略などの表示の規則を変える必要があると分かったとき |
| デザインシステム・UIガイド | 表記ルールと呼び名の対照表 | 表記ルールを、部品の使い方とあわせてガイドに含めるとき |
| ネーミング・コピー | その名前が表示される画面と、機能の説明 | 機能やプランの名前、訴求の言葉そのものを決める必要があるとき |
| UXフロー | 次の行動を示せない状態と、その表示条件 | 文言を書く途中で、戻る先のない状態が見つかったとき |
このガイドへ戻るとき
機能の変更で状態や表示条件が増えたときは、工程01に戻り、変わった文言だけを調べ直します。UI画面のガイドで文字数の上限が変わったときは、工程04で該当する文言を画面に入れて読み直します。