Mobile App Design

Mobile app design is a different craft from web design, and pretending otherwise is how bad apps get shipped. The conventions that make iOS feel like iOS and Android feel like Android aren’t arbitrary; users move through your app based on muscle memory built from every other app on their device. We respect that by default, and we override it only where the product genuinely earns it — which is less often than brand teams usually think.

Our mobile design process is structurally similar to our web process, with a few important differences. We prototype on-device earlier, because screens that look right in Figma at 400% zoom are often wrong on a phone in a coffee shop. We design for the full state space — loading, empty, error, offline — rather than treating edge states as engineering’s problem. And we design the platform-specific surfaces (system sheets, share extensions, widgets, App Intents) as part of the product rather than as post-launch additions.

We work in Figma with component libraries that mirror the engineering architecture: if the app is React Native, the design system is structured the way the engineers will build it. If the app is native Swift or Kotlin, the components anticipate SwiftUI or Compose patterns. This isn’t a cosmetic choice; it’s the difference between a design system the engineering team can implement cleanly and one that requires a translation layer on every ticket.

The brand’s single voice across iOS and Android matters, but not more than the platform-specific details that let the app feel at home on each device. The tension between those two is the interesting part of the job. We resolve it deliberately, in writing, per screen, rather than defaulting to “design it once and ship the same thing everywhere.”