プロダクトデザイン・UX・行動科学

最終更新: 2026-08-01

デザインの目的

個人開発におけるデザインは装飾ではない。顧客が状況を理解し、正しい行動を選び、価値へ到達し、失敗から回復できるようにする設計である。

良い UX は次を同時に満たす。

何のための製品かが分かる
最初の成果まで迷わない
現在の状態と次の行動が分かる
誤りを予防し、元に戻せる
速度、端末、能力の違いに耐える
料金、AI、データ利用、制約を誤解させない
使い続けるほど本来の仕事が楽になる

価値から画面を逆算する

機能一覧ではなく、顧客の仕事を次に分ける。

発火条件
→ 入力を集める
→ 判断・処理する
→ 人が確認する
→ 成果を渡す
→ 履歴・証拠を残す
→ 次回へ再利用する

各段階で問う。

顧客は何を知っているか
何が不安か
何を入力しなければならないか
どの誤りが高コストか
AI とルールと人間のどれが担当すべきか
完了を何で確認するか

画面数を減らすことより、顧客の認知・入力・待機・確認・やり直しを減らす。

コア価値イベント

登録やログインではなく、顧客が初めて成果を経験した行動を 1 つ定義する。

例:

最初の監視対象を登録し、意味のある変化通知を受け取った
初回レポートを原データ照合済みで配信した
最初の請求漏れ候補を発見して修正した
顧客データで 1 件の処理を承認まで完了した

Activation rate
= 所定期間内にコア価値イベントへ到達した新規適格ユーザー
  / 同期間の新規適格ユーザー

分母からテスト、社内、ボット、不適格流入を除くルールを固定する。

Time to Value

Time to First Value (TTFV)
= 初回価値イベント時刻 - 初回の意図ある開始時刻

「短いほど良い」だけではない。高リスク B2B では設定・確認が必要で、速さより信頼が優先される。競争相手は次のいずれか。

何もしない時間
現在手順の所要時間
導入稟議と設定の負担
誤りを発見・修正する時間

価値到達を早める方法:

サンプルではなく本人の最小データを使う
インポート、連携、テンプレートを先に用意
初回は 1 つの成果へ機能を制限
設定代行や共同オンボーディング
空状態に「追加」ではなく完成例と次の一手を出す
長い設定は保存可能な段階へ分ける
待ち時間中に進捗、理由、終了見込み、キャンセルを示す

オンボーディング

オンボーディングは製品説明ツアーではなく、価値までの支援。

最小原則

初回に不要な情報を聞かない。
顧客の意図を 1〜3 個の選択で知り、経路を変える。
読ませる前に、実データで小さい仕事を終わらせる。
権限や連携を求める直前に、用途と範囲を説明する。
サンプルデータと本番データを明確に分ける。
後で変更できるものは既定値を置く。
離脱箇所だけでなく、迷い、エラー、支援依頼を観察する。

初回セッションの設計

約束を再確認
→ 最小入力
→ 最小処理
→ 成果を見せる
→ 正しさを確認させる
→ 保存・共有
→ 次回の自動化を提案

課金をどこに置くかは、流入意図と価値の明瞭さで決める。価値がよく知られ、提供原価が高いなら先払いも合理的。価値を体験しないと理解できないなら、制限付き試用または有償パイロットがよい。

ここでのオンボーディングは利用者が製品内で価値へ到達する設計である。B2B の契約、データ・権限、顧客側 RACI、Start-ready、組織定着は 11 章で別に管理する。

情報設計

顧客の言葉を使う

内部データモデルや AI 用語をナビゲーションへ出さない。

悪い: Vector store、Agent run、Artifact
良い: 資料、処理、レポート、確認待ち

顧客インタビュー、サポート、検索語、既存帳票から語彙を集める。同じ概念に複数語を使わない。

状態を明示する

非同期処理、承認、決済、連携では状態機械を先に設計する。

下書き → 処理中 → 要確認 → 承認済み → 配信済み
              ↘ 失敗 → 再試行 / 手動対応

各状態に次を用意する。

状態名
なぜその状態か
いつ変わったか
誰が変えたか
次にできる行動
取り消し・再試行方法

「Something went wrong」だけではサポート負債になる。

フォームとエラー

