Navigation Design

Purpose

Design the navigation architecture for a mobile or cross-platform feature, including screen hierarchy, deep linking scheme, state preservation strategy, and transition animations.

Inputs

• •Feature requirements and user flows
• •Target platforms and framework (React Navigation, Flutter Navigator, SwiftUI NavigationStack)
• •Existing navigation structure (if extending)
• •Deep linking requirements (universal links, custom schemes)

Process

Step 1: Map the Screen Hierarchy

Identify all screens the feature requires. Organize into a hierarchy:

• •Root screens (accessible from tab bar or drawer)
• •Stack screens (pushed onto a navigation stack from a root)
• •Modal screens (presented modally — confirmation dialogs, full-screen overlays)
• •Nested stacks (sub-flows that have their own back history)

Step 2: Define Navigation Patterns

For each transition between screens, specify:

• •Push/Pop (standard stack navigation, swipe-back gesture)
• •Modal present/dismiss (bottom sheet, full-screen modal)
• •Tab switch (preserves stack state per tab)
• •Deep link entry (navigates directly to a specific screen with params)

Step 3: Design Deep Linking Scheme

Map feature screens to URL patterns:

• •Universal link format: https://app.example.com/feature/:id
• •Custom scheme format: myapp://feature/:id
• •Define parameter handling and fallback behavior (web redirect, app install prompt)
• •Handle authentication requirements for deep-linked screens

Step 4: State Preservation Strategy

Design how navigation state survives:

• •Tab switches — Each tab preserves its own stack
• •Backgrounding — Navigation stack is serialized and restored
• •Process death — Full state restoration from persistent storage
• •In-progress forms — Draft data survives navigation events

Step 5: Transition Design

Specify animations for each navigation event:

• •Standard push/pop (platform default is usually correct)
• •Modal presentation style (sheet, full-screen, custom)
• •Shared element transitions (if applicable)
• •Reduced-motion alternatives

Step 6: Edge Case Handling

Address navigation edge cases:

• •Back button from a deep link (where does the user go?)
• •Notification tap while already on the target screen
• •Multiple deep links in quick succession
• •Authentication-gated screens (redirect to login, then return)

Output Format

# Navigation Architecture

## Screen Map

Tab Bar ├── Home (root) │ ├── Feature Detail (push) │ │ └── Edit Modal (modal) │ └── Settings (push) ├── Search (root) │ └── Result Detail (push) └── Profile (root)

## Navigation Table
| From | To | Type | Gesture | Animation |
|------|----|------|---------|-----------|
| Home | Feature Detail | Push | Tap row | Slide left |
| Feature Detail | Edit | Modal | Tap button | Slide up |

## Deep Link Map
| URL Pattern | Target Screen | Params | Auth Required |
|-------------|--------------|--------|---------------|
| /feature/:id | Feature Detail | id | No |
| /feature/:id/edit | Edit Modal | id | Yes |

## State Preservation
| Event | Strategy | Storage |
|-------|----------|---------|
| Tab switch | Preserve stack | Memory |
| Background | Serialize nav state | AsyncStorage |
| Process death | Full restoration | Persistent |

## Edge Cases
- [Edge case and handling strategy]

Quality Checks

• • Every screen is reachable from at least one navigation path
• • Deep links have fallback behavior for unauthenticated and uninstalled states
• • State preservation handles backgrounding, process death, and tab switches
• • Back button behavior is defined for every screen including deep link entry
• • Navigation patterns match platform conventions (iOS push vs Android fragment)
• • Reduced-motion alternatives are specified for custom transitions

Evolution Notes