Mobile users decide whether your app is worth their time in the first 30 seconds -- and the design quality is most of that decision.

Usability testing conducted on physical iOS and Android devices with representative users, not in a browser simulator -- because thumb reach zones, one-handed posture, and notification interruptions produce behaviour that simulators cannot replicate. Task-based testing of the core mobile flows that drive your key outcomes: onboarding completion, first purchase, booking completion, search-to-result, or whatever your specific conversion path is. Participants are recruited to match your target demographic and platform (iOS or Android primary), with 5-6 participants per round sufficient to surface the majority of critical usability issues (Nielsen Norman Group research finding). App store review analysis and support ticket mining to identify recurring UX complaints from existing users -- these are the problems your current users have already articulated and are waiting for you to fix. Competitive analysis of the 3-5 most directly comparable apps in your category: what navigation patterns they use, where they follow platform conventions and where they diverge, what their App Store ratings suggest about user friction points. A research findings document with prioritised issues, direct user quotes, and design recommendations delivered before wireframes begin -- not after, so the wireframes can be built on validated assumptions rather than revised to address findings discovered late.

Design aligned with Apple Human Interface Guidelines across every navigation, interaction, and component decision. Navigation patterns: tab bar for primary navigation (maximum 5 tabs), navigation stack with back button for hierarchical drill-down, modal sheets (full-screen and half-sheet) for tasks that interrupt the main flow. System controls and gestures: swipe-right to navigate back (must not be blocked by custom gesture recognisers), swipe-left on list rows for contextual actions (delete, archive), long-press for context menus (iOS 14+), pinch-to-zoom where spatial manipulation is meaningful. SF Symbols integration for iconography: SF Symbols scale and weight match the surrounding text automatically, render correctly in Dark Mode, and are universally recognisable to iOS users. Dynamic Type support: all text sizes defined as iOS text styles (Large Title, Headline, Body, Caption) rather than fixed point sizes, so users who have increased their system font size for accessibility see your interface scale correctly rather than overflow or truncate. Safe Area insets handled correctly for notch, Dynamic Island (iPhone 14 Pro and later), and home indicator, with content scrolling correctly below system UI on all current iPhone models. App Store screenshot and preview specifications produced alongside the designs so the review submission is ready without a separate design pass.

Design aligned with Material Design 3 (Material You), Google's current design system, across navigation, component, and theming decisions. Navigation patterns: bottom navigation bar for primary destinations (2-5 tabs), navigation rail for tablet and large-screen forms, navigation drawer for secondary destinations in complex apps. Material components used throughout: FloatingActionButton for primary actions, chips for filters and selections, cards with correct elevation hierarchy (level 0 through level 5), dialogs for decisions requiring explicit user input, and snackbars for brief non-disruptive feedback. Adaptive layouts for Android's wider range of screen sizes and densities: foldable device considerations (Samsung Galaxy Z Fold, Google Pixel Fold) where the use case benefits from the unfolded large screen. Dynamic colour theming (Material You) implemented where the app's branding allows the system wallpaper to influence accent colours -- the personalisation feature that increases user attachment to Android apps. Google typeface integration with Roboto or a custom Google Fonts pairing. Google Play Store asset specifications: feature graphic, icon, and screenshot specifications for all required device sizes. Material Design 3 components are production-tested across the fragmented Android hardware ecosystem -- designing to them significantly reduces implementation risk on devices your test lab does not cover.

Onboarding is where mobile apps lose the majority of users who will never return -- industry benchmarks show 25% of mobile apps are used only once. Onboarding flow design covers every decision in the first-run experience: value proposition communication on the first 2-3 screens (specific, outcome-focused, not generic marketing language), permission request timing and framing (requesting camera access on the screen where you explain what you will do with it produces 40-60% higher grant rates than requesting at app launch), account creation flow (social sign-in options reducing form friction, progressive profiling collecting minimum required data upfront and deferring optional data), and the initial setup steps that personalise the experience before the user reaches the core product. A/B test variant design for the critical onboarding decisions: permission request framing, value prop copy, screen count, and whether to show a product tour or defer to task-based discovery. Onboarding completion tracking instrumented with specific event names and properties per screen so you can identify where users drop off and which variant outperforms in a controlled test. The first-run experience ends not when the user creates an account but when they complete their first meaningful action -- the activation event that predicts retention -- and onboarding design is scoped to deliver users to that moment.

Mobile interaction patterns that exist because of physical constraints -- not conventions borrowed from desktop -- must be designed explicitly rather than discovered during development. Touch targets: minimum 44x44pt on iOS, 48x48dp on Android, with tap targets visually distinct from non-interactive elements so users do not tap expecting a response and receive nothing. Gesture-based navigation: swipe actions on list rows (left for delete/archive, right for mark-read or pin), pull-to-refresh with haptic feedback at the trigger point, pinch-to-zoom on media content, and long-press for context menus -- all specified in the design with gesture conflict resolution documented where two gestures share the same direction. Bottom sheet and modal drawer patterns for secondary content: half-sheet for quick actions, full-screen sheet for forms, drawer (navigation or filter) for content too dense for a modal. Skeleton screens for loading states: placeholder layouts that match the content shape, eliminating the layout shift when real content arrives and reducing perceived loading time compared to a spinner. Empty state and error state design for every screen that can have no data: first-time empty state (no data yet), filtered empty state (no results for this query), and offline/error state with a specific recovery action rather than a generic "something went wrong" message. Haptic feedback specification: notification, impact, and selection haptics tied to specific interaction events in the design handoff so developers implement the tactile feedback that makes iOS interactions feel native.

Cross-platform mobile design for apps built in React Native or Flutter means a shared design system with platform-specific overrides -- not identical designs for both platforms, and not two completely separate design processes. The shared foundation: design tokens (colour, typography scale, spacing, border radius, shadow elevation) defined in Figma Variables and exported to match the token format used by the development framework (React Native StyleSheet, Flutter ThemeData). Platform-specific overrides: navigation patterns (iOS tab bar vs Android bottom navigation rail, iOS navigation stack vs Android Material navigation), component variants (iOS-style pickers vs Android dropdown menus, iOS action sheets vs Android bottom sheets), and system font integration (SF Pro on iOS, Roboto on Android) -- with the override logic documented in the handoff so developers know which components need platform branching and which can use the shared implementation. Figma library structure: a shared component library for cross-platform elements, plus iOS and Android platform libraries for platform-specific variants, linked into page designs using Figma's component swapping. The handoff documentation explicitly separates shared implementation from platform-specific implementation, eliminating the developer ambiguity that produces "works on iOS but feels wrong on Android" -- the most common failure mode of cross-platform mobile development.