ラベルをプレースホルダーだけにしない
必須・任意と形式を入力前に示す
検証は可能な範囲で即時、エラーを入力欄と要約の両方に関連付ける
入力値を失わない
高損失操作は確認画面、要約、取消猶予を置く
同じ入力を再度要求しない
自動整形で意味を変えない
API・連携障害では利用者が取れる次の手段を示す

決済、削除、公開、メール一斉送信、外部更新、AI エージェントの実行は、影響範囲と費用を直前に再確認する。

行動科学を倫理的に使う

行動科学は人を騙す方法ではなく、望んでいる行動を妨げる摩擦と不確実性を理解する道具。

能力・動機・きっかけ

行動が起きないとき、単に通知を増やさず三つに分ける。

動機: 成果が重要だと感じるか
能力: 時間、知識、権限、費用が足りるか
きっかけ: 適切な瞬間に次の行動が分かるか

動機がない顧客へリマインダーを送ってもスパムになる。能力不足ならテンプレート、設定代行、権限説明を改善する。

認知負荷

人の作業記憶は限られる。次で負荷を下げる。

1 画面 1 主目的
選択肢を意味のあるまとまりへ分ける
以前の選択と文脈を保持する
比較は同じ単位と順序で示す
初心者には推奨値、熟練者には詳細設定
重要な違いだけを強調する
文書・料金・権限を平易な言葉で要約する

既定値

既定値は強い影響を持つため、利用者の合理的利益に沿うものにする。

通知は価値あるイベントだけを既定にする
公開・データ共有・高額利用は保守的な既定
年額課金やマーケティング同意を紛れ込ませない
推奨設定の理由と変更方法を示す

社会的証明

「人気」「残りわずか」「多くの企業が利用」を根拠なく使わない。証言は許可、属性、利用時期、具体的成果、典型性を確認する。絶対額より、導入条件と測定方法を併記する。

損失回避と緊急性

本当に存在する期限、在庫、更新、リスクは明瞭に伝える。偽カウントダウン、取消しにくい試用、罪悪感を使う解約画面は、短期転換と引き換えに返金、苦情、評判、法的リスクを増やす。

進捗とコミットメント

複雑な設定は小さな完了へ分け、残りと中断可能性を示す。完了率を上げるために不要なステップを作らない。利用者が設定した目標、保存したテンプレート、次回予定を再利用し、本人が望む継続を助ける。

ダークパターンを避ける

禁止すべき社内ルール:

解約だけ見つけにくくする
同意済みに見せかけたチェックボックス
料金・更新・試用終了を隠す
見た目で「拒否」を弱くする
追加商品を無断でカートへ入れる
データ削除と課金解約を曖昧にする
AI 生成物を人間の確定判断に見せる
偽の利用者数、在庫、期限、通知
退会時に必要以上の理由や連絡を要求する

良い確認は誤操作を防ぐ。悪い摩擦は意思決定を妨げる。目的を区別する。

信頼設計

AI 機能

利用者へ必要に応じて示す。

AI を使う箇所
入力データがどこへ送られるか
出力の不確実性と用途制限
根拠、原文、計算へのリンク
人が確認したか
やり直し、修正、報告方法
費用または利用枠への影響

信頼度を根拠なくパーセント表示しない。代わりに、出典の有無、検証済み項目、未確認項目を示す。

料金

税込み・税抜き、通貨、請求周期
自動更新、試用終了日、超過課金
解約後の利用期間、データ保持
返金条件
プラン変更の適用時期

を申込み直前と確認メールに明示する。

プライバシー

法務ページだけでなく、データを求める瞬間に目的と範囲を説明する。最小権限、最小収集、保存期間、削除、エクスポートを製品機能として設計する。

リテンション設計

通知や連続記録だけでは継続価値を作れない。顧客の反復ジョブと結び付ける。

AI 機能では、生成・採用・ログインを継続価値とみなさず、別の自然業務周期で verified value が再現し、非標準の founder rescue なしで成立したかを追う。workflow value cycle、商業更新、介入の assignment と exposure を分ける操作定義は 12 章を正本とする。

健全な継続要因:

定期的に再発する問題
過去データから改善する提案
テンプレート、履歴、ルールの蓄積
同僚・顧客との共同作業
既存業務への連携
監査、証拠、期限管理
継続的な監視と例外通知
使うほど精度が上がる評価・修正データ

