Designing a mobile app well requires understanding both the craft of UI/UX design and the specific constraints of mobile platforms. Apps that ignore platform conventions feel wrong to users, even if users can’t articulate why. Apps designed without performance constraints often look great in Figma and feel sluggish in production.

This guide covers the key decisions and principles for designing mobile apps that ship and perform.

The Design Foundation: Understand Your Platform

iOS and Android have distinct design systems. Designing for one while ignoring the other is a mistake that users notice.

iOS follows Human Interface Guidelines (HIG). Apple’s HIG defines how iOS apps should look, feel, and behave. Key conventions: bottom navigation tabs, swipe-to-go-back, large titles on scroll, and a preference for clear over cluttered. iOS users expect apps to feel “native” — gestures should work as expected, navigation should be intuitive without instruction.

Android follows Material Design 3. Google’s Material You system emphasises dynamic colour, adaptive layouts, and clear hierarchy. Navigation drawers, floating action buttons, and the back button behaviour differ from iOS. Material Design 3’s “expressive” design direction leans into colour and personalisation.

When building for both platforms, decide whether you’re designing once (with platform-specific adaptations) or twice (fully native designs per platform). For most apps, designing once with platform variants for key interactions is the right balance. Full platform-native designs take significantly more time and may not justify the investment unless your users are highly platform-sensitive.

Information Architecture for Mobile

Mobile information architecture has harder constraints than desktop. Screen size limits how much you can show. Touch targets need to be large enough to use accurately. Navigation adds to cognitive load.

Prioritise ruthlessly. What are the two or three things users will do most often? Those should be immediately accessible. Everything else can be behind one tap.

Navigation patterns:

  • Tab bar (iOS) / Bottom navigation (Android): For 3–5 primary sections. The standard for most consumer apps.
  • Navigation drawer: For apps with many sections or secondary navigation that doesn’t need to always be visible.
  • Top navigation: Common in web, less common in native mobile. Be intentional if you use it.

Don’t put everything in the menu. Navigation menus that contain 15 items reflect poor prioritisation, not comprehensive feature access. Audit what actually gets used and surface it; archive what doesn’t.

Designing for Touch

Touch has different affordance requirements than mouse/pointer:

Minimum touch target size: 44×44 points (iOS) / 48×48dp (Android). Smaller touch targets cause errors. This applies to buttons, links, and any interactive element. Many designs look right in Figma and fail this test in production.

Thumb zones matter. The bottom two-thirds of a phone screen is comfortably reachable with one thumb. Primary actions should live here. Destructive actions (delete, log out) should be harder to reach accidentally.

Swipe gestures are discoverable only if users know they exist. Don’t rely on swipe-only interactions for primary functionality unless you teach them. Swipe-to-delete in a list is well-established; custom swipe gestures for non-standard actions need onboarding.

No hover states. Hover state design from web doesn’t translate to touch. Redesign any pattern that relies on hover for information disclosure.

Typography on Mobile

Small screens require different typographic choices than desktop:

  • Body text minimum 16sp/pt. Smaller text causes users to zoom, which breaks your layout.
  • Line length: 45–75 characters. Long lines are harder to track across a small screen. Narrow your content columns.
  • Sufficient line height. 1.4–1.6x the font size for body text. Tight line height is harder to read on a small screen.
  • System fonts perform better. San Francisco (iOS) and Roboto (Android) load instantly. Custom fonts add latency. Use custom fonts only when brand requirements justify it.

States and Edge Cases

Every screen has more states than the happy path. Design all of them:

  • Empty state: What does the screen look like before the user has any data?
  • Loading state: What shows while data is fetching?
  • Error state: What shows when the network request fails?
  • Partial data: What if the user has done some things but not others?
  • Extreme content: What if the user’s name is 60 characters long? What if a list has 500 items?

Designs that only show the happy path create surprises during development. Design the edge cases before handing off — it’s much cheaper to solve them in Figma than in code.

Performance-Aware Design

Design choices have performance implications:

  • Image sizes. Large images slow down load times. Design with appropriate image sizes in mind. Specify compression settings in handoff.
  • Animation. Complex animations that run at 60fps on your MacBook may drop frames on a mid-range Android device. Test animations on target hardware.
  • Font loading. Every custom font adds a network request. Minimise font variants (weights, styles).
  • Skeleton screens over spinners. Skeleton loading states feel faster than spinners because they communicate the shape of what’s coming.

Accessibility

Mobile accessibility is non-negotiable for consumer apps:

  • Dynamic type support. iOS and Android both allow users to set their preferred text size. Designs must accommodate larger type sizes without breaking layouts.
  • Screen reader support. VoiceOver (iOS) and TalkBack (Android) read elements aloud. Every interactive element needs a meaningful label. Images need alt text.
  • Colour contrast. WCAG AA minimum: 4.5:1 for normal text, 3:1 for large text. Test with a contrast checker.
  • Colour-independent information. Don’t rely on colour alone to communicate status (success/error/warning). Use icons and labels too.

Handoff to Developers

Good handoff prevents the most common design-to-development translation errors:

  • Export designs from Figma with auto-layout so engineers understand spacing and responsive behaviour.
  • Document component states — all variants of each component (default, hover, active, disabled, error).
  • Specify interactions — transitions, animations, gesture behaviours.
  • Create an asset export spec — which images need which formats and sizes (@1x, @2x, @3x for iOS; mdpi through xxxhdpi for Android).

Mobile app design is a discipline that rewards depth. Platform conventions, touch ergonomics, performance constraints, and accessibility requirements all interact. Apps that get these right feel effortless; apps that don’t feel laboured even when the underlying functionality is solid.

If you’re building a mobile app and want a team that handles both design and development, talk to us about your project.