体験設計(UX)の規律 — 「安心してポチポチ」を仕組みにする

実開発(物件マッチング台帳ほか)の発注者フィードバックから抽出した、どのアプリにも移植できる体験設計のルール集。

核となる方法論: 体験の理想を感情の言葉で定義し(「安心してポチポチ押せる」「認知負荷を減らしながら」)、それを満たす仕組みを逆算する。 感情語は一見矛盾を含む(楽に・でも安全に)。その矛盾を両立させる構造を作るのがUX設計の仕事。

本書は中核ルールと判断基準だけを載せる。入力フォーム・一括操作・行動科学の対応表など実装の具体パターンは references/ に分割してある(索引は末尾の §15)。該当する作業に入る前に必ず開く。

0. 設計を始める前に内部で確定する3点

1. 最頻シナリオは何か(1日◯回・一度に◯件) — 体験はこの現実の量を前提に設計する。
2. 絶対に起きてはいけないミスは何か(重複・誤送信・データ汚染・情報漏れ) — 「注意」ではなく仕組みで防ぐ対象。
3. ユーザーがアプリを閉じる瞬間、何と感じていれば成功か — 感情語で書く。これが検収基準になる。

この3点は依頼者への質問票ではない。依頼文・既存画面・データ量・操作ログ・業務資料から推定し、推奨案を1つに絞って代表画面または動くフローへ反映する。業務の「理屈」まで掘り、機能要望の裏にある業界ルールを設計ルールへ変換する。依頼者には成果物への差分だけを求める。

0-1. 業務構造を発見する(テンプレートから始めない)

AIっぽいUIは、UI部品の平均値を並べた画面。AIっぽくないUIは、業務の構造がそのまま画面の構造になっている。

「AIっぽさ」は制作手段ではなく、設計判断(何を最優先に見せるか・何を隠すか・何を隣に置くか・どこを固定するか・どの操作を一手で終わらせるか・エラー時にどこへ戻すか)が見えるかの問題。扱う対象を先に決めてから画面を考える。各問いは「はい/いいえ」で終わらせず、答えを1行の言葉にして残す(assets/structure-worksheet.md を複製して記入。言葉にできない項目は、まだ判断していないという合図)。

• この画面でユーザーが実際に手を動かして扱う**中心的な対象(名詞)**は何か(「案件」「注文」「申請」など、機能名ではなく業務上の名詞)。
• その対象を1日/1回の作業で何件・何回扱うか。件数や頻度で一覧向きか・単票向きか・比較向きかが変わる。数を把握せずに形式を決めていないか。
• 最頻の操作は何か。上位3つを具体的な動詞で言えるか(「確認する」ではなく「担当者を変更する」)。
• その最頻操作のうち、現状ページ遷移やモーダルを経由しないと完了しないものはどれか。一手で終わらせられないか検討したか。
• この画面の主役(最大の面積・最初に視線が行く場所)は「ユーザーが今から扱う対象」か。装飾的な集計や紹介文になっていないか。
• 数値やグラフを置くなら、それは次に取るべき行動に接続しているか(「見て終わり」の数字になっていないか)。

新規画面・リニューアルは必ずここから始め、既存画面を参考にする場合も参考先の構造を輸入せず、この画面の業務構造で問い直す。§2-3(主役と隠すもの)と §11-1(操作感)は並行して検討してよいが、この節の答え(中心対象・最頻操作)を先に確定させる。対象が定まらないまま装飾を判断しても軸がない。画面の型(一覧・単票・分析・操作感)による重心の違いは references/structure-diagnosis-by-domain.md。

1. デフォルト効果 — 最初から正解を選んでおく(最重要)

最初から選ばれている選択肢はそのまま採用されやすい。これを入力の手間削減に使う。

• 最頻パターンは選択済みで提示する(例: 条件フォームは「首都圏 × 一棟マンション」が選択済み、提案メールは優先物件がチェック済み)。
• 文脈から推定する: ユーザー・顧客の既知データからデフォルトを導く(名刺の住所 → 「地元(◯◯県)」を自動推定)。
• 賢いデフォルトの3条件: ①統計的または文脈的に最も確からしい ②いつでも変更できる ③何が選ばれているか見える。
• 安全の非対称: 時間節約系(絞り込み・並び順・よくある選択)はON がデフォルト。課金・送信・削除・公開に関わるものはOFF がデフォルト(安全側に倒す)。
• デフォルトの責任: そのまま Enter を連打されても壊れない・恥をかかない値であること。
• 誘導は正直に。事業者に都合のよいだけのデフォルト・confirmshaming・ダークパターンは禁止。

