わかる言葉で書く (Plain Language)

「エラーコード：0x80070005」「操作を実行するには適切な権限が必要です」「リクエストを処理できませんでした」——これらのメッセージを見たユーザーは何をすればいいかわかりますか？

UIのテキストは、開発者やデザイナーが書きます。しかし読むのはユーザーです。この当たり前のことが、実務では驚くほど忘れられます。システムの内部用語がそのままボタンラベルになり、エラーメッセージはエンジニアのデバッグ用文言がそのまま表示され、ヘルプテキストは法務部が書いた難解な文章になる——これがUIのテキストが「わからない」状態です。

よくある失敗は「正確に書こうとして難しくなる」ことです。正確さと平易さは両立できます。「認証情報が無効です」より「メールアドレスかパスワードが間違っています」の方が、正確で、かつわかりやすい。

1. 原則の定義

UIのすべてのテキスト（ラベル・エラー・ヘルプ・ボタン）を、ターゲットユーザーが日常的に使う言葉で書き、理解のための認知コストをゼロに近づける設計。

本質は「書き手の言葉ではなく、読み手の言葉で書くこと」です。専門用語・社内用語・システム用語は、書き手にとっては正確で効率的ですが、ユーザーにとっては「翻訳が必要な外国語」です。この翻訳コストが認知負荷となり、ユーザーのタスク完了を妨げます。

2. いつ使うか（適用場面）

特に重要になるケース

• エラーメッセージ: ユーザーが最も混乱しているタイミング。「何が起きたか」「なぜ起きたか」「どうすれば解決できるか」を平易な言葉で伝える必要がある。
• ボタン・CTA: 「送信」「実行」「OK」などの汎用ラベルは、ユーザーに「押したら何が起きるか」を想像させる認知コストを生む。「アカウントを作成する」「無料で始める」など、動作と結果が明確なラベルにする。
• オンボーディング・空状態: 初めて使うユーザーへの説明。専門用語が1つでも入ると、その時点で理解が止まる。
• フォームのラベル・ヘルプテキスト: 「氏名（フリガナ）」「半角英数字8〜16文字」など、入力規則の説明。ユーザーの言葉で書かないと入力ミスが増える。

トレードオフが起きる場面

• 専門家向けプロダクト: 医師・弁護士・エンジニア向けのツールでは、専門用語を使う方が正確で効率的な場合がある。ターゲットユーザーの語彙レベルに合わせる。
• 法的・規約テキスト: 法的な正確性が求められる文章は、平易さより正確さを優先せざるを得ない場合がある。ただし「要約」を平易な言葉で添えることは可能。

3. なぜ重要か（設計判断の核）

UIのテキストは「情報を伝える」のではなく、「ユーザーを次の行動へ導く」ために存在する。

設計判断の基準

• 「このテキストを読んだユーザーは、次に何をすべきかが即座にわかるか？」→ Noなら書き直す。
• 「このテキストに、ユーザーが日常生活で使わない言葉が含まれているか？」→ Yesなら平易な言葉に置き換える。

優先順位の考え方

• 1. 明確さ（最優先）: 短くても意味が伝わること。「送信」より「メッセージを送る」。
• 2. 行動の明示: ボタンは「動詞＋目的語」で書く。「OK」ではなく「削除する」「保存する」。
• 3. 共感のトーン: エラー時は責める言葉を避け、解決策を示す。「無効な入力です」ではなく「メールアドレスの形式を確認してください」。

例外条件

• アイコンのみのボタン（ハンバーガーメニュー、検索アイコンなど）は、広く普及したパターンであれば言葉がなくても伝わる。ただし初回利用時はツールチップやラベルを表示する。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、ユーザーはUIの意味を理解できません。

エラーメッセージに解決策があるか: エラーが表示された時、「何が問題か」と「どうすれば解決できるか」が平易な言葉で書かれているか？エラーコードや技術的な文言だけになっていないか？
ボタンラベルが動作を表しているか: 「OK」「はい」「送信」などの汎用ラベルではなく、「〇〇を削除する」「アカウントを作成する」など、押した後に何が起きるかが明確なラベルになっているか？
専門用語・社内用語が排除されているか: ユーザーが日常的に使わない技術用語・社内略語・システム用語がUIテキストに含まれていないか？含まれている場合、ユーザーの言葉に置き換えられているか？

理想ライン（Better - できると強い/プロの品質）

テキストが「ガイド」として機能している状態です。

ヘルプテキストが予防的か: エラーが起きる前に、入力規則や注意点をフィールドの近くに表示しているか？（例：「パスワードは8文字以上、英数字を含む」をエラー後ではなく入力前に表示）
トーンがブランドと一致しているか: 親しみやすいブランドなら「メールアドレスを確認してください」ではなく「メールアドレスをもう一度確認してみてください」など、ブランドの声のトーンが一貫しているか？
空状態・ゼロ状態のテキストが行動を促しているか: データがない画面（空のリスト、検索結果ゼロ）で、「データがありません」ではなく「まだ〇〇がありません。〇〇してみましょう」など、次のアクションを示しているか？

5. UI例

同じ状況でも、テキストの書き方でユーザーの感じる「わかりやすさ」と「次の行動への明確さ」が大きく変わります。

改善プロセス

1. ユーザーテスト（5秒ルール）: テキストを5秒見せて「次に何をすればいいか」を答えてもらう。答えられなければ書き直す。
2. 専門用語リストの作成: UIに使われている専門用語・社内用語を洗い出し、ユーザーの言葉への置き換え辞書を作る。
3. 声に出して読む: 書いたテキストを声に出して読む。不自然に感じる箇所は、ユーザーにとっても不自然。

6. 関連リンク

• 関連リファレンス（理論）: 認知負荷
• 用語集（定義）: 可読性
• 関連するUI原則（横）: スキャンしやすさ (Scannability), フィードバック (Feedback)

7. まとめ

今日から直せる一手 今担当しているUIのエラーメッセージを1つ開いてください。「何が問題か」「どうすれば解決できるか」がユーザーの言葉で書かれているか確認し、技術的な文言が含まれていたら平易な言葉に書き直しましょう。

チームに共有するなら一言 「UIのテキストは、書き手の言葉ではなく、読み手の言葉で書く。ユーザーに翻訳させるコストは、すべて離脱リスクになる。」