# UXライティング チートシート 「場面 → 行動 → 根拠（章・節）」で、迷ったときにすぐ引ける形にまとめた早見表。 ## UI文言・マイクロコピー | 場面 | 行動 | 根拠（章・節） | | --- | --- | --- | | 会員登録・開始ボタンの文言を決める | 提供者視点（「新規会員登録はこちら」）ではなくユーザー視点（「今すぐ始める」）で書く | 第1章 | | 通知の許可を求める | 許可するメリットを具体的な数字で示す（例:「学習継続率 約1.7倍UP」） | 第1章 | | サポート・ヘルプ画面を書く | 堅苦しい表現でなく「こんにちは！なにかお困りですか？」のようなフレンドリーな呼びかけにする | 第1章 | | インストール・登録などの操作ボタンを書く | ユーザーの慣れ度に応じて言い換える（アプリに不慣れなら「インストール」→「使い始める」） | 第2章（3.5） | | 入力欄で何を入れればいいかユーザーが迷う | 入力欄自体にプレースホルダーで具体例を示す（例: `******@gmail.com`、`***-****-****`） | 第4章（4.5） | | Googleアカウント等の抽象的なラベルだけでは伝わらない | ラベルではなく入力形式そのものを例示する | 第4章（4.5） | ## 文章の書き方 | 場面 | 行動 | 根拠（章・節） | | --- | --- | --- | | 1文が長く複数の内容を詰め込んでいる（盛りだくさん文） | 箇条書きに分解し、1箇条書き＝1文にする。50字を超えたら要チェック | 第4章（4.1） | | 主語の前に長い修飾語句がついて構造が複雑 | 修飾語句を独立させて別の文に分ける | 第4章（4.1） | | コンピューター特有・ビジネス文書特有の硬い表現になっている | 「メール配信が行われる」→「メールが届く」のように日常会話の表現に置き換える | 第4章（4.2） | | 読み手のイメージが曖昧なまま書き始めている | ペルソナシートの似顔絵に向かって語りかけるように書く | 第4章（4.2）、第3章（3.3） | | 表現を機械的に統一しようとして不自然になる | ユーザーの実際の操作感覚・日常感覚に合わせて表現を変える（「指定する」→「選ぶ」） | 第4章（4.3） | | 用語の定義だけで説明が終わっている | 「ユーザーが何をできるようになるのか」「あなたにとってどんなよいことがあるのか」を先に書く | 第4章（4.3） | | 敬語を多用して文が長くまどろっこしい | 読み手（ユーザー/社外/社内）・親しさ・状況（緊急性・困っている程度・感情）で丁寧さの加減を判断する | 第4章（4.4） | | 専門用語をそのまま使うか言い換えるか迷う | 頻出語は初出時に定義、単発語は普通表現に置き換え、抽象語は比較・例示・語源説明を添える | 第4章（4.7） | | 自動翻訳にかける前提で書く | 「が」による順接/逆接の曖昧さを避け、文を分けて「その結果」等の明示的な接続表現を使う。所有/著作など複数解釈できる表現も避ける | 第4章（4.8） | | 公的・専門的な言い回しが読み手にそぐわない | 「未就学児」→「まだ小学校に通っていないお子さん」のように身近な文脈に言い換える | 第4章（4.8演習） | ## UXプロセス・調査 | 場面 | 行動 | 根拠（章・節） | | --- | --- | --- | | いきなり文言を考え始めようとしている | 調査・分析→コンセプト→プロトタイプ→評価→提供の7段階プロセスを踏んでから書く | 第3章（3.1） | | ユーザーの利用実態がわからない | 実際の利用場所で行動観察し、時間がかかる作業・とまどう操作を記録する | 第3章（3.2） | | インタビューの質問設計に迷う | 答えやすいクローズド質問から入り、深掘りはオープン質問（なぜ？どのように？）で聞く | 第3章（3.2） | | 複数ユーザーから隠れたニーズを引き出したい | グループインタビューやワークショップを実施し、中立的なファシリテーターを置く | 第3章（3.2） | | チームでユーザー像の認識がバラバラ | 全員でペルソナシート（名前・プロフィール・行動特徴・ニーズ不満）を作成し1人の像に合成する | 第3章（3.3） | | ユーザーの行動の流れ・離脱ポイントを可視化したい | ジャーニーマップ（プロセス・タッチポイント・行動・思考・感情）をAS-IS→TO-BEで作る | 第3章（3.4） | | プロトタイプをどこまで作り込むか決められない | 目的・日数・費用の3要素で、ストーリーボード/ワイヤーフレーム/動くプロトタイプ/ペーパープロトタイプを使い分ける | 第3章（3.5） | | 非専門家（現場のユーザー）と一緒にシステムを作る | 現場に行き、スケッチとサインペンで課題を「引き出す」姿勢で臨み、既存のワークフローに溶け込む提案にとどめる | 第2章（マリンIT事例） | | 限られた人員・時間で情報発信しなければならない | ユーザーの「心の声」を書き出して絞り込み、概要→具体的手順の順に段階的に出す | 第2章（オンライン授業移行事例） | ## エラー・トラブル対応 | 場面 | 行動 | 根拠（章・節） | | --- | --- | --- | | 容量オーバーなどのエラーを通知する | 原因の提示だけで終わらせず、具体的な対処法（zip圧縮、クラウド利用等）まで書く | 第4章（4.6） | | 利用停止などユーザーを不安にさせる通知を書く | 原因・状況（データは保持される等）・対処法（再開方法）の3点をセットで伝える | 第4章（4.6） | | ウイルス疑いなどより重大な失敗を伝える | 「〜という状況ならまだ大丈夫です」と読み手を落ち着かせる一言を添える | 第4章（4.6） | | ユーザーからのクレーム・問い合わせに対応する | 「知識不足」「誤操作したはず」と決めつけず、相手の意見・感情をまず理解しようとする（アサーティブネス） | コラム（第2章） | | 制度・行政系の申請案内がわかりにくいと言われる | 前提条件（必要なもの・所要期間）を※印の後出しにせず、最初に明示する | コラム（第3章、電子申請事例） | ## 効果検証・改善運用 | 場面 | 行動 | 根拠（章・節） | | --- | --- | --- | | アンケートの質問を作り始める前に迷う | 「問題点→改善内容→目的→知りたいこと（疑問文）」の順で目的を具体化してから設問化する | 第5章（5.1） | | アンケートの選択肢設計に迷う | 1質問1事柄にし、選択肢の言葉の距離感をそろえる。揃えにくければ両端ラベルの数値目盛りにする | 第5章（5.1） | | アンケート結果の分析が単純集計で終わっている | 属性（年代等）とのクロス集計を行い、隠れた傾向差を確認する。自由記述はラベル付けして定量化する | 第5章（5.2） | | どちらのデザイン案が効果的か検証したい | A/Bテストで比較要素を1つに絞り、運用段階の改善に使う | 第5章（5.3） | | A/Bテストで数値差は出たが理由がわからない | インタビューなど定性評価を追加して「なぜ選ばれたか」を補う | 第5章（5.3） | | レビューを完成版になってから初めて行っている | 企画・設計・制作の各段階でレビューを挟み、手戻りを防ぐ | 第5章（5.4） | | 複数人でテキストを書いて表記がバラつく | 使う/使わないことばの用語集と、語・文・構成・形式ごとのチェックリストを整備する | 第5章（5.4） | | 経営層がUXライティングにピンとこない | 経営者に理解してもらえることばでデザインの効果を説明する | 第5章（5.5） | | 1人だけでUXライティングを始めたい | 社内の小さな業務改善から、7プロセスの縮小版（観察・ペルソナ・プロトタイプ・評価）を1人で回す | 第5章（コラム） |