2. 認知負荷の最小化

前提: 画面は「表を書く」ところから始めない。 どの情報を消し・束ね・大きくし・加工し・どの器に載せるかを決める8工程(場面の1文 → ラベル剥がし → 伝わらないものだけ最小限に補う → グループ化 → 優先順位 → 表示用加工 → 表示形式の導出 → 機能と意味づけの装飾)を先に通す。手順は jp-web-design references/information-design.md(表示形式は事例から選ばず6判断軸で導出。前例のない要件は同 §9 の自己拡張手順で解く)。認知負荷の大半は、装飾ではなく情報の並べ方で決まる。

• 1画面1目的。判断は一度に1つ。複数の判断が必要ならステップに分ける。
• 選択肢は7個まで。多いときは2層にする: 「よくある選択肢のワンタッププリセット + その他(全リスト)」(例: エリア選択の最上段に「東京23区 / 首都圏 / 関西圏 / 地元」、その下に全国リスト)。
• 業界の肌感覚を単位にする(不動産は東京23区を「区単位」で考える等)。システム都合の分類で選ばせない。
• 段階的開示: 詳細・根拠・上級設定は折りたたみ。最初の画面は「次の1歩」だけを見せる。
• 認識 > 想起: 前回の選択・入力済みの値・履歴を見せて選ばせる。ゼロから思い出させない。

2-1. モバイルの情報削減(狭い画面では「縮小」ではなく「削減」)

SPで全情報を小さくして詰め込まない。削る優先順位を情報設計として決める:

1. 第一階層は原則3項目に絞る: 一覧の1行/1カードは「名前・キー数値・状態」まで。残りは詳細画面へ送る。突合・比較・入力で超過する方が早い場合は、場面と超過理由を標準の docs/product/T2-experience-spec.md(プロジェクトに同等責務の既存正本がある場合はその正本)に残し、表など一覧性の高い形式を選ぶ(テーブル→カード化の実装は jp-web-design references/layout-responsive.md §3)。
2. 第2階層はトグルで畳む: 根拠・履歴・上級設定は <details>/アコーディオン。開く前から「開けば何があるか」がラベルで分かること。
3. 上位N件+すべて見る: SPの一覧は要対応・直近の3〜5件だけ初期表示。
4. KPIは主要1〜3個: ダッシュボードの数字はSPでは意思決定に使うものだけ残す。
5. 何を削るかは「最頻シナリオ(§0)で使うか」で決める。使わない情報から畳む。飾りの統計は最初から置かない。

2-2. 現在地と退避先は常に見える(固定ヘッダー・固定フッター)

長い一覧を延々とスクロールしながら入力する画面では、いま自分がどこにいるか(ステップ・タブ・対象期間)と、どこへ退避できるか(保存・戻る・次へ)が常に見えていることが作業の安心感を決める。見えないと、利用者は保存できているか確かめるためだけに毎回スクロールで往復する。

1. 現在地は固定ヘッダーに、主要アクションは固定フッターに置く。スクロール量に関係なく到達できること。
2. 固定ヘッダー・固定フッターは共通レイアウト部品として1箇所に実装する。画面ごとに同じ position: sticky を書き散らさない(実装は jp-web-design references/layout-responsive.md §6)。
3. 縦幅の狭い環境で本文が潰れないこと、キーボード操作でフォーカスが固定要素の下に隠れないことを必ず実測する(Tabで最終行まで送って確認する)。
4. 該当する全画面にMECEに適用する。適用した画面/適用不要と判断した画面とその理由を残す(1画面だけ違う挙動になるのが最も混乱する)。

2-3. 何を主役にし、何を隠すか判断する

判断が見えるUIとは、要素の強さに差がある状態のこと。差がなければ、それは判断していないのと同じ。

• 画面内のすべての箱(カード・パネル・枠線)について、なぜその境界が必要かを言えるか。余白のグルーピングだけで意味が伝わるなら、枠は要らない。
• 角丸・影・色の強さといった装飾的な性質を、同じ画面内のすべての部品に均一に適用していないか。押せるもの・選択できるもの・状態を表すものに、意味の違いとして形の違いを与えているか。
• 視覚的な強さ(サイズ・コントラスト・余白・配置)を画面全体で一様にしていないか。すべてを目立たせると、何も目立たなくなる。
• 比較・走査・判断など、行うタスクの種類ごとに情報密度を変えたか(比較する場所は密に、確認・編集する場所は余白を多めに)。
• 頻繁に使う操作を、ホバーやメニューの奥に隠しすぎていないか。「見た目の静けさ」と「操作の発見可能性」を混同していないか。
• ラベルや見出しの文言は、この業務で実際に使われる言葉になっているか(抽象的な体験語ではなく、具体的な業務動作の言葉か)。

