リーンUX

まずビジネス上の課題から出発して、UXに関する仮説を明文化する。

フォーマット: 「私たちは、〇〇（機能/デザイン変更）を提供すれば、△△（ターゲットユーザー）が□□（期待する行動）をするようになると信じている。これは☆☆（計測指標）が改善されることで検証できる」

例: 「私たちは、トップページにユーザーの利用履歴に基づくレコメンドを表示すれば、リピートユーザーが再購入するまでの時間を短縮できると信じている。これは再購入率が10%向上することで検証できる」

ポイント: 仮説なしのデザインは「なんとなく良さそう」の積み重ね。仮説があれば失敗しても学びが残る。

仮説を検証するための最小限のデザイン成果物を作る。完成品ではなく、学びを得るために必要な最低限のものでよい。

レベル別のアウトプット:

• ペーパープロトタイプ: 紙とペンで画面を描いてユーザーに見せる（所要30分）
• ワイヤーフレーム: Figmaなどで骨格だけ作る（所要2〜3時間）
• クリッカブルプロトタイプ: 画面遷移できるモックアップ（所要1〜2日）
• コード実装: 実際に動く最小限の機能（所要3〜5日）

仮説のリスクが高いほど、軽量な手法で先に検証する。「この導線で迷わないか？」はペーパープロトで十分わかる。

作ったデザインを実際のユーザーに触ってもらい、データを集める。

• ユーザビリティテスト: 5人に触ってもらい、操作の様子を観察する
• A/Bテスト: 現行デザインと新デザインを同時に出して比較する
• 定量データ分析: クリック率、離脱率、タスク完了率などを計測する

「使いやすいと思いますか？」と聞くのではなく、実際の行動を観察・計測すること。人は質問に対して嘘をつくが、行動は嘘をつかない。

テスト結果を仮説と照らし合わせ、次のアクションを決める。

• 仮説が正しかった → そのデザインを本実装に進める
• 仮説が部分的に正しかった → 改善点を特定して次のイテレーションへ
• 仮説が間違っていた → 仮説を修正して別のアプローチを試す

学びをドキュメント化するのが重要。「このデザイン変更は効果がなかった。理由は〇〇」という記録が、チームの資産になる。