不健全な継続要因:

データを出せない
解約方法を隠す
意味のないバッジや通知
失う恐怖だけを煽る

コホートを見る

週 N 継続率
= 初回価値週が同じ利用者のうち、週 N に価値行動を行った人数
  / そのコホート人数

ログインではなく価値行動で測る。顧客属性、獲得チャネル、初回用途、プランで分ける。人数が少ない間はグラフだけでなく、各顧客の利用理由を読む。

解約から学ぶ

解約時は 1 クリックで手続きを完了できるようにし、その後に任意で聞く。

期待した成果を得られなかった
利用頻度が低い
価格に見合わない
必要機能・連携がない
品質・速度・信頼性
組織変更・予算
競合へ移行
その他

選択肢だけで断定せず、利用ログ、サポート、面談と照合する。解約直前の値引きより、初回価値と継続ジョブを直す。

アクセシビリティ

W3C は WCAG 2.2 を推奨し、知覚可能、操作可能、理解可能、堅牢という原則と、A・AA・AAA の適合水準を定めている。一般的な Web アプリでは、法域・顧客要件を確認しつつ WCAG 2.2 AA を設計・検証基準の既定値にする。W3C WCAG 2.2

最低限の実装チェック:

セマンティック HTML を先に使う
キーボードだけで全主要操作が可能
フォーカスが見え、固定 UI に隠れない
入力に永続ラベルとエラー説明
色だけで状態を伝えない
文字・UI のコントラストを確認
画像、図、アイコンへ適切な代替
200% 拡大と狭い画面でも操作可能
動きを減らす設定へ対応
タップ対象を十分に確保
認証で記憶・パズルだけに依存しない
スクリーンリーダーで状態変更を通知
自動テストに加え、キーボードと支援技術で手動確認

アクセシビリティは最後の監査ではなく、コンポーネント、デザインシステム、受入条件へ組み込む。

パフォーマンスも UX

Core Web Vitals の安定指標は LCP、INP、CLS。Google の「良好」基準は 75 パーセンタイルで LCP 2.5 秒以下、INP 200ms 以下、CLS 0.1 以下である。web.dev Core Web Vitals thresholds

これらは唯一の UX 指標ではない。アプリでは次も見る。

サーバー応答と初回描画
検索・保存・生成の p50/p95 待ち時間
失敗率、再試行率
低速回線・低性能端末
実ユーザー計測と合成テストの差
AI 処理中に別作業ができるか

速さのために正しさや確認を消さない。即時に完了できない処理は、キュー、進捗、通知、再開、冪等性で体感を改善する。

デザインシステムの最小構成

個人開発では大規模なコンポーネント集より、次を統一する。

文字サイズ・行間・行長
色の役割とコントラスト
余白の段階
ボタン、リンク、入力、表、ダイアログ
成功、注意、失敗、処理中、空状態
フォーカス、無効、読取専用
破壊操作と取消し
モバイルとキーボード挙動

独自 UI を増やすほど、Codex が生成する画面の一貫性とアクセシビリティ検証が難しくなる。標準要素と成熟したプリミティブを使い、例外に理由を求める。

ユーザビリティテスト

5 人という数字を儀式にせず、対象セグメントと主要タスクごとに反復する。

手順:

調べたい仮説と失敗条件を決める。
実際の ICP に近い参加者を集める。
「このボタンを押して」ではなく、現実の目標を渡す。
発言だけでなく、迷い、戻り、確認、諦めを記録する。
助けずに観察した後、期待と理解を聞く。
重大度を、到達不能・誤操作・大きな遅延・軽微な摩擦に分ける。
修正し、同じタスクを別参加者で再検証する。

測るもの:

タスク成功率
所要時間
重大エラー
支援が必要だった箇所
確信度
期待と実結果の差

UX 受入条件テンプレート

対象ユーザー:
状況と目的:
開始状態:
成功状態:
主要経路:
エラー・空・処理中・権限不足:
キーボードとスクリーンリーダー:
狭い画面と 200% 拡大:
性能予算:
計測イベント:
取消し・復旧:
利用者へ説明すべき AI/料金/データ条件:

リリース前 UX チェック

美しさは信頼を助けるが、顧客が成果へ到達できること、誤りを理解し回復できることが先である。