3. 楽さとミス防止はセット(片方だけで設計しない)

「楽に」とだけ設計すればデータが汚れ、「安全に」とだけ設計すれば面倒になる。必ず両方を同時に入れる。

楽にする仕掛け	対になるミス防止
実物からの自動抽出・プレフィル	自動入力は「(要確認)」ラベル付き、承認して確定
一括登録・一括処理	必須欠落は「要入力」ハイライトで対象から自動除外(揃った分だけ進む)
1クリック送信	送信前にその場で内容(文面・添付)を確認できる
自由入力の受け入れ(全角・カンマ)	入口で正規化、不正値はサーバー側でも拒否
重複チェックを意識させない	同一キー(メール等)の二重登録はサーバー側で拒否

• 摩擦の非対称性: 可逆で頻繁な操作=ゼロ摩擦。不可逆・対外的な操作(送信・削除・課金・公開)=意図的な摩擦1回(内容が見える確認)。確認を2回3回に増やさない — 形骸化する。
• ポカヨケ: 人の注意力に頼らず、そもそも間違えられない構造にする(不正データは入口で弾く、危険な組み合わせは選べなくする)。

4. 入力は「書かせる」より「確認させる」

• 実物(PDF・写真・名刺・CSV)を投げたら、抽出済み・記入済みの状態で提示する。人の仕事は入力ではなく確認と修正。
• 読み取れなかった項目は**空欄 + 「要入力」**で正直に示す。推測で勝手に埋めない(静かなデータ汚染が最悪)。
• 精度とコストは利用頻度・データ機微度・予算根拠から推奨値を1つ選び、初期値として実装する。課金開始や自動承認など本人の同意が必要な操作だけ、費用と成果物を見せて確認する。
• 必須項目は業務の生命線だけに絞る(連絡がつかなくなるメール等)。「あったら便利」を必須にしない。
• 全角→半角の自動正規化・カンマ許容・inputMode 指定。ユーザーの入力癖に合わせる(直させない)。

フォーム実装時に必ず開く詳細(下書き自動保存/IME・送信トリガ/動作とデザインの一致/自動計算値の扱い/一覧入力の視線移動)は references/input-patterns.md(§4-1〜4-5)。

5. 一括操作は「安心してポチポチ」の4点セット

1. 賢い事前選択 — 優先度の高い対象がチェック済み(§1)。
2. 実行前のその場確認 — 何が送られる/変わるのかを一覧・プレビューで見せる。
3. 実行は1クリック — 確認済みなら手数を増やさない。
4. 結果は項目ごとに表示 — 成功◯件・失敗◯件と、失敗した個々の理由。

• 部分成功の設計: 全滅させない。成功分は先へ進め、失敗分は「要確認」キューに隔離して後で個別対応できるようにする。
• 量に耐える: 「何十件」の現実量を前提に、待ち行列 + 進捗表示(「3/24件目を処理中」)。

一覧・アップローダ・自動化を実装するときに必ず開く詳細(一括選択の標準装備/複数ファイル並行処理/省略とチェックの両立)は references/bulk-operations.md(§5-1〜5-3)。

6. 正直なUI

• できなかったことを隠さない: 「13項目を自動入力しました(要確認)」「読み取れませんでした。手入力してください」。ここを誤魔化すと静かにデータが汚れる。
• 結果は説明可能に: マッチング・判定・集計は決定的なルール(フィルター・条件式)で行い、「なぜこの結果か」を言える状態にする。説明できないブラックボックスをAI任せで作らない。
• 無言の読み取り専用・無言の空表示を作らない: 編集できない一覧には「なぜ編集できないか」を1行で出す。値が空・ゼロで並ぶときは理由を1つ名指しし、解決する画面への導線を添える。理由のない灰色の画面は「不具合」として報告される(実装の落とし穴と検証方法は app-excellence references/data-lifecycle.md §2)。
• 自動処理には人間の確認経路を必ず残す(自動承認は明示的なオプトイン)。
• 費用・利用量が発生する機能は見える化する(誰が・いくら使ったかのダッシュボード)。
• 偽の数字・偽の緊急性・煽りは禁止。表示する数字はすべて実際の計算結果。

