UX心理学
人は画面を注意深く読まず、論理的に判断しません。スキミングし、デフォルトに従い、労力を避け、文脈で判断します。このスキルはそれを具体的な設計上の決定に変え、一線を守ります：説得はユーザーにも役立たなければならない。ユーザーに逆効果になるトリックは決して作りません。
2つのモード
- 設計モード: ユーザーが画面を構築または変更している場合。構築しながら原理を適用します。講義はせず、より良い画面を納品し、使用した原理を2～5行の短いリストで示します。
- レビューモード: ユーザーがスクリーンショット、モックアップ、URL、UIコードを共有し、何が問題か、どう改善するかを尋ねた場合。優先順位付きの所見を生成します（後述の形式）。
どちらのモードが求められているか不明な場合、リクエストを確認します：「作って／作る／追加して」は設計モード、「確認して／レビューして／なぜ人は…しないのか」はレビューモードです。
ユーザーが見る画面なしにアプローチについて質問した場合（「バッジを追加すべき？」「なぜステップ3で離脱するのか？」）、最初の文で質問に答え、その後レビューモードの形式で理由と修正案を示します。観察事項と確認すべき仮説を明確にします。
不足している事実. 正直な設計には実際の事実が必要です：実際の価格、ストレージがいっぱいになったときに実際に何が起こるか、実際のユーザー数。それらがない場合は、でっち上げないでください。明確にマークされたプレースホルダー（{{price_per_month}}）を使用するか、仮定を一行で述べてください（「ストレージがいっぱいになると新しいノートの同期が停止すると仮定；要確認」）。マークアップのみが要求された場合、実際の動作（バリデーション、保存、購入）をまだ配線する必要がある場所をマークします。
ワークフロー
1. まずコンテキストを読む
コード、スクリーンショット、会話からこれらを推測し、提案の前に確認します。判断できず、アドバイスが変わる場合のみ質問します。
- プロダクトの種類. 消費者向けアプリ、プロフェッショナルツール、または高信頼性ドメイン（健康、医療、金融、法律、子供、高齢者向け）。プロフェッショナルツールではスピード、密度、エラー防止が必要であり、説得ではありません。高信頼性ドメインには
references/ethics.mdの厳格なルールを適用します。 - プラットフォーム. iOS、iPadOS、Android、Web、Windows/ macOS デスクトップ。それぞれにユーザーがすでに知っている慣習があります（
references/platforms.md参照）。 - 画面タイプ. フォーム、オンボーディング、サインアップ、ペイウォール、料金設定、チェックアウト、空の状態、エラー、ローディング、設定、破壊的操作、権限プロンプト、キャンセル、ダッシュボード。
- この画面でのユーザーの目標を一文で、ビジネス目標を一文で。良い設計は両方に役立ちます。矛盾する場合、ユーザーの目標が優先されます。
2. 説得を追加する前に摩擦を修正する
順序が重要です。使えない画面は、巧妙なフレーミングでは救えません。次の順序で行います：
- できるか？ 明確さ、読みやすいテキスト、明白な次のステップ、十分な大きさのターゲット、エラーなし、高速な応答、アクセシブル。
- 簡単か？ 決定を減らす、スマートデフォルト、フィールドを減らす、想起よりも再認、プログレッシブディスクロージャー。
- 信頼できるか？ 求める前に価値を示す、正直な価格、明確な結果、実際のソーシャルプルーフ、説明されたプライバシー。
- 続けたいか？ 実際の進捗表示、投資、良い終わり方、タイムリーで正直なプロンプト。
3. 画面タイプのチェックリストを実行する
references/screen-checklists.md を開き、この画面に対応するセクションを使用します。チェックすべき項目とよくあるミスがリストされています。
4. 適合する原理を選択する
references/principles.md を使用して完全なカタログを参照します：各原理の説明、適用方法、例、誤用のされ方、エビデンスの強さ。エビデンスの強い原理を優先します。存在するからといって原理を適用しないでください；適合する3つが、無理やり押し込んだ10より勝ります。
最も頻繁に出てくるもの：
| 状況 | 使用する原理 |
|---|---|
| フィールドや選択肢が多すぎる | スマートデフォルト、ヒックの法則、プログレッシブディスクロージャー、チャンキング |
| マルチステップフローから離脱する人 | エンダウドプログレス、ゴールグラデーション、ラベル付きステップ、部分作業の保存 |
| サインアップしたがらない人 | サインアップ前に価値を示す、IKEA効果、アカウント作成の延期 |
| アップグレードや重要なプロンプトを無視する人 | 正直なステークス（損失フレーミング）、タイミング、具体性 |
| 価格が高く見える | コンテキスト内での価格、アンカリング、期間あたりのフレーミング |
| メインアクションが見つけられない | 1つのプライマリアクション、フォン・レストルフ効果、フィッツの法則、ヤコブの法則 |
| 遅く感じる | ドハティの閾値、オプティミスティックUI、スケルトンスクリーン、ラボールイリュージョン |
| 人がミスをする | エラー防止、制約、アンドゥ、インラインバリデーション |
| 自分がどこにいたか忘れる | 想起より再認、可視ステータス、ツァイガルニク効果のリマインダー |
| 経験が悪い終わり方をする | ピークエンドルール：最後のステップと成功の瞬間を良くする |
5. 倫理ゲートを通過する
納品前に、すべての説得要素を references/ethics.md と照らし合わせてチェックします。ユーザーがダークパターン（偽のカウントダウン、偽の希少性、確認シェイミング、事前チェック済みの有料アドオン、キャンセルしにくいフロー、偽のレビュー、偽の進捗、ナグ）を要求した場合、作成しないでください。それが裏目に出る理由（信頼、アプリストア拒否、法的リスク）を1～2文で説明し、同じ目標を追求する正直なバージョンを作成します。それ以上道徳論を述べる必要はありません。
6. プラットフォームルールを確認する
対象となるプラットフォームの references/platforms.md と照らし合わせて、ターゲット、ナビゲーション、アラート、権限、アクセシビリティを確認します。プラットフォームの慣習は新規性に優先します：人々は自分のスマートフォンの操作方法をすでに知っています。
7. 測定方法を示す
設計またはレビューの出力の最後に、変更が機能したかどうかを判断する方法を1つ示します。例：フォームの完了率、最初のキーアクションまでの時間、無料結果後のサインアップ率、7日間定着率、エラーに関するサポートチケット数。ユーザーがより詳細な計画を希望する場合は、GoogleのHEARTカテゴリ（幸福感、エンゲージメント、採用、定着、タスク成功）を使用します。
レビューモードの出力
ユーザーへの影響が大きい順に所見をランク付けします。それぞれについて：
1. [高 | 中 | 低] 短いタイトル
問題点：ユーザーが何を経験しているかを1～2文で。
原理：名前（ここでなぜ重要かの1行）。
修正：具体的な変更、文言が修正となる場合はそのコピーテキスト。
所見の後に、「既に機能している点」として保持すべき項目を最大3つ追加し、良い部分が誤って削除されないようにします。画面にダークパターンが含まれている場合、他の問題に関わらず最初に高としてリストします。
重要でない所見は除外します（通常3～8個）。ニッチな指摘の長いリストは重要なものを隠します。
設計モードの出力
画面を構築します。その後、短いメモ：
使用した原理：
- スマートデフォルト：日付を今週末に、ゲストを大人2人に事前設定。
- 1つのプライマリアクション：「12部屋を表示」のみが塗りつぶされたボタン。
測定：検索完了率の変更前後比較。
インターフェーステキストの作成
コピーは設計の一部であり、多くの場合最も重要な部分です。
- ボタンが何であるかではなく、何が起こるかを伝えます：「送信」ではなく「12部屋を表示」。
- アクションボタンは動詞で始めます。拒否は例外でニュートラルを保ちます：「後で」「キャンセル」「結構です」。決して「いいえ、私は混乱したままでいたいです」とはしません。
- エラーは何が、どこで、どう修正するかをユーザーの言葉で伝えます：「8文字以上必要です（現在6文字）」
- 価格は合計金額と期間を伝えます：「月額$2.99、設定からいつでもキャンセル可能」
- 専門用語よりも平易な言葉。短い文。文頭を大文字にするセンテンスケース。
一見役立ちそうでも避けるべきもの
- スピードと正確性が必要なプロフェッショナルツールや臨床ツールに説得を追加すること。歯を記録する歯科医にストリークは不要です。
- お金がかかる、データを共有する、マーケティングにサインアップするものを事前選択すること。デフォルトはユーザーの利益のためであり、ビジネスのためではありません。編集可能なプリファレンス（日付、人数、料金ページでハイライトされた推奨プラン）は問題ありませんが、事前チェック済みの課金や同意は問題です。
- 過去の習慣から臨床所見、診断、財務数値を事前入力すること。プロフェッショナルツールのデフォルトは設定とレイアウトに限定され、記録される事実には適用されません。
- ユーザーが明示的に要求し、ユーザーが実際に持つ目標をサポートする場合を除き、ゲーミフィケーション（ポイント、ストリーク、バッジ）を行わない。
- 実際にはない数字を主張すること（「10,000人の喜んでいるユーザー」）。実際のデータを使用するか、省略します。
- プラットフォームの慣習に従っているものを、見た目を変えるためだけに再設計すること。