YAML
---
name: designing-mobile-flows
description: Designs mobile application flows by mapping state changes, timing, and async behavior before UI implementation. Use when planning mobile features, user journeys, or complex interactions.
---

Designing Mobile Flows

Create a flow map with three layers:

1. States: What data/UI states exist (loading, empty, error, success)
2. Transitions: How users move between states (tap, swipe, timeout)
3. Async Events: What happens behind the scenes (API calls, caching, notifications)

Login Flow Example:
States: [idle] → [validating] → [authenticated] → [dashboard]
Async: validate credentials → fetch user data → sync offline data
Timing: 300ms validation delay, 2s timeout, instant UI feedback

Progress:

• Map user journey: List all user actions from start to end
• Identify states: Define each possible app/screen state
• Plan transitions: How does each user action change state?
• Design async behavior: What network/background tasks run when?
• Set timing expectations: Loading states, timeouts, animations
• Handle edge cases: Network failures, interruptions, edge data
• Validate flow logic: Walk through all possible paths

Example 1: Photo Upload Flow Input: User wants to share a photo Output:

States: [camera] → [preview] → [uploading] → [posted] → [feed]
Async: compress image → upload to CDN → create post → notify followers
Timing: instant preview, 500ms compression, 3s upload timeout
Edge cases: upload failure → retry queue, network loss → draft save

Example 2: Payment Flow Input: User checking out with saved card Output:

States: [cart] → [payment_processing] → [confirmation] → [receipt]
Async: validate card → charge payment → send receipt → update inventory
Timing: 200ms validation, 5s payment timeout, instant success feedback
Edge cases: card decline → retry, timeout → check status, duplicate → idempotency

• State-first thinking: Define all possible states before designing screens
• Assume async failure: Plan for network errors, timeouts, and retries
• Design loading states: Users need feedback within 100ms of any action
• Plan offline behavior: What works without network? What queues?
• Use progressive disclosure: Show essential info first, details on demand
• Consider interruptions: Phone calls, app switching, background/foreground
• Design idempotent actions: Multiple taps shouldn't cause multiple effects

• Starting with UI mockups before mapping logic flow
• Forgetting intermediate loading/error states
• Not planning for slow networks or API failures
• Assuming synchronous behavior (everything happens instantly)
• Missing edge cases like empty data states or first-time users
• Not considering background app behavior and state restoration
• Designing flows that break when interrupted or resumed