画面遷移
ユーザーニーズを起点に、目的達成までの画面遷移を設計します。
「ユーザーの行動」と「必要な画面」を紐づけることで、抜け漏れを防ぎます。
なぜ画面遷移を設計するか
よくある失敗パターン
- • 画面はあるが、ユーザーがどう辿り着くか不明
- • 開発終盤で「この画面からあの画面に行けない」と発覚
- • エラー時や例外ケースの遷移が考慮されていない
- • 複数のニーズで同じ画面が必要なのに、重複して設計してしまう
toishi の画面遷移設計は、ユーザーニーズを起点にします。 「このニーズを達成するために、ユーザーはどんな行動を取り、どの画面を経由するか」を考えることで、 必要な画面が自然と洗い出されます。
入力する項目
対象ユーザーニーズ
どのユーザーニーズの画面遷移を設計するかを選択します。
例
「商品を素早く検索して見つけたい」（月間45,000回）
ステップ（行動と画面の紐づけ）
ユーザーの行動を自然言語で記述し、それぞれの画面を紐づけます。
記入例：「商品を検索して購入したい」
行動: サイトを開く
画面: トップページ
行動: 検索キーワードを入力する
画面: トップページ（検索フォーム）
行動: 検索結果から商品を選ぶ
画面: 検索結果ページ
行動: 商品詳細を確認する
画面: 商品詳細ページ
行動: カートに入れる
画面: 商品詳細ページ → カートページ
Claude Code での操作例
あなた
「toishiに画面遷移を追加して。 ニーズは『商品を素早く検索して見つけたい』。 トップ→検索結果→商品詳細→カートの流れで」
AI
画面遷移を作成しました。
1. サイトを開く → トップページ
2. 検索キーワードを入力 → トップページ
3. 検索結果から商品を選ぶ → 検索結果ページ
4. 商品詳細を確認 → 商品詳細ページ
5. カートに入れる → カートページ
「検索結果ページ」は新しい画面です。画面詳細に追加しますか？
あなた
「追加して。あと、検索結果が0件だった場合の分岐も入れて」
承認のポイント
承認者はここをチェック
- ✓ ユーザーの行動が自然で、ステップ数が適切か
- ✓ 各ステップで必要な情報が画面で得られるか
- ✓ エラーケースや例外パターンが考慮されているか
- ✓ 「戻る」操作や離脱後の再開が考慮されているか
- ✓ 他のニーズと画面が適切に共有されているか
ベストプラクティス
ユーザーの言葉で行動を書く
「検索APIを呼び出す」ではなく「検索キーワードを入力する」。 ユーザー視点の自然な行動として記述します。
ハッピーパスから始める
まずは「うまくいく場合」の遷移を設計。 その後、エラーケースや例外パターンを追加します。
画面の共有を意識する
複数のニーズで同じ画面を使う場合、ROI計算で工数が重複カウントされません。 共有できる画面を見つけることで、効率的な設計になります。
5-7ステップを目安に
ステップが多すぎるとユーザー体験が悪化。 7ステップを超える場合は、機能を分割するか、ステップを統合できないか検討します。
なぜこの設計なのか
ユーザーニーズ起点で設計。画面ありきではなく行動ありき
「ログイン画面が必要」から始めると、「なぜその画面が必要か」が不明確になります。 「商品を検索したい」というニーズから「検索→結果→詳細」の遷移を導出することで、 目的のない画面が生まれません。
エラー・空状態・ローディングの遷移まで考慮 — これを後から追加すると工数1.5倍
「検索結果0件」「通信エラー」「ローディング中」の遷移を後から追加すると、 画面設計・実装・テストが全て手戻りします。 正常系だけでなく例外ケースも事前に設計することで、開発中の「これも必要だった」を防ぎます。
複数ニーズが同じ画面を共有するケースを事前に発見できる
「商品検索」と「お気に入り通知」が両方「商品詳細画面」を使うことが分かれば、 工数を重複カウントせずに済みます。 画面遷移を全ニーズで設計することで、共有画面を発見し、ROI計算の精度が上がります。