Mobile UI Design: A Complete Guide in Six Steps

Mobile UI design is the work of deciding how an app screen looks and behaves on a phone: the layout, the components, the type, the color, the motion and the states each element moves through. It is constrained by a small screen, an imprecise input device and a platform that already has rules.

This guide covers those constraints, the difference between the two platform design languages, the screen types nearly every app needs, dark mode, and a six-step process from strategy through to app store review.

What makes a phone screen different

• Size: roughly 360 to 430 points wide. Every element competes for the same narrow column, so priority has to be brutal.
• Input: a finger covers about 9 millimeters and obscures what it touches. Precision targets do not work.
• Reach: on a phone held one-handed, the comfortable zone is the lower two thirds of the screen. The top corners are the hardest to reach.
• Context: people use apps in motion, in bad light, with one hand and partial attention. Assume interruption at any step.
• Platform expectations: iOS and Android users have learned different navigation patterns, and violating them reads as a broken app rather than a distinctive one.

UX and UI, and why the order matters

UX decides what the screens are

UX work happens before any visual decision. It defines who the app is for, what jobs they need done, what the flow between screens is, and what the information architecture looks like. Its outputs are personas, user flows, a screen map and wireframes.

Get this wrong and the app is beautiful and unusable. No amount of interface polish fixes a screen that should not exist.

UI decides how those screens look and respond

UI work takes the approved structure and makes it concrete: the color palette, the type scale, the icon set, the component library, the spacing system, the motion, and every state each element can be in.

One person often does both jobs. They are still two stages, and running them in parallel is how projects end up redesigning the flow after the visual design is signed off.

iOS and Android are different design languages

Designing one interface and shipping it identically on both platforms is the most common mobile UI mistake. The two systems disagree on fundamentals.

• Navigation: iOS uses a bottom tab bar with a back affordance in the top left of each screen. Android uses a bottom navigation bar plus a system-level back gesture, so an in-app back arrow is often redundant.
• Design language: Apple's Human Interface Guidelines govern iOS, with the Liquid Glass direction introduced in the 2025 releases. Android follows Material Design 3, including dynamic color derived from the user's wallpaper.
• Minimum touch target: 44 by 44 points on iOS, 48 by 48 density-independent pixels on Android. Design to 48 and both are satisfied.
• Typography: San Francisco on iOS, Roboto on Android, both with platform type scales that respect the user's accessibility text size setting.
• Modals and sheets: iOS leans on sheets that slide from the bottom. Material has its own bottom sheet and dialog specifications with different dismiss behavior.
• Controls: switches, pickers, date entry and share actions all look and behave differently. Using the iOS versions on Android is immediately noticeable.

Both Apple and Google publish free official design kits for Figma. Start from those rather than rebuilding platform components, and your app will feel native without extra effort.

Touch targets and the thumb zone

• Minimum target: 48 by 48 pixels, with at least 8 pixels of space between adjacent targets. Small icon buttons packed into a row are the top cause of mis-taps.
• Primary actions belong in the lower half of the screen, where the thumb rests. A save button in the top right corner of a tall phone is a stretch every time.
• Destructive actions belong away from the thumb path, and behind a confirmation.
• Bottom navigation beats a top hamburger menu on a phone, because it is both reachable and always visible.
• Leave room for the system: the notch or dynamic island at the top, the home indicator and gesture area at the bottom. Content placed there gets covered or intercepted.
• Test one-handed, on the largest phone you support. Anything you have to shift your grip to reach is a design problem.

The screens nearly every app needs

Teams routinely design the happy path and improvise the rest. This is the list worth designing deliberately.

• Splash or launch screen, which should be near-instant and never a branding opportunity.
• Onboarding, ideally two or three screens, skippable, and only if it earns its place.
• Sign-up and sign-in, including social and passkey options, and the password reset path.
• Permission requests, asked in context at the moment the feature needs them rather than all at launch.
• Home or feed, which is the screen most people see most often and deserves the most iteration.
• Search, with recent queries, suggestions and a useful no-results state.
• List and detail, the pattern most of the app is built from.
• Forms and input, with the correct keyboard type per field and inline validation.
• Profile and settings, including account deletion, which app stores require to be reachable in-app.
• Checkout or payment, if the app transacts.
• Notifications and an activity view.
• The states nobody designs: empty, loading, offline, error, and the paywall. Each of these is a real screen a real user will hit.

The six steps

Step 1: Define the objective and the audience

Write down what the app is for in one sentence, who it is for, and what a successful session looks like. Name the single action that matters most, because the whole interface will be arranged around it.