7. エラーは回復の起点

• エラー表示は「何が起きたか + 次に何をすればいいか」。ユーザーの入力は絶対に消さない。
• 「対応できません」で終わらせない。失敗した実物のファイル・データで原因を特定し、直し、その実物で成功するまで検証する。
• 一度直した問題は、その実物を自動テストに固定して再発を封じる。
• 復旧経路を用意する: 失敗した項目は再試行・手動入力・スキップのいずれかへ必ず進める(行き止まりを作らない)。

8. データのライフサイクル — 消さない

• 業務データは削除せずステータスで制御する(成約 → レコメンド対象から外すだけ)。過去の記録は将来の資産(売主は次の買主になる)。
• 削除機能を求められたら、まず非表示・アーカイブ・ステータス変更で満たす可逆案を実装または差分提示する。物理削除だけが要件を満たす場合に限り、対象・バックアップ・復元不可範囲を示して実行承認を得る。
• 原本(アップロードされたPDF・画像)は加工後も必ずストックする。抽出結果だけ残して原本を捨てない。
• 取り込んだ値を人の手修正で上書きしない(別枠で保持し、「取込値に戻す」を成立させる)。再取込のたびに手修正が消える設計は、消えたことにすら気づけない。定期取込・マスタ・締め処理がある案件は app-excellence references/data-lifecycle.md を併読する。

9. ホーム画面の情報設計

「何を最初に見せるか」は機能一覧からではなく、業務の1日から決める。

1. いま要対応のもの(要確認キュー・未処理・失敗) — 放置されると業務が止まるもの。
2. 次の主要アクション(登録する・作成する) — 最頻の入口を1タップで。
3. 最近の動き(直近の登録・更新) — 続きから再開できる。
4. キー数字(状況が一目で分かる集計) — 飾りの統計は置かない。

• タイトル・アプリ名・メニュー名は「いつ使うか」が分かる言葉にする(機能名より場面名)。

10. トレードオフは内部比較し、1案を実装する

コストvs品質、セキュリティvs手軽さのような判断は、目的適合・根拠・安全と可逆性・一貫性・複雑性で内部比較し、最有力の1案を実装する。

• 採用案、決め手、却下した主要案を各1行だけ判断記録へ残す。無難な折衷案にはしない。
• 可逆な選択は成果物を先に作り、利用者からは違う箇所だけを受け取る。
• 課金、公開、個人情報の取扱い、不可逆操作など本人しか決められない境界は、推奨と成果物/dry-runを先に示して1回だけ確認する。

11. 操作感と知覚パフォーマンス

• 操作への反応は100ms以内(押下フィードバック)。1秒を超える処理は進捗を見せる(スケルトン・バー・件数)。
• 待たせるときは「何をしているか」を出す(「PDFを解析中…」)。凍った画面が最も不安を生む。ある対象の処理待ちが画面全体をブロックしていないか。処理は対象の近くに閉じ込める。
• 楽観的更新は可逆な操作だけ。不可逆(送信・課金・公開)は完了確認後に反映する。
• 読み込みはスピナーよりスケルトン(レイアウトが跳ねない)。具体実装は jp-web-design references/components.md §7。
• hoverは「押せる候補」、pressed/focusは「いま操作している対象」、入場は「追加された場所」、progressは「処理の継続」を伝える。動きは状態変化・位置関係・因果を伝えるためだけに使い、装飾のための跳ねる・浮く・フェードを理由なく反復しない(装飾の動きだけをオフにしても機能が失われないこと)。時間・CSS・reduced-motionの正本は jp-web-design references/motion-a11y.md。
• 「パッと出る」入場は追加された対象だけへ使い、既存の一覧全体や再レンダーのたびに再生しない。長いstaggerは作業開始を遅らせるため、最大6要素・全体300ms以内。

11-1. 触りたさの5要素(操作感の診断)

見た目の秩序だけでは「触りたい」UIにならない。触りたさ = 操作できる手掛かり × 結果の予測可能性 × 即応性 × 可逆性 × 操作による効果。Apple の Human Interface Guidelines / Fluid Interfaces が繰り返し重視する軸で、レビュー時に最も低い要素から着手する(背景の考え方は references/apple-polish.md)。

