The UI/UX Pattern Master

You are a Senior UI Designer at Apple, specialising in iOS applications.

Design a complete UI for Citymapper, a multimodal urban transit and journey planning app.

User research insights:

• Primary user: Alex, 29, lives in Zone 2 London (Dalston), works in Zone 1 (Farringdon). Commutes daily using a combination of Overground, Elizabeth Line, and cycling (Lime e-bike). Doesn't own a car. Makes 4–6 journeys per day including lunch trips, gym, and social plans. Has PAYG TfL contactless but also a Lime monthly pass and occasional Uber. Wants one app that understands all of these modes and optimises across them — not just "fastest route" but "best route for me right now" factoring in cost, weather, energy level, and whether they're carrying a laptop bag or grocery shopping.
• Top 3 user goals: (1) Get a door-to-door journey plan that intelligently combines transit, cycling, and walking based on real-time conditions — not just static timetable data. (2) Understand the true cost of each journey option across all payment methods (contactless cap tracking, Lime subscription credits remaining, Uber surge pricing) before choosing. (3) Receive proactive alerts when their routine is disrupted — "Northern Line suspended, here's your backup route already calculated" — without having to open the app and search.
• Pain points in current solutions: (1) Google Maps treats every mode independently — it'll show a bus route OR a cycling route but won't suggest "cycle to the station, take the train two stops, walk the last 5 minutes" as a single optimised journey. (2) TfL and Citymapper show disruption alerts but don't automatically recalculate — the user still has to manually search for alternatives while standing on a platform. (3) No app tracks cumulative daily/weekly transport spend across multiple providers — contactless TfL, Lime, Uber, and Bolt charges are scattered across four different apps and bank statements, making it impossible to know if they're spending £50/week or £90/week on getting around. (4) Real-time bike/scooter availability is unreliable — the app shows a Lime bike at the corner but by the time you walk there it's gone, and there's no reservation or "hold for 5 minutes" integration. (5) Accessibility information is inconsistent — step-free route options exist but are buried, and there's no way to set a permanent preference for "always show me step-free options first" that persists across all journey searches.

Design following Apple HIG principles: HIERARCHY & LAYOUT

• Visual hierarchy strategy (what users see first, second, third) — The app opens on "right now": your next likely journey based on time of day and historical patterns, real-time status of your usual routes, and any active disruptions affecting your area. Second priority: the journey planner input (where are you going?). Third: your transport dashboard (weekly spend, contactless cap progress, subscription credits remaining). The hierarchy should shift based on context — at 8:15am on a Tuesday, the commute route dominates; at 10pm on a Saturday, nearby night bus and Uber options surface automatically.
• F-pattern and Z-pattern application — Journey results should use a vertical scan pattern optimised for one-handed thumb scrolling on iPhone, with the critical decision-making information (total time, total cost, number of changes) visible without expanding the card. Detailed step-by-step instructions expand on tap.
• Content density decisions — This is a high-information app used in stressful moments (running late, disruption, unfamiliar area). Content density should be medium-high but ruthlessly hierarchical — show everything the user needs to make a decision, hide everything they don't until they ask for it. No decorative elements, no illustrations, no empty space that doesn't serve scanability.

PLATFORM-SPECIFIC PATTERNS

• Navigation pattern: Tab bar with 4 tabs — Go (journey planning and real-time navigation), Live (real-time transit map with disruption overlay), Spend (transport cost tracking and subscription management), and Profile (preferences, accessibility settings, saved locations, commute patterns)
• Modal presentation guidelines — Journey detail view slides up as a sheet over the map. Disruption alerts present as compact banners that expand to full detail on tap. Payment method selection uses an action sheet. Route sharing uses the native iOS share sheet.
• Gesture definitions — Swipe between journey alternatives horizontally (like switching between route options). Pull-to-refresh on the Live map to update real-time positions. Long-press on any transport mode icon to see the next 3 departure times without entering full journey planner. Pinch to zoom the transit map between "my area" and "full city" views.
• Context menus and action sheets — Long-press on a saved location for quick actions (navigate here, share location, check disruptions, set as home/work). Long-press on a journey result for "save this route," "set as daily commute," "share with someone," "report inaccurate time."

SCREEN DESIGNS (8 key screens) For each: wireframe description, component inventory, interaction specs, empty/error/loading states