Look at the two or three apps your users already use for adjacent jobs. Their conventions are your users' expectations, whether or not you like them.

Cut the feature list before you design

Every feature costs a place in the navigation, and the navigation is the scarcest resource on a phone. An app with three well-placed features beats one with nine buried in a menu.

Step 2: Map the flows and wireframe

Draw the screen map: every screen, and every route between them. Then wireframe each screen in grayscale, at real phone dimensions, on a real grid.

Keep it plain. Boxes for images, lines for text, every navigation label written out. The question at this stage is whether someone can complete the primary task in as few steps as possible, and color cannot answer it.

Count the taps to the main action. If it is more than three from launch, restructure before going further.

Step 3: Design the interface

Color, type and motion

• Color: one primary for actions, a small neutral scale for surfaces and text, and defined semantic colors for success, warning and error. Check every combination against a 4.5 to 1 contrast ratio.
• Type: use the platform type scale, and respect dynamic text sizing. A layout that breaks when the user raises their text size will break for a lot of users.
• Motion: short, 150 to 300 milliseconds, and functional. Motion should show where a screen came from or confirm that something happened, and nothing else. Honor the reduced-motion setting.

Layout and components

Build a component library rather than designing screens one at a time. Buttons, inputs, cards, list rows, navigation, sheets, toasts, each with every state defined: default, pressed, focused, disabled, loading, error.

Use a 4 or 8 point spacing scale and a consistent screen margin, usually 16 or 20 points. Consistent spacing is most of what makes an interface look finished.

Building this from scratch takes real time, and it is the part teams underestimate most. An on-demand design team or a design subscription is one way to get a full component set built without hiring for it.

Dark mode

Dark mode is now an expectation rather than a feature, and it is not a color inversion.

• Do not use pure black. A dark gray around 18 to 20 percent lightness reduces the harsh contrast against white text and lets you show elevation.
• Show depth with lighter surfaces rather than shadows, because shadows are close to invisible on a dark background.
• Desaturate the palette. Saturated colors that read well on white vibrate against dark backgrounds and become hard to focus on.
• Do not use pure white for body text. A light gray reads more comfortably.
• Recheck every contrast ratio. Passing in light mode says nothing about dark mode.
• Define both themes as tokens from the start. Retrofitting dark mode means touching every screen.

Step 4: Prototype

Link the screens, add the real transitions, and run the primary task on an actual phone rather than in a browser window. Figma, Framer and ProtoPie all handle this.

Interaction problems are invisible in a static mockup. Gesture conflicts, transitions that hide where you came from, and sheets that cover the field you are typing into all show up in the first minute of clicking through.

Test on the device, not the desktop

A screen that looks spacious at 200 percent zoom on a monitor can be cramped in the hand. Mirror the prototype to a phone before showing it to anyone.

Step 5: Test and iterate

Five users, one task each, thinking aloud, no instructions. Watch where they tap, where they hesitate, and what they expected to happen.

Give them the task, not the route. "Buy a ticket for Friday" tells you something. "Tap the button in the bottom right" tells you nothing.

Fix the problems that stopped people completing the task first. Preference comments are the least reliable data in the room.

Step 6: Prepare for launch and review

• Accessibility: contrast checked, dynamic type supported, every control labeled for VoiceOver and TalkBack, and the primary flow completable with a screen reader.
• Performance: a launch screen that appears immediately, skeleton loaders instead of spinners, and images sized for the device.
• Offline and error states: designed, not improvised. Assume the network drops mid-task.
• Store assets: icon at every required size, screenshots for each device class, and a preview video if the flow needs showing.
• Review requirements: both stores reject apps for missing account deletion, unclear permission usage, dark-pattern subscription screens and broken sign-in. Read the current guidelines before submitting, because they change.
• Post-launch: instrument the funnel, then keep iterating. The first version is a hypothesis.

Where to study real mobile interfaces

• Mobbin: screens and full flows captured from shipped iOS and Android apps, searchable by pattern. The most useful reference of the set, because everything in it was actually built.
• Apple Human Interface Guidelines and Material Design 3: the source of truth for platform behavior, and both are readable.
• Dribbble and Behance: visual range and trend awareness, with the caveat that much of it was never built and would collapse under real content.
• Figma Community: the official Apple and Material design kits, plus free mobile UI kits worth starting from.
• The apps on your own phone: open the three you use daily and look at how they handle empty states, errors and onboarding. That is where craft shows.

FAQ