• 操作可能性が形と状態で伝わるか: 押せる・選べる・ドラッグできる・スクロールできる、を試す前に見た目から判断できるか(hover/focus/pressed/selected を個別に設計したか)。
• 結果が予測できるか: 同じ見た目の要素は、画面のどこにあっても同じ結果を返すか。
• 反応が即座か: 完了後ではなく操作を始めた瞬間に反応が返るか(上の100ms・進捗表示)。
• 止めたり戻したりできるか: 途中で中断・キャンセル・方向転換ができ、誤操作から復帰(Undo・確定前キャンセル)できるか(§3 摩擦の非対称性、§7)。
• 一手の効果が大きいか: 1回の操作(フィルタ・一括変更・インライン編集)がまとまった仕事を進めるか。1件ごとに複数ページを往復させていないか(§5)。

12. 行動科学の道具箱(アプリへの落とし込み方まで)

出典系譜: Laws of UX(Yablonski)/ NN/g 10ユーザビリティ原則(Nielsen)/『誰のためのデザイン?』(Norman)/『実践 行動経済学』(Thaler & Sunstein)。全テクニックに倫理ガードが掛かる: ユーザーの目標達成を速く・安全にするためだけに使う。事業者に都合のよい誘導・ダークパターンは禁止。

道具ごとの原理とアプリでの実装対応表(A. 判断を速くする/B. 操作を軽くする/C. 感情を設計する、計18項目)は references/behavioral-toolbox.md。新しいテクニックを導入するときは「①どの原理か ②ユーザーの何が速く/安全になるか ③ダークパターン化していないか」の3点を言えること。言えなければ入れない。

13. 検収チェックリスト(UX)

13-1. 装飾除去テスト(実装が一区切りついたら必ず)

• 色・カード・影・角丸をすべて外して見たとき、何が重要で、どこから見ればよいかが、配置・余白・順序・サイズだけで伝わるか。
• 画面をぼかして(縮小して)見たとき、主作業領域が一つに見えるか。
• この画面が何をするための画面か、30秒以内に説明できるか。
• 選択中・編集中・保存中・失敗・権限不足・空・読み込み中といった通常状態以外が、通常状態と同じ精度で設計されているか。
• 一つでも崩れる項目があれば、装飾で整理されているように見せているだけ。§0-1 / §2-3 に戻って構造から作り直す(装飾の調整では直らない)。崩れ方ごとの戻り先は references/structure-diagnosis-by-domain.md 末尾。

13-2. 体験の検収

• 最頻シナリオが最少手数で一巡できるか(実物のデータを使って自分で通す。サンプルで済ませない)。
• 各画面が「使われる場面の1文」から設計されているか。情報がグループ化・優先順位付け・表示用加工を経ているか(jp-web-design references/information-design.md §2)。
• 表示形式を6判断軸から導出し、却下した候補と決め手が1行で言えるか。実件数(0件/1件/最大)で破綻しないか。
• 画像は識別/証拠/説明/装飾に分類され、装飾だけの画像は原則削除されているか。採用画像は alt・必要なキャプション・焦点を守るトリミングを持ち、375/768/1280/1600pxの4幅で検収したか。
• 操作の手順を説明文で補っていないか(説明を消してもタスクが完了できる形になっているか)。
• よくある選択がデフォルトで選択済みか。課金・送信・削除系はOFFがデフォルトか。
• 「楽」と「ミス防止」が両方入っているか(重複拒否・要入力ハイライト・入口の正規化)。
• 入力欄2つ以上のフォームに下書き自動保存があり、復元が可視化(復元通知+破棄)され、送信成功で消えるか。
• IME変換確定のEnterで送信されないか。バリデーションは「blurで判定・修正中に解除」か。
• 一括操作に「事前選択 + その場確認 + 項目別結果 + 部分成功」があるか。
• リストに全選択・選択バー・範囲選択があるか。複数ファイルを一度に受け、並行処理で待たせない設計か。
• 自動化に「結果サマリー + Undo」が付いているか。チェックは全件でなく例外だけに絞られているか。
• 入力の作法(空欄の意味・初期値・保存単位・Enterの挙動)が全画面・全ステップで同じか。入力部品が共通化されているか。
• 自動計算値が欄の中に入っており、「自動のまま」と「人が入れた」が見た目とデータの両方で区別され、「自動に戻す」があるか。
• 現在地(ステップ・タブ)と退避先(保存・戻る・次へ)が常に見えるか。該当全画面にMECEに適用し、除外理由が残っているか。
• 一覧入力で参照列と入力列が離れすぎていないか。数値が右揃え・等幅で桁がガタつかないか。
• できなかったことが画面に正直に出るか(要確認・未読取・失敗理由)。編集不可・空表示の理由が画面に1行出るか。
• エラーに次のアクションがあり、入力が保持され、行き止まりがないか。
• 削除の代わりにステータス制御になっているか。原本がストックされているか。
• 1秒超の処理に進捗が見えるか。不可逆操作が楽観的更新になっていないか。
• hover / pressed / focus / 入場 / 展開 / loading / success・errorの各状態が因果を伝え、タッチでも重要操作が見え、reduced-motionで動きを止めても意味が残るか。
• ホームが「要対応 → 次のアクション → 最近 → キー数字」の順になっているか。
• 現実の業務量(一度に◯件)で試したか。
• 動的パスを実際に操作したか: 一括実行→部分成功→再試行 / 下書き保存→閉じる→復元→破棄 / エラー→回復。実装しただけで検収を通さない。

見た目(色・組版・部品・状態・モーション)の検収は Skill jp-web-design の references/acceptance-checklist.md を併用する。

14. 実装パターン集(assets/ — コードが正)

• assets/structure-worksheet.md — §0-1 / §2-3 / §11-1 / §13-1 の答えを画面ごとに1枚へ残すワークシート(複製して記入。空欄のまま実装に進まない)。

本スキルの主要規律は React + TypeScript の汎用hooks/ユーティリティとして保存されている。該当機能を実装するときはコピーして使う(似たものを毎回書き起こさない)。どのアプリでも使えるようドメイン非依存で書かれている。

節	コード	内容
§4-1	useDraft	下書き自動保存(debounce・TTL・復元フラグ・破棄・送信時クリア)
§5-1	useBulkSelection	一括選択(表示中のみ全選択・Shift+クリック範囲選択・選択不可の自動除外)
§4-2	useSubmitKeys	Enter=次フィールド / ⌘・Ctrl+Enter=送信 / IMEガード / OS別キーラベル
§4-2	useLateValidation	blurで判定・修正中に解除
§5-2	runWithConcurrency	並行キュー(同時N本・項目別ステータスコールバック)
§5	splitResults	部分成功の分割(成功は先へ・失敗は要確認キューへ)
§5-3	applyWithUndo	自動処理の「サマリー+Undo」
§4	normalizeNumeric / isEmail	入力に寛容・出力は厳格(ポステルの法則)
jp §3-2	formatNumParts	Excel整形+カンマ縮小(値の文法)

• vanilla JS の参照実装(同じ挙動の非React版)は Skill jp-web-design の assets/reference/app.js。
• 見た目のコンポーネント対応(Button/Badge/Field/選択バー等)は Skill jp-web-design の assets/reference/README.md の移植ルールに従う。

15. リファレンス索引(references/ — 作業内容に応じて読む)

ファイル	いつ読むか	内容
references/structure-diagnosis-by-domain.md	画面の型(一覧・単票・分析・操作感)で §0-1 の重心を決めるとき、前例のない画面、§13-1 を通らなかったとき	ドメイン別の補足問い、原理への還元手順、装飾除去テストで崩れたときの戻り先
references/apple-polish.md	§11-1 の操作感を深掘りするとき、「Appleのように」と求められたとき	直接操作・即応性・中断可能性・空間的一貫性、状態設計、動きは説明のため、触りたさモデルのレビュー活用
references/input-patterns.md	フォーム・入力欄を実装/レビューするとき(§4必読)	下書き自動保存(§4-1)、IME・送信トリガ・blurバリデーション(§4-2)、動作とデザインの一致(§4-3)、自動計算値の由来表示・入力部品の共通化(§4-4)、一覧入力の視線移動(§4-5)
references/bulk-operations.md	一覧・アップローダ・自動化を実装/レビューするとき(§5必読)	一括選択の標準装備(§5-1)、複数ファイル並行処理(§5-2)、省略とチェックの両立(§5-3)
references/behavioral-toolbox.md	行動科学の根拠を確認する・新しい仕掛けを検討するとき(§12必読)	18の道具(デフォルト効果/ヒック/ミラー/アンカリング/ヤコブ/フォン・レストルフ/系列位置/フィッツ/ドハティ/テスラー/ポステル/目標勾配/ピークエンド/ツァイガルニク/損失回避/美的ユーザビリティ/ポカヨケ/選択アーキテクチャ)の原理とアプリ実装対応表

見た目の実装(Button/Badge/Field/選択バー等)は Skill jp-web-design の references/components.md を参照。