UI/UX設計 — エンジニア視点の思考フローとスプリント計画

ユーザー理解 → UX設計 → UI設計 → 実装
     ↑            ↑         ↑        ↑
   "誰が"      "どう動く"  "どう見せる" "どう作る"
   "何に困ってる"  (体験)    (画面)    (コード)

実装 → UI設計 → (ユーザー理解は後回し)
→ 誰に向けて作ったかわからないものができる
→ リリース後に「使われない機能」が生まれる

【定量ツール】何が起きているかを数値で把握
  Google Analytics / Pendo / Mixpanel など

【定性ツール】なぜ起きているかを言葉で把握
  ユーザーインタビュー / アンケート / セッション録画（FullStory等）

Step1: GA4    → 「機能Aに辿り着いているか」を確認
Step2: Pendo  → 「辿り着いた人が使っているか」を確認
Step3: 定性   → 「なぜ使わないか」をインタビューで確認

ログイン頻度    → 月1回以下 = ライトユーザーの目安
機能利用数      → 全機能中2〜3つしか使っていない
セッション時間  → 短い・目的達成後すぐ離脱

ヘビーユーザー向け設計          ライトユーザー向け設計
─────────────────────────────────────────────
機能の豊富さ          →        機能の少なさ・シンプルさ
カスタマイズ性        →        デフォルトの完成度
学習コストOK          →        ゼロ学習で使える
滞在時間を伸ばす      →        素早くゴール達成させる

❌ 悪い例: トップ → メニュー開く → 投稿ボタン探す → カテゴリ選択 → 本文 → 投稿（6ステップ）
✅ 良い例: トップに投稿欄が最初から表示 → 本文入力 → 投稿（2ステップ）

選択肢が増えるほど意思決定に時間がかかる
→ ライトユーザーは迷った瞬間に離脱する
→ ナビゲーション項目は5つ以内・初期表示は1〜2アクションに絞る

過剰な通知 = ストレス = 離脱
→ 週1サマリーメール等、低頻度・高価値な通知が有効

投稿する人（少数・ヘビー寄り）< 閲覧する人（大多数・ライト）
→ 閲覧UXへの投資対効果が圧倒的に高い

UX設計のアウトプット：
  ├ ユーザーフロー（画面遷移の流れ）
  ├ 情報アーキテクチャ／IA（情報の構造）
  └ ワイヤーフレーム（画面の骨格）

① ゴールを決める（例: 投稿を読んでいいねする）
② スタート地点を決める（例: トップページ）
③ 最短経路を描く
④ 分岐・エラーを追加する

[トップ]
  └─ 投稿一覧を見る
       └─ [投稿詳細]
             ├─ いいねする → [完了]
             └─ コメントする → [入力画面] → [完了]

ユーザーフローを見てAPIの設計が変わる
IAを見てルーティング設計が変わる
→ UXフローを読めると「この画面遷移、API1本じゃ足りない」と
  実装前に気づける = 手戻りゼロ

UX設計で決めたこと          UI設計で決めること
─────────────────────────────────────────
ユーザーフロー         →    画面遷移図
情報の優先順位         →    レイアウト・配置
ゴールまでのステップ   →    ボタン・インタラクション

// ① コンポーネントの粒度 → Reactのコンポーネント設計に直結
// ② Stateの数 → 実装コストに直結
const [isLiked, setIsLiked] = useState(false)       // いいね済みか
const [likeCount, setLikeCount] = useState(0)        // いいね数
const [commentCount, setCommentCount] = useState(0)  // コメント数
const [isPending, setIsPending] = useState(false)    // API待ち
const [error, setError] = useState<string | null>(null) // エラー

// ③ APIの呼び出しタイミング → 無限スクロール or ページネーション

設計フロー               スプリントへの変換
─────────────────────────────────────────
ユーザーフロー     →    エピック（大きな機能単位）
画面単位のUI       →    ストーリー（ユーザー視点のタスク）
Stateの数          →    タスク（実装単位）
APIの呼び出し      →    タスク（バックエンド）

【エピック】投稿へのリアクション機能

【ストーリー】"ユーザーとして、投稿にいいねして気持ちを伝えたい"

【タスク】
  フロントエンド：
    ├ いいねボタンコンポーネントの実装
    ├ いいね済み/未いいねのState管理
    ├ いいね数のリアルタイム表示
    ├ オプティミスティックUI実装
    └ エラー時のロールバック処理

  バックエンド：
    ├ POST /likes APIの実装
    ├ DELETE /likes APIの実装
    └ いいね数取得エンドポイントの実装

  その他：
    ├ Pendoのイベントトラッキング設置
    └ エラーハンドリングのテスト

判断軸：ユーザー数 × 使用頻度 × 実装コスト

Sprint 1（基盤）:   タイムライン表示・閲覧UX
Sprint 2（反応）:   いいね機能（ワンタップ・低コスト）
Sprint 3（対話）:   コメント機能（実装コスト高め）
Sprint 4（計測）:   Pendo/GA4トラッキング設置
                    → データを見て次のスプリントを決める