• Onboarding/Welcome — Permissions flow (location always-on for proactive alerts, notifications for disruptions, motion for auto-detecting when you're on a bus/train). Connect payment methods (TfL contactless card, Lime account, Uber account) to enable spend tracking. Set home/work locations. Select accessibility preferences (step-free priority, low-vision mode, reduced motion). Should feel like 90 seconds, not a registration form.
• Home/Dashboard ("Go" tab) — Map background showing your current location, predicted next journey card at bottom (expandable), disruption banner if active, quick-launch buttons for saved routes. The "smart suggestion" card is the hero — "Your usual 8:22 Overground is running 4 minutes late. Leave at 8:26 instead, or cycle to Haggerston for the 8:31?" This is the screen that makes the app feel intelligent rather than just functional.
• Journey results (Primary task) — Multi-modal journey options presented as swipeable cards, each showing total time, total cost (aggregated across all providers), CO2 comparison, and a colour-coded mode breakdown (blue for rail, green for cycling, yellow for walking, black for Uber/taxi). The "recommended" route is pre-selected based on the user's historical preferences — if they always choose the cheapest option, lead with cheapest; if they always avoid buses, don't show bus routes first.
• Turn-by-turn navigation (Detail view) — Real-time guidance that adapts to mode: walking directions with AR overlay option, cycling navigation with bike lane preference, transit countdown ("your train arrives in 2 minutes, platform 3"), and seamless handoff between modes ("you've arrived at Farringdon, walk 4 minutes to your destination via Exit 1"). Live updating if the journey goes off-plan.
• Spend dashboard (Settings/Profile adjacent) — Weekly and monthly transport spend broken down by mode and provider. TfL contactless cap progress ("you've spent £34.60 this week, £5.40 until your weekly cap"). Lime subscription usage ("12 of 30 rides used this month"). Uber/Bolt spend. Trend comparison to previous weeks. Budget setting with alerts ("notify me if I'm on track to spend over £80 this week").
• Live transit map (Search/Filter) — Real-time positions of buses, trains, and available bikes/scooters overlaid on the city map. Disruption overlay showing affected lines with severity colour coding (amber = delays, red = suspended, grey = planned closure). Filter by mode (show only cycling, show only rail). Tap any vehicle to see its route and next stops. Tap any station to see departures board.
• Journey completion and rating — After arriving, a subtle card summarises the journey: actual time vs. estimated, actual cost, CO2 saved vs. driving. Option to rate accuracy ("was this journey time accurate?") to improve future predictions. Prompt to save as a regular route if it's new. No forced review — this should feel like a gentle debrief, not a feedback form.
• Disruption/Error state — When a planned journey is disrupted mid-travel: full-screen takeover with the disruption summary, automatically recalculated alternative routes (not just "service suspended, check TfL" — actually show the user what to do), and a "I'm stuck, get me home" emergency button that calculates the best available route from current GPS position regardless of mode. For app-level errors (no connectivity): offline mode showing cached timetables with "last updated" timestamps and a clear banner explaining what's live vs. cached.

COMPONENT SPECIFICATIONS

• Button hierarchy: Primary action is always "Go" / "Navigate" (filled, system blue). Secondary actions (save, share, modify) use outlined or text buttons. Destructive actions (cancel journey, remove saved route) use red text, never filled red buttons.
• Form patterns: Journey input uses a two-field "From → To" pattern with smart autocomplete drawing from saved locations, recent searches, and popular destinations. Date/time picker uses iOS native wheel for departure/arrival time selection.
• Card layouts: Journey result cards use a consistent structure — left-aligned mode icons as a horizontal timeline, right-aligned total time and cost, expandable detail on tap. Cards should have clear visual separation but no heavy borders — use subtle shadows and spacing.
• Data visualisation: Spend tracking uses simple bar charts (daily spend) and progress rings (cap tracking). Journey time comparisons use horizontal bar comparisons. CO2 savings use a simple counter that accumulates over time. No complex charts — this isn't a finance app, the data viz should be glanceable.

ACCESSIBILITY COMPLIANCE

• Dynamic Type: All text must scale from accessibility small to accessibility XXXL without layout breaking. Journey result cards must remain functional (all critical info visible) at the largest type sizes, even if secondary information collapses.
• VoiceOver labels: Every journey option must announce mode, time, cost, and number of changes in a single swipe. Map pins must announce location name and relevant real-time info (next departure, bike availability). The mode timeline in journey results must read as a sequential narrative ("Walk 4 minutes, then Overground from Dalston Junction to Liverpool Street, 12 minutes, then walk 6 minutes to destination").
• WCAG AA contrast: All text on map overlays must meet contrast requirements against variable map backgrounds — use semi-opaque background pills behind text rather than relying on map colours.
• Reduce Motion: Replace all route animation (the "drawing" of a route on the map) with instant display. Replace card transitions with crossfades. Disruption alerts use opacity transitions instead of slide-in animations.
• Step-free routing: Must be a persistent, one-tap toggle in the tab bar or journey planner — not buried in settings. When active, a clear visual indicator (wheelchair icon in the status area) confirms the preference is on, and all journey results are filtered accordingly.

MICRO-INTERACTIONS

• Transitions: Journey result cards use a fluid spring animation when swiping between alternatives. The map smoothly tracks the user's position during navigation with a subtle camera ease. Mode transitions during a journey (walking → train → walking) trigger a brief haptic pulse and visual mode-change indicator.
• Haptic feedback: Light tap when selecting a journey option. Medium pulse when a disruption alert fires. Success haptic when arriving at destination. Warning haptic if the user appears to be going the wrong direction during navigation.
• Sound design: Optional departure countdown chime (customisable — "alert me 2 minutes before I need to leave"). Subtle completion sound on journey end. All sounds respect the iOS silent switch and must be independently toggleable in settings.

RESPONSIVE BEHAVIOR

• iPhone landscape: Journey results switch to a split view — map on left, result cards on right — useful when the phone is mounted on a bike handlebar.
• iPad: Full split-view with persistent map and journey panel side-by-side. The spend dashboard expands to show weekly and monthly views simultaneously.
• Dynamic Island integration: Live Activity showing countdown to next departure, real-time delay updates, and current navigation step — the user should never need to unlock their phone to check "how long until my train."
• Apple Watch: Complication showing next predicted journey time. During active navigation, haptic turn-by-turn directions (distinct patterns for "turn left," "turn right," "get off at next stop").
• Widget: Lock screen widget showing next departure from home/work. Home screen widget showing real-time disruption status for saved routes.

Include "Designer's Notes" explaining the rationale behind key decisions.