改善パターン
画面遷移を減らす、具体的な改善パターンを紹介します。
パターン1: 確認画面の削除
Section titled “パターン1: 確認画面の削除”現状: 入力 → 確認 → 完了（3画面）
改善案: 入力 → 完了（2画面）+ 取り消し機能
- 確認画面を削除
- 代わりに「取り消し」ボタンを追加
- または確認モーダルに置き換え
期待される効果: 画面遷移が1つ減ります。セッション管理が不要になります。テストケースも減ります。
パターン2: 編集画面の統合
Section titled “パターン2: 編集画面の統合”現状: 一覧 → 詳細 → 編集（3画面）
改善案: 一覧 → 詳細（編集モード付き）（2画面）
- 編集画面を削除
- 詳細画面に「編集モード」を追加
- 参照/編集をトグルで切り替え
期待される効果: 画面が1つ減ります。コンテキストが保たれます。ルートが減り、テストも単純になります。
パターン3: 登録画面の統合
Section titled “パターン3: 登録画面の統合”現状: 一覧 → 登録画面 → 一覧（画面遷移あり）
改善案: 一覧（インライン追加）（画面遷移なし）
- 登録画面を削除
- 一覧に「+ 追加」行を表示
- その場で入力・保存
期待される効果: 画面遷移がゼロになります。既存データを見ながら追加できます。E2Eテストのステップも減ります。
パターン4: モーダルの削除
Section titled “パターン4: モーダルの削除”現状: 一覧 → モーダルで編集
改善案: 一覧 → インラインで編集
- モーダルを削除
- 行をクリックで編集モードに
- 他の行を見ながら編集可能
期待される効果: 背景が見えたまま操作できます。複数行を同時に編集可能です。
共通するポイント
Section titled “共通するポイント”- 画面を減らす（遷移を減らす）
- その場で操作できる（コンテキストを保つ）
- 戻る操作を不要にする
- テストを単純にする（状態の組み合わせを減らす）
シンプルな設計は、テストもシンプルになります。テストが書きにくいと感じたら、設計を見直すきっかけかもしれません。