How to Design a Mobile App: End-to-End Process

Most mobile app design projects fail at the same step: jumping into screen design before understanding the user's flow. You end up with beautiful individual screens that don't connect into a coherent experience. Start with flow, build screens from there.

Start with user flows, not screens

A user flow is a diagram of the path a user takes to complete a goal. Before opening Figma, map the key flows on paper or in a simple diagramming tool.

For each primary task in your app, answer:

• Where does the user start?
• What decision points do they hit?
• What are the paths to success?
• What are the failure states?

A flow for "user resets their password" might be: Login screen → Tap "Forgot password" → Enter email screen → Success confirmation → Check email → Click link → New password screen → Back to app.

This seems obvious, but most designers skip it and then discover mid-project that they've designed the wrong screens. Each node in your flow becomes a screen. Map the flows first, then the screens emerge naturally.

Setting up Figma for mobile

Use real device dimensions. Don't invent sizes.

iOS:

• iPhone 15 Pro: 393 × 852px
• iPhone SE (3rd gen): 375 × 667px (smallest current iPhone)
• iPhone 15 Pro Max: 430 × 932px

Android:

• Pixel 8: 412 × 892px (standard Android reference frame)
• Samsung Galaxy S24: 360 × 780px

Use status bar heights: iOS safe area top is 59px on iPhone 15 Pro (with dynamic island). Safe area bottom is 34px. Design your content to avoid these areas for interactive elements.

Figma has a device frame section in the Community (search "iOS 17 UI Kit" or "Material 3 Design Kit") — use these for platform-accurate spacing and component references.

Platform-specific components

Designing natively for each platform isn't always necessary (React Native and Flutter apps can share designs), but understanding platform conventions prevents you from creating confusing UX.

iOS (Human Interface Guidelines):

• Use SF Symbols for icons — they scale, respect accessibility text sizes, and feel native. The SF Symbols app (free from Apple) lets you browse all 6,000+ symbols. In Figma, the "SF Symbols 5" community file gives you access.
• Navigation: top navigation bar with back button on the left, title centered, optional right action
• Tab bars sit at the bottom, typically 5 items max
• System fonts: SF Pro (download from developer.apple.com)
• Minimum touch target: 44 × 44px

Android (Material Design 3):

• Use Material Symbols for icons (available as a variable font on Google Fonts)
• Navigation: bottom navigation bar (up to 5 items) or navigation rail for tablets
• System font: Roboto, or your app's custom font
• Minimum touch target: 48 × 48dp
• Material 3 components have specific shape and color token systems — the official Figma kit from Google is the best reference (search "Material 3 Design Kit" in Figma Community)

If you're building one design for both platforms, use a neutral design that feels native on neither and terrible on neither. Don't use iOS-specific navigation patterns in an Android app.

Try Figma Free

Designing for gesture navigation

Both iOS and Android have moved to gesture-based navigation. No more hardware back buttons on most Android devices. No more home buttons on current iOS.

Design considerations:

• Back gestures: Users swipe from the left edge on iOS to go back. Don't put interactive elements close to the left edge on detail screens.
• Home indicator area: The bottom 34px on iPhone (with gesture indicator) should be clear of interactive elements. Use safe area padding.
• Swipe-to-dismiss: Modals and sheets can be dismissed by swiping down. If you have a confirmation modal that shouldn't be accidentally dismissed, lock this behavior.
• Interactive areas at bottom: Floating action buttons and bottom sheets need to account for the home indicator. Add 34px bottom padding to anything that sits above the gesture area.

Prototyping touch interactions

Figma handles basic touch flows — tap to navigate, basic transitions. For simple apps, this is sufficient for usability testing.

For gesture-heavy interactions (drag to reorder, swipe cards, pinch to zoom), Figma's prototyping falls short. This is where ProtoPie becomes valuable.

ProtoPie handles:

• Swipe gestures with momentum
• Drag interactions with physics
• Multi-finger gestures
• Conditional responses based on gesture direction or speed
• Haptic feedback triggers (for iOS developer review)

A ProtoPie prototype that simulates real touch behavior is significantly more effective for mobile usability testing than a tap-only Figma prototype. Users interact with it naturally rather than accommodating the limitations of the prototype.

Marvel is a simpler alternative for basic app prototyping — it has direct upload-to-device for testing on physical hardware, which is underrated for mobile. Viewing a prototype on an actual phone is always better than viewing it in a browser.

Try Marvel Free

Handing off to mobile developers

Mobile developers need platform-specific specs:

For iOS:

• Dimensions in points (not pixels) — 1x, 2x, 3x assets
• Safe area insets explicitly called out
• Specify whether animations use UIKit or SwiftUI
• Accessibility label text for every interactive element

For Android:

• Dimensions in dp (density-independent pixels)
• Which Material 3 components are being used
• Elevation values for shadows
• Asset export in vector format where possible (SVG → vector drawable)

In Figma Dev Mode, set the platform to iOS or Android in the code panel — it'll show you UIKit/SwiftUI or Jetpack Compose code snippets alongside the specs.

Mark your export assets: icons should be exported as SVG where possible, images as 2x and 3x PNG for iOS, and as appropriate density buckets for Android (mdpi, hdpi, xhdpi, xxhdpi).

The cleaner your Figma file, the faster the developer can work. Named components, semantic color variables, and explicit safe area annotations turn days of back-and-forth into hours.