Mobile app design encompasses the UI/UX principles, interaction patterns, and visual guidelines that create intuitive, accessible, and engaging experiences on smartphones and tablets. Unlike desktop design, mobile demands thumb-friendly layouts, gesture-driven interactions, and awareness of constraints like limited screen space and variable network conditions. Effective mobile design balances platform conventions (iOS Human Interface Guidelines with Liquid Glass in iOS 26, Material Design 3) with user expectations for smooth animations, instant feedback, and one-handed usability—while increasingly incorporating AI-adaptive interfaces and privacy-by-design principles to meet the rising bar users set in 2026.
24 tables, 224 concepts. Select a concept node to jump to its table row.
Table 1: Core UX Principles
The foundational rules that separate a mobile app people enjoy from one they delete. Most trace back to the physical reality of a phone — a thumb reaching across a small screen, held one-handed, on a flaky connection — so principles like thumb-zone placement, generous touch targets, immediate feedback, and forgiving input keep showing up. Get these right and everything downstream feels easier.
| Principle | Example | Description |
|---|---|---|
Primary actions within bottom 1/3 of screen | • Place critical buttons in the natural thumb reach area (lower center) to minimize hand strain • avoid top corners for frequent actions. | |
Show 3-5 menu items initially, hide advanced options | Reveal complexity gradually through layered navigation or expandable sections to prevent overwhelming users on small screens. | |
Minimum 44×44px (iOS) or 48×48dp (Android) | Ensure buttons and interactive elements meet minimum tap target sizes with adequate spacing (8-12px) to prevent accidental taps—WCAG 2.2 sets 24×24 CSS px minimum. | |
Hero image + CTA above fold | • Display the most important content first without scrolling • use visual hierarchy to guide attention through size, contrast, and placement. | |
Button color change + haptic on tap | Provide instant visual, auditory, or haptic confirmation for every interaction to reassure users their action was registered. | |
Auto-format phone numbers, inline validation | Reduce user effort with smart defaults, autocomplete, and real-time error correction rather than punishing mistakes. | |
Surface "add to cart" shortcut based on browse history | Anticipate user intent using behavioral patterns—AI can correctly predict the next user step 68% of the time, reducing hesitation and taps. | |
Skeleton screens during load; spinner for 1-3s, progress bar for 3s+ | • Use skeleton loaders, progress indicators, and optimistic UI to make waits feel shorter • follow the 1-3-10 rule: no indicator <1s, spinner 1-3s, progress bar 3s+. | |
Show location-based results, adaptive UI by time of day | Leverage device sensors (GPS, orientation) and user context (time, activity) to surface relevant content and features proactively. | |
Fixed bottom tab bar across screens | • Maintain predictable navigation patterns throughout the app • users should always know where they are and how to return. | |
Explain "why" before requesting camera permission | Embed transparent data usage and user controls from the start—explain permission requests contextually and make privacy settings easy to find. |
Table 2: Navigation Patterns
How users move around your app, and the choice has real consequences for discoverability. A bottom tab bar keeps 3-5 destinations within thumb reach and always visible, while a hamburger menu hides options to reduce clutter — the recurring trade-off in this table. Match the pattern to your structure: flat and frequently used wants tabs; deep and occasional can tolerate a drawer.
| Pattern | Example | Description |
|---|---|---|
[Home] [Search] [Profile] at screen bottom | • Most common pattern for 3-5 top-level destinations • keeps primary navigation within thumb reach and always visible. | |
Three-line icon opens slide-out menu | • Slide-in side panel for secondary navigation or feature-rich apps • reduces clutter but hides options, lowering discoverability. | |
Horizontal swipeable tabs below header | • Good for 2-6 related views of the same content type (e.g., News sections) • supports swipe gestures for quick switching. | |
Modal panel slides up from bottom | • Temporary overlay for contextual actions or multi-step flows • dismissible and less intrusive than full-screen modals. | |
Circular [+] button for primary action | • Promotes the single most important action (e.g., Create, Compose) • should trigger only one consistent function app-wide. | |
Swipe back from left edge to return | iOS-style edge swipes or Android back gestures reduce reliance on visible buttons, maximizing content space. | |
Drill-down through Home > Category > Detail | • Linear parent-child structure with back navigation • ideal for deep content like settings or product catalogs. | |
Frequently used features surface in home section | Interfaces that reorder or surface navigation items based on individual usage patterns—helps power users reach frequent destinations faster. | |
Return to home hub after each task | • User completes a task and returns to central hub (e.g., camera app) • suits task-focused or utility apps. |
Table 3: Touch Gestures & Interactions
Fingers are the only input device, so the gesture vocabulary is the language of mobile interaction. Users arrive already fluent in tap, swipe, pinch, and long-press from every other app — which means honoring those expectations matters as much as inventing anything new. Note how several rows flag discoverability: hidden gestures like double-tap need a visible backup for critical actions.
| Gesture | Example | Description |
|---|---|---|
Select button, open link | • Primary selection gesture • should provide instant feedback (color change, ripple effect) to confirm action. | |
Navigate between screens, reveal actions | • Horizontal swipe for pagination/navigation • vertical swipe for scrolling or triggering actions (e.g., dismiss notification). | |
Drag down from top to reload content | • Standard pattern to refresh data in feeds or lists • originated by Tweetie (later Twitter), now universally expected. | |
Swipe left to delete, right to archive | • Reveals action buttons behind list items • limit to 2-3 actions per side to avoid overwhelming users. | |
Show context menu, enter edit mode | • Reveals hidden options or alternative actions • requires ~500ms hold and should display visual feedback (e.g., lift animation). | |
Zoom into image or like/favorite | • Quick zoom in/out or like/favorite action • avoid for critical functions as it's less discoverable than single tap. | |
Two-finger pinch on map/image | • Intuitive zoom control for media and maps • essential for content that benefits from detail inspection. | |
Reorder list items, move files | • Allows content rearrangement by pressing and dragging • requires clear visual feedback (lift animation, drop zones). | |
Two fingers rotate image or map | • Two-finger rotation for orienting media or maps—provide visual angle feedback • less common so combine with visual affordance. | |
Swipe from left edge to go back | • System-level back navigation gesture on iOS and Android • respect this gesture to avoid conflicts with custom gestures. | |
Peek/pop preview or quick actions (iPhone X era) | • Pressure-sensitive tap on older iPhones (up to iPhone 11 Pro) • replaced by long-press Haptic Touch on iPhone 12+; do not rely on it. |
Table 4: Layout Patterns & Responsive Design
How content is arranged on screen and how that arrangement flexes as the screen grows. The single-column stack is mobile's default, but cards, grids, and masonry layouts organize denser content — and the responsive patterns near the end (column drop, mostly fluid, layout shifter) describe how a design gracefully reshapes itself from phone to foldable to tablet.
| Pattern | Example | Description |
|---|---|---|
Vertical stack of cards or content blocks | • Default mobile pattern • 100% width utilization with vertical scroll ensures content fits all screen sizes without horizontal clipping. | |
Tappable cards containing title + image + CTA | • Encapsulates related content in tappable containers • provides clear boundaries and shadow/elevation for depth. | |
Image gallery with 2 items per row | • Displays multiple items efficiently • common for product listings, photo galleries—use 8px+ gutters for breathing room. | |
Scrollable rows with icon + text | • Efficient for scannable content (emails, contacts) • supports swipe actions, separators, and section headers for organization. | |
Pinterest-style staggered cards | • Variable-height items create organic, dynamic layouts • ideal for user-generated content with unpredictable dimensions. | |
3 columns → 2 → 1 as screen narrows | • Responsive pattern where columns stack vertically at narrow widths • maintains content order without reflow. | |
Content maxes out at 1280px, margins grow | • Grid scales fluidly until max-width, then adds side margins • prevents overstretched layouts on tablets/desktops. | |
Hidden side menu revealed via button | • Navigation or secondary content slides in from edge • maximizes content space but hides features until revealed. | |
Two-pane view on unfolded, single-pane when folded | Adapt layout for folded / unfolded / table-top modes—use WindowSizeClass API to switch between single-column (folded) and list-detail (unfolded) views. | |
Content reorders across breakpoints | • Most complex pattern • layout fundamentally changes at breakpoints (e.g., sidebar moves from side to bottom). |
Table 5: Typography & Readability
Text is most of what users actually read on a phone, often at arm's length in bright sunlight, so the numbers here matter. Body text at 16px and up, generous line height, a clear type scale, and enough contrast keep content comfortable — and the 16px input-field rule has a sneaky practical payoff: it stops iOS from auto-zooming when a field gains focus.
| Principle | Example | Description |
|---|---|---|
16-18px for body, 14px minimum | • Use at least 16px for primary text to ensure readability without zooming • 14px absolute minimum for secondary content. | |
Minimum 16px to prevent iOS auto-zoom | Use at least 16px for input fields on iOS to prevent automatic zoom-in when focused, disrupting user flow. | |
line-height: 1.5-1.6 for body text | • Set line spacing to 1.5-1.6× font size for comfortable reading • tighter spacing (1.2-1.3×) acceptable for large headings. | |
4.5:1 for normal text, 3:1 for large text (18px+) | • Meet WCAG AA standards for text contrast • higher contrast (7:1) recommended for mobile outdoors and AAA accessibility. | |
H1: 28-32px, H2: 24px, H3: 20px, Body: 16px | Establish clear hierarchy with consistent size jumps (e.g., 4px increments or 1.25× ratio) to guide attention. | |
50-75 characters per line ideal | • Limit line width to 50-75 characters on larger screens • single-column mobile naturally constrains this. | |
Use font weights (400, 600, 700) over italics | • Vary font weights for emphasis rather than italics or underlines • bold (700) for key terms, medium (600) for subheadings. | |
One sans-serif (headings) + one serif (body) | • Limit to 2-3 fonts maximum • pair fonts with distinct personalities but harmonious proportions for visual interest. | |
-0.02em for large headings, 0 for body | • Slightly tighten spacing on large text, keep neutral on body • excessive tracking reduces readability on small screens. |
Table 6: Color & Accessibility
Color carries meaning, but it can't carry it alone — that's the thread running through this table. WCAG contrast ratios keep text legible, semantic tokens make theming and dark mode painless, and the repeated reminder to pair color with icons or text ensures the roughly 8% of users with color blindness aren't left guessing what red means.
| Principle | Example | Description |
|---|---|---|
4.5:1 normal text, 3:1 large text (18px+) | • Ensure text/background contrast meets WCAG AA standards • aim for AAA (7:1 normal, 4.5:1 large) for critical content. | |
Use icon + color for error states | • Never rely solely on color to convey information • combine with text labels, icons, or patterns for accessibility. | |
Dark background (black/gray) + light text | • Offer dark theme for low-light usage and OLED battery savings (15-30%) • reduce saturation in dark mode to maintain readability. | |
--color-error: #B00020, --color-success: #2E7D32 | Use named semantic tokens (error, success, warning) rather than raw hex values—makes theme changes instant and ensures consistent meaning across UI. | |
Blue #2196F3 for CTAs, links | • Choose one bold accent color for primary actions • ensure it meets contrast requirements against all background colors. | |
Avoid red-green combinations | • Design for protanopia/deuteranopia (8% of males) • use tools like Stark to test for color blindness accessibility. | |
Green success, yellow warning, red error | • Use consistent color semantics for states • combine with icons/text since color perception varies by culture and accessibility needs. | |
Translucent frosted-glass card over blurred background | • Frosted glass effect using backdrop-filter: blur or Apple's Liquid Glass material (iOS 26) • ensure sufficient contrast between foreground text and background—accessibility at risk if ignored. | |
Raised button with 2dp shadow | Use shadows and elevation (not just color) to establish depth and hierarchy, especially important in dark mode. | |
3px blue outline on focused element | • Provide clear, high-contrast focus rings for keyboard/switch navigation • never remove default focus styles without replacement. |
Table 7: Spacing & Grids
Consistent spacing is what makes an interface feel calm and intentional rather than haphazard. The 8-point grid is the backbone — sizing every margin, padding, and gap in multiples of 8 — which scales cleanly across screen densities and stops designers from sprinkling arbitrary values. The rest of these rules build on it: column grids, gutters, and minimum gaps between tap targets.
| System | Example | Description |
|---|---|---|
Margins, padding in 8px increments (8, 16, 24, 32) | Design all spacing in multiples of 8px for consistency and easier scaling across screen densities (xxhdpi, etc.). | |
16-20px side margins on mobile | • Apply 16px minimum horizontal padding to prevent content from touching screen edges • 20-24px provides more breathing room. | |
4 columns (mobile), 8 (tablet), 12 (desktop) | • Use 4-column grid on phones, 8-12 on tablets/desktop • helps maintain alignment and proportional scaling. | |
Minimum 8px gap between tap targets | Maintain at least 8px separation between interactive elements to prevent accidental taps and improve accuracy. | |
Consistent vertical spacing between sections | • Use multiples of base unit (8px) for vertical gaps • e.g., 24px between sections, 16px between components. | |
12-16px internal padding for buttons/cards | Internal padding (space inside elements) should be 12-16px to keep text from touching edges of containers. | |
16px gaps between grid columns | • Space between columns (gutters) typically 16-24px • provides visual separation without fragmenting content. | |
Use 4, 8, 12, 16, 20, 24... increments | • Finer granularity than 8-point • allows 4px adjustments for tighter designs while maintaining systematic spacing. |
Table 8: Icons & Visual Elements
Icons and imagery do a lot of communicating in the limited space of a phone screen. Consistent sizing keeps them crisp, pairing icons with short labels fixes their notorious discoverability problem, and the imaging rows cover the practical side — aspect ratios, retina assets, and modern formats like WebP that shrink files without visible loss. Empty-state and placeholder visuals round it out by making absence and loading feel intentional.
| Principle | Example | Description |
|---|---|---|
24×24dp standard, 16-48dp range | • Use 24×24dp as base size • scale to 16dp (inline), 32dp (prominent), or 48dp (hero) maintaining pixel-perfect alignment. | |
Tab bar with icon + text below | • Combine icons with short text labels (1-2 words) for clarity • icons alone have low discoverability for unfamiliar features. | |
1024×1024px master, rounded square | • Create 1024×1024px master (iOS) or 512×512px (Android) • avoid transparency, use simple/recognizable shapes, no text. | |
24×24px icon inside 48×48px button | • Extend interactive area beyond visible icon using padding • 48×48dp minimum tap target even if icon is 24×24dp. | |
16:9 landscape, 4:3 portrait, 1:1 square | • Choose consistent aspect ratios for images • 16:9 for banners/videos, 1:1 for avatars/thumbnails, 4:3 for product photos. | |
WebP/AVIF format, 2x retina resolution | • Serve @2x/@3x images for high-DPI screens • use WebP or AVIF formats for 30-50% smaller files than PNG/JPG. | |
Friendly graphic + helpful message + CTA | • Use welcoming visuals when no content exists • guide users on what to do (e.g., "Add your first item"). | |
Gray boxes during load, fade to real content | • Display skeleton screens or blurred thumbnails while loading • maintains layout and reduces perceived wait time. |
Table 9: Buttons & Interactive Elements
The tappable controls users act through, each with its own job. Visual hierarchy is the organizing idea — one bold primary button per screen, quieter secondary styles for everything else — and the rest covers the selection controls (toggles, checkboxes, radios, segmented controls) along with the sizing and state rules that keep them comfortable to hit and obvious to read.
| Component | Example | Description |
|---|---|---|
Solid fill, high contrast, bold label | • Most important action on screen • use bold color (brand primary), one per screen to avoid decision paralysis. | |
Outlined or ghost style, less prominent | • Lower-priority actions • use outline or text-only style to visually de-emphasize compared to primary button. | |
Minimum 44×44px (iOS), 48×48dp (Android) | • Ensure buttons meet minimum tap target sizes • 48-56dp height is comfortable for thumbs across most hand sizes. | |
"Add to Cart" (action-oriented) | Use clear, action-oriented verbs (Add, Send, Delete) instead of vague labels (OK, Submit) to set expectations. | |
Default → Pressed → Disabled → Loading | • Design distinct visual states for all interactions • disabled buttons should be dimmed + non-interactive; loading state shows spinner inside button. | |
Sliding pill with on/off states | • Binary on/off control • change takes immediate effect without confirmation (unlike checkbox in forms). | |
Two-option toggle for view switching | • Mutually exclusive 2-5 options displayed inline • commonly used for filtering (List/Grid) or scope selection. | |
Square box with checkmark when selected | • Multi-select input • minimum 44×44px tap target, clear selected state (checkmark or fill), label to the right. | |
Circular button, one selectable per group | • Single-select from group • show all options (3-6 max), use dropdown if more options to save space. | |
Circular button with icon, bottom-right | • Represents primary app action (Create, Compose) • positioned above content, 56×56dp (regular) or 40×40dp (mini); Extended FAB adds text label. |
Table 10: Forms & Input Fields
Typing on a phone is tedious, so good form design is really about reducing how much the user has to do. Full-width fields, the right contextual keyboard, autofill, smart defaults, and breaking long forms into steps all chip away at friction — and inline validation that catches errors as you go beats a wall of red after you hit submit. Small touches like persistent labels and biometric login add up to far higher completion.
| Component | Example | Description |
|---|---|---|
Label → Input box → Helper text/error | • Structure as label (above) → field → helper text • avoid left-aligned labels on mobile (reduces usable width). | |
Full-width fields (100% screen width) | Use full-width inputs on mobile to maximize space and reduce horizontal scrolling or awkward partial widths. | |
type="tel" for phone, type="email" for email | • Trigger contextual keyboards with HTML input types • numeric keypad for numbers, @ shortcut for email, etc. | |
autocomplete="email" for browser autofill | Use autocomplete attributes to enable password managers and browser autofill, reducing typing effort. | |
Real-time feedback as user types | • Validate fields as user completes them (onBlur), not while typing • show green checkmark for valid input. | |
Red text below field: "Email format invalid" | • Apply the Avoid-Explain-Resolve framework: what to check, what happened, and what to do next • never use generic "Invalid input." | |
Face ID / Touch ID prompt after first login | • Offer biometrics after first successful login as opt-in shortcut • always provide PIN/password fallback; data never leaves device. | |
Pre-fill country based on location | • Reduce input effort with intelligent defaults • pre-select common options or use device data (time zone, location). | |
Multi-step wizard with progress indicator | • Break long forms into 2-5 steps with progress bar • reduces overwhelming feeling and improves completion rates. | |
Related fields in visual groups (border/spacing) | Use visual grouping (spacing, dividers, cards) to organize related fields and reduce cognitive load. | |
autocapitalize="words" for names | • Control capitalization behavior • capitalize sentences, words (names), or disable for usernames/emails. |
Table 11: UX Writing & Microcopy
The tiny bits of text — button labels, error messages, empty states, tooltips — that quietly shape whether an app feels clear or confusing. The recurring lesson is specificity: "Send message" beats "Submit," and an error that says what happened and what to do next beats "Something went wrong." A couple of memorable frameworks here, Avoid-Explain-Resolve and the 3 Cs, give you a repeatable way to write copy that actually helps.
| Technique | Example | Description |
|---|---|---|
"Send message" not "Submit"; "Create account" not "OK" | Use action verbs that describe the outcome, not the system operation—removes ambiguity and sets user expectations. | |
"Your card was declined. Check the billing address or try a different card." | • Apply the Avoid-Explain-Resolve framework: what to check → what happened → what to do next • Generic "Something went wrong" fails all three | |
"No projects yet. Create one to organize your work. [Create project]" | • Three-part structure: what's empty + why + clear CTA • celebrate positive empty states (inbox zero) rather than showing a blank or sad state. | |
Persistent label above field + format hint inside | • Labels must always be visible (never as disappearing placeholder) • placeholders show format examples, not instructions. | |
"Uploading your file (45%) — about 30 seconds left" | • For actions >3s, show progress and time estimate • for long operations, let users leave with "We'll email you when it's done." | |
"✓ 3 invitations sent. Check your email." | Provide specific, immediate feedback—"✓ Message sent" beats "Done." Include next steps where relevant. | |
Info icon (ⓘ) reveals: "Your changes save automatically every 30s." | • Under 2 sentences, lead with key point, plain language • don't use for critical info users need to see—put that in the main interface. | |
"Syncing your data. Almost there!" (not "System processing synchronization") | Follow the 3 Cs: Clear (no re-reading needed), Concise (every word earns its place), Contextual (tone matches user's emotional state). | |
"Delete project" with "This can't be undone." | • Name the specific object being destroyed ("Delete project" not "Delete") • state consequences clearly—no vague "Are you sure?" dialogs. | |
"Tell us about yourself — this personalizes your experience. (2 of 3)" | • Show benefit not just feature; state steps and time upfront • always include "Skip for now"—forced onboarding frustrates users. |
Table 12: Navigation & Wayfinding
Where the previous navigation table covered overall structure, this one is about the smaller signposts that help users know where they are and how to get around. Back buttons, search bars, badges, breadcrumbs, and page-indicator dots all answer the same quiet question — "where am I, and how do I move from here?" — and getting them right keeps people oriented inside deep or content-heavy apps.
| Component | Example | Description |
|---|---|---|
< Back or left-pointing arrow in nav bar | • Standard return navigation • position top-left (iOS convention) or use system back gesture/button (Android). | |
Persistent top bar or icon that expands | • Provide prominent search access • auto-suggest results after 1-3 characters, support voice input when appropriate. | |
Red number badge on tab icon | • Indicate unread count or new content • use sparingly to avoid notification fatigue, clear badge on view. | |
Bottom sheet with filter options + apply button | • Use modal bottom sheet for filters on mobile • show active filter count badge, allow clear-all action. | |
● ● ○ below horizontal scroll | • Show current position in paginated content (onboarding, carousels) • limit to 5-7 pages max for clarity. | |
Home > Category > Product | • Linear path indicator showing current location • tappable segments allow jumping back multiple levels. | |
Open specific product page from notification | • Support universal links to navigate directly to content • maintain back stack so user can navigate upward. | |
Long-press reveals Copy | Share | Delete | • Display action menu on long-press • limit to 3-5 most common actions, use icons + labels for clarity. |
Table 13: Feedback & Loading States
Waiting feels shorter when the app shows it's working, and these patterns manage that perception. Skeleton screens and progress indicators fill the gap during loads, optimistic UI makes actions feel instant by updating before the server confirms, and toasts, snackbars, and haptics confirm that something happened — with empty and error states catching the moments when there's nothing to show or something went wrong.
| Pattern | Example | Description |
|---|---|---|
Gray placeholder mimicking final layout | • Content placeholder during load • reduces perceived wait time vs. blank screen/spinner by showing structure immediately. | |
Circular rotating indicator | • Indeterminate loader when duration is unknown • use for quick operations (<3 seconds) to avoid abandonment. | |
Horizontal bar filling 0-100% | • Determinate loader showing completion percentage • use for uploads/downloads to set user expectations. | |
Show "Message sent" immediately, retry if fails | • Update UI before server confirms to feel instant • roll back and show error if operation fails. | |
Brief message at bottom: "Item saved" | • Temporary (3-5s) non-blocking alert for low-priority feedback • dismissible, doesn't interrupt user flow. | |
"Deleted" with [UNDO] button for 5 seconds | • Temporary message with optional action (Undo, Retry) • appears at bottom, auto-dismisses after timeout; don't auto-dismiss errors. | |
Subtle vibration on button tap or error | • Use tactile vibration to confirm actions or alert • keep duration short (10-30ms), align with visual feedback. | |
Illustration + "No items yet" + CTA | • Friendly message when no content exists • explain why it's empty and provide action to populate (e.g., Add button). | |
Icon + "Something went wrong" + Retry button | • Actionable error messages following Avoid-Explain-Resolve: what happened, why (if known), how to resolve • error states must not auto-dismiss—they need action. | |
Drag down + release to reload | • Standard manual refresh pattern • show loading spinner at top during fetch, animate content update when complete. |
Table 14: Push Notifications & Alerts
Notifications are a privilege users grant and quickly revoke, so this table is as much about restraint as it is about reach. Asking for permission only after you've shown value, offering granular category controls, and favoring genuinely useful transactional messages over guilt-driven marketing are what keep people from disabling everything — the recurring warning that one pushy notification can cost you all of them.
| Pattern | Example | Description |
|---|---|---|
"Your order has shipped. Track it here." | • High-value, directly triggered by user action • highest trust—never bundle marketing into these; once trust erodes, users disable all notifications. | |
Ask after user has completed first meaningful action | • Request permission after demonstrating value, not on first launch • users more likely to allow when they understand the benefit. | |
"Notify me: [Order updates ✓] [Promotions ✗] [Tips ✗]" | • A single allow/block toggle is poor UX—provide granular category controls • users who can customize are less likely to disable all notifications. | |
Trigger around user behavior, not fixed daily schedule | • Send at contextually relevant moments; delay non-urgent messages to likely downtime • respect repeated dismissals as signals, not challenges. | |
Full headline + key detail in notification body | • Convey a fully formed idea without requiring the app to be opened • average notification microsession is ~15 seconds—make it count. | |
"You've got a new message" vs. "You're missing out!" | • Favor positive motivation over loss-framing or guilt-driven pressure • manipulative copy ("We miss you!") accelerates opt-outs. | |
"3 new messages from your team" (batched) | • Group low-urgency updates into a single digest • reduces notification fatigue for apps that generate frequent low-priority events. | |
Clear badge count when user views content | • Update app icon badge count to reflect unread items • clear immediately on view—stale badges erode trust. | |
Banner that slides down while user is in-app | • Show in-app alerts for events that happen while the user is active • less intrusive than push; automatically dismisses after a few seconds. |
Table 15: Onboarding & First-Time UX
First impressions decide whether someone sticks around, and the patterns here are about earning that commitment instead of demanding it. Letting users feel the value before forcing a sign-up, introducing features in context rather than in an upfront slideshow, and justifying permission requests before the system dialog all push retention up — with a hard-won rule throughout: never make onboarding feel like a wall, and always offer "Skip."
| Pattern | Example | Description |
|---|---|---|
Show key feature demo before requiring sign-up | • Let users experience value before commitment • deferred authentication increases sign-ups by 50%+. | |
Introduce features contextually as users need them | • Surface guidance in-context (tooltips, highlights) rather than upfront slideshow • less overwhelming; users learn by doing. | |
3-4 slides illustrating core benefits | • Use 3-4 slides max for initial feature overview • focus on user benefits, not feature lists; skip option always visible. | |
Explain "why" before the system dialog appears | • Custom pre-permission prompt explaining benefit improves allow rate by 2-3× • request permission only when functionality is needed (just-in-time). | |
Social login (Google/Apple) + skip option | • Minimize registration friction with social login options • offer guest mode where appropriate; ask for profile details after value is established. | |
First-run state shows samples + "Start here" CTA | Use positive first-run empty state to guide users—welcome message + action button + sample data if appropriate. | |
"What are you here for?" → immediate personalization | • 1-2 setup questions can enable tailored experience upfront • keep it optional, show immediate impact. | |
Coach mark (spotlight) on new feature | • Highlight specific UI elements with tooltips on first encounter • one at a time, dismissible, never block primary content. |
Table 16: Dialogs & Overlays
Surfaces that appear over the main screen, ranked roughly by how much they interrupt. Alert dialogs block everything and should be reserved for genuinely critical, irreversible actions; bottom sheets and popovers offer contextual choices without stopping the user cold; and snackbars and toasts sit at the gentle end, flashing brief feedback that fades on its own. Choosing the right level of interruption is the whole skill here.
| Component | Example | Description |
|---|---|---|
"Delete note? [Cancel] [Delete]" | • Use for critical, high-risk actions requiring confirmation • minimum 2 buttons (Cancel + Confirm); destructive action button in red/prominent. | |
Action list slides up from bottom | • Non-blocking contextual overlays for actions or navigation • standard modal (half screen) or expanded for complex content. | |
Date picker, filter panel, multi-step form | • Expanded bottom sheet for complex interactions • dim background, swipe down to dismiss, handles edge gestures. | |
"Account updated" auto-dismisses in 4s | • Brief, auto-dismissing feedback messages • max one line + optional action (e.g., Undo); stays visible without blocking primary flow. | |
Short floating message: "Link copied!" | • Lightweight Android feedback with no action; auto-dismisses • iOS uses snackbar pattern instead (no system Toast). | |
Terms of service, media viewer, multi-step form | • Use only for complex multi-step tasks requiring full context • provide clear "Done" or "Cancel" control at top. | |
Info bubble appears on tap of ⓘ icon | • Small overlay anchored to element • dismiss on tap outside, keep brief (1-2 lines). | |
In-app message at top or bottom | • Non-blocking in-app message for moderate-priority events • tap to navigate, swipe to dismiss. |
Table 17: Motion & Animation
Motion guides attention and adds polish, but only when it's quick and purposeful — most of these guidelines are really about restraint. Duration and easing rules keep transitions feeling natural rather than sluggish, shared-element and container transforms preserve spatial context between screens, and the reduced-motion entry is a non-negotiable: always offer a calmer alternative for users prone to motion sickness.
| Principle | Example | Description |
|---|---|---|
200-500ms for transitions, 100ms for hover feedback | • Short: 100-200ms for hover/state; Medium: 200-400ms for transitions; Long: 400-500ms for complex changes • avoid exceeding 500ms for standard interactions. | |
Ease-in-out for standard, spring for natural | • Use ease-in-out for transitions, spring physics for list insertions • avoid linear timing (looks robotic). | |
Card image expands to full-screen view | • Persistent element morphs between screens maintaining context • helps users understand spatial relationship. | |
Checkbox springs into checked state | • Small interactions providing confirmation and delight • loading dots, button ripples, icon transforms; keep under 300ms. | |
List item expands into detail card | • Semantic transition showing containment relationship • element from list view grows to become full detail view. | |
Detect prefers-reduced-motion and disable animations | • Always provide reduced-motion alternative • simple opacity fades or no animation for users with vestibular disorders. | |
Background moves slower than foreground on scroll | • Creates depth illusion and visual interest • use sparingly—can cause motion sickness; avoid when reduced motion is set. | |
List items appear 30ms apart in sequence | • Sequential delay creates visual flow • limit to <200ms total stagger across full list; longer = annoyance. | |
Shimmer effect pulsing across skeleton screen | • Animated loading placeholder (shimmer/pulse) reduces perceived load time • match skeleton structure to real content dimensions. | |
Haptic fires on gesture completion, not start | • Synchronize haptic feedback with visual/audio cues • use selection (light) for picks, impact (medium) for confirmations, notification patterns for alerts. |
Table 18: Platform-Specific Conventions
iOS and Android each have deeply ingrained conventions, and fighting them makes an app feel foreign. This table pairs the two platforms side by side — safe-area insets versus edge-to-edge WindowInsets, iOS large titles versus Material navigation, and Apple's new Liquid Glass against Material 3's dynamic color — so you can respect each platform's expectations instead of forcing one design onto both.
| Convention | Example | Description |
|---|---|---|
Respect home indicator and notch padding | • Use safeAreaLayoutGuide to avoid content under Dynamic Island, notch, or home indicator • iOS 26 adopts full-bleed with Liquid Glass overlapping content. | |
Edge-to-edge content + WindowInsets API | • Draw behind status/navigation bars with WindowInsets API • Material 3 defaults to edge-to-edge on Android 15+. | |
Android predictive back gesture (preview) | • Android predictive back shows destination preview • implement OnBackPressedCallback for custom back handling. | |
Large title collapses to small on scroll | • Use large title for root views, collapses on scroll • iOS 26 Liquid Glass nav bar blurs content scrolling behind it. | |
App theme adapts to wallpaper on Android 12+ | • Extract 5-color palette from user's wallpaper • creates personalized theme automatically without developer effort. | |
Translucent tab bars, nav bars, and overlays that refract background content | • Apple's new translucent, refractive material replacing flat design across iOS/iPadOS/macOS Tahoe • surfaces like glass, responds to light, tinted by background content; adopt glassEffect() modifier (SwiftUI). | |
UIImpactFeedbackGenerator with .medium | • iOS has rich haptic engine with selection, impact, and notification feedback types • use CoreHaptics for custom patterns. | |
iPhone view ≠ iPad side-by-side view | • Use UITraitCollection (iOS) / WindowSizeClass (Android) to adapt layout• iPhone = single column; iPad = split view or multi-column. | |
Use spacing.md token not hardcoded 16px | • Cross-platform consistency via named token values for color, spacing, and typography • one token change updates iOS, Android, and web simultaneously. |
Table 19: Responsive & Adaptive Design
One app now has to look right on a compact phone, a tablet, and a foldable that changes shape mid-use. The tools here — breakpoints and window size classes, fluid layouts, density-aware assets, and master-detail patterns that unfold as space grows — let a single design adapt rather than break, while dynamic type scaling makes sure it still works when users crank up their system font.
| Principle | Example | Description |
|---|---|---|
Compact <600dp, Medium 600-840dp, Expanded >840dp | • Google's Window Size Classes provide standard breakpoints • Compact = phone; Medium = tablet portrait; Expanded = tablet landscape, desktop. | |
Content fills width proportionally, not fixed pixels | • Use percentage widths and flexible containers • prevents overflow on small screens and unused space on large ones. | |
Single column → list-detail → three-pane | • Switch from single-column to list-detail to three-pane as screen grows • mirrors content complexity with available space. | |
@1x, @2x, @3x or vector SVG | • Serve density-appropriate assets • iOS: @1x/@2x/@3x; Android: ldpi/mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi; use SVG/vector when possible. | |
App respects user's system font size setting | • Support iOS Dynamic Type and Android sp units • test with largest accessibility font size to ensure UI doesn't break. | |
App adapts layout on rotate | • Support portrait and landscape unless UX specifically demands one • avoid landscape-only for mainstream apps. | |
Email list on left, email body on right | • Master-detail pattern for tablets maximizes screen real estate • list panel ~360dp; detail panel fills remainder. | |
App spans both screens when unfolded | • Handle HALF_OPENED and hinge position with Jetpack WindowManager • provide unique value in unfolded state (e.g., two-up view). | |
44×44px or WCAG 2.2 SC 2.5.8 24×24px minimum | • WCAG 2.2 SC 2.5.8 requires 24×24 CSS px minimum with spacing fallback • Apple HIG recommends 44×44pt; Android Material recommends 48×48dp. |
Table 20: AI & Adaptive UX
The newest frontier, where interfaces stop being static and start responding to the individual. Predictive content, layouts that reorder around how someone actually uses the app, conversational and agentic flows that act on the user's behalf — these are the 2026 patterns reshaping mobile UX. The constant caveat across every row is trust: explain the AI's reasoning, keep a manual override, and let people see and edit what drives their personalization.
| Pattern | Example | Description |
|---|---|---|
Suggest "Continue watching" based on time of day + history | • Surface relevant content before users seek it • AI predicts next action ~68% of the time; reduces taps to goal. | |
Frequent features move to home screen for power users | • Interface reconfigures based on usage patterns—frequent actions surface; rare ones recede • always provide manual override to reset. | |
AI assistant with message bubbles + quick-reply chips | • Dialogue-based interface for open-ended queries or task automation • include quick-reply shortcuts to prevent typing fatigue. | |
"Book my usual flight" → auto-fills and confirms | • AI acts on behalf of user across multi-step tasks • always show summary + confirm step before irreversible actions. | |
"Suggested because you often order this on Fridays" | • Show reasoning behind AI recommendations • improves trust and helps users understand + course-correct the system. | |
Keyboard autocorrect, photo classification, face recognition | • AI runs locally on device without data leaving • faster, private, works offline—preferred for sensitive data (face, voice). | |
"Edit your interests" toggle in settings | • Show what data drives personalization and let users edit it • builds trust and reduces "creepy" perception. | |
Pre-fill delivery address based on location context | • AI infers best defaults to reduce form friction • clearly labeled as suggestion, easy to override. | |
Search "comfortable shoes for summer" returns sandals/sneakers | • Natural language intent-based search rather than exact keyword matching • dramatically improves discoverability in large catalogs. |
Table 21: Design Systems & Tokens
How design stays consistent across a whole product — and across iOS, Android, and web at once. Design tokens are the central idea: named values for color, spacing, and type stored in one place, so changing a token updates every surface that references it. The token hierarchy, component libraries, and automated design-to-code handoff described here are what let large teams move fast without the design drifting apart.
| Concept | Example | Description |
|---|---|---|
--color-primary: #1A73E8; --spacing-md: 16px | • Atomic named values (color, spacing, typography) stored centrally as the design-code contract • change once, update everywhere. | |
Global blue-500 → Alias color-action → Component button-bg | • Three tiers: global (primitive values) → alias (semantic role) → component (specific usage) • avoids tightly coupling components to raw values. | |
Shared Figma library + React/React Native package | • Reusable, documented UI components shared across design and code teams • reduces duplication, enforces consistency, speeds delivery. | |
Tokens exported as CSS custom properties, JSON, Swift enums | • Automated token export via tools (Style Dictionary, Theo) generates platform-specific code from design tokens • eliminates manual copy-and-paste errors. | |
Light/dark theme by swapping token values | • Full theme switch (light/dark, brand) by replacing token values without changing component structure • enables per-tenant white-labeling. | |
space-1: 4px, space-2: 8px, space-3: 16px | • Predefined scale (often 4 or 8-point) prevents arbitrary spacing values • reduces design-code inconsistency. | |
Dedicated DS team, PR review for component changes | • Living documentation with contribution guidelines and change logs • prevents drift between design and code over time. | |
Figma variables linked to design token JSON | • Figma's variables allow tokens to be defined and tested inside Figma • sync via Tokens Studio plugin to code repository. |
Table 22: Performance & Optimization
Performance is a design concern, not just an engineering one — a sluggish or bloated app gets abandoned before its visuals ever matter. Lazy loading, modern image compression, and app-size trimming cut what users wait on, while offline-first architecture, a steady 60fps frame target, and prefetching keep the experience smooth even on mid-range hardware and shaky networks.
| Technique | Example | Description |
|---|---|---|
Load images as they enter viewport | • Defer off-screen images until user scrolls near them • reduces initial load time; use loading="lazy" or IntersectionObserver. | |
WebP/AVIF instead of PNG/JPG | • Use modern formats (WebP 30-50% smaller, AVIF up to 50% smaller than JPEG) • auto-convert at build time or CDN. | |
Enable ProGuard/R8 (Android), App Thinning (iOS) | • Use App Thinning (iOS: slicing/bitcode/on-demand resources) and R8/ProGuard (Android) to strip dead code • every 10MB increase reduces install conversion. | |
Combine 5 API calls into one batch request | • Combine requests to reduce round-trips • use GraphQL or REST batching; avoid N+1 queries in lists. | |
Read from cache, sync when reconnected | • Store critical data locally (SQLite, Room, Core Data) • gracefully degrade to read-only mode offline. | |
Target 60fps, avoid jank (>16ms per frame) | • Keep UI thread clear of long operations • offload heavy work to background threads; use Choreographer/CADisplayLink to detect drops. | |
Android App Bundle (.aab) for modular delivery | • Dynamic Feature Modules (Android) or Lazy loading (iOS) deliver only needed code • reduces initial download. | |
Avoid bitmap leaks, release large resources | • Use WeakReferences for cached bitmaps, implement onLowMemory() callback• leaks cause OOM crashes on mid-range devices. | |
Preload next page content before user taps | • Anticipate navigation and start loading resources early • e.g., preload next article while user reads current one. |
Table 23: Ethical Design & Anti-Patterns
A catalog of the manipulative tricks to avoid — confirm shaming, roach motels, hidden costs, forced continuity — alongside the privacy-first practices that build genuine trust. Beyond being wrong, many of these dark patterns are now outright illegal, with GDPR, the EU Digital Markets Act, and FTC enforcement cited throughout, making this table as much a compliance checklist as an ethics one.
| Pattern | Example | Description |
|---|---|---|
Request permissions with visible reason + "Not now" option | • Embed transparent data practices into design from day one • explain what data is collected, why, and how to control it. | |
Decline button: "No thanks, I hate saving money" | • Manipulative reject option wording designed to induce shame or guilt • GDPR Article 7: consent must be freely given—confirm shaming invalidates consent. | |
Easy sign-up, nearly impossible to cancel | • Design that's easy to enter, difficult to exit • subscription cancellation must be as easy to find as signup under EU Digital Markets Act. | |
Free trial auto-converts with no reminder | • Silent trial-to-paid conversion without prominent notification • GDPR and CPRA require clear pre-renewal notifications for free trials. | |
Double-negative checkbox: "Uncheck to not receive emails" | • Confusing UI language to obtain consent through user error • checkboxes must always use positive, affirmative language. | |
Prominent "Accept All" next to tiny "Manage Preferences" | • Visual design draws attention toward the choice you want users to make • GDPR requires equal prominence for consent options. | |
Fake "32 people looking at this right now" counter | • Fabricated urgency or social proof to pressure purchases • illegal in EU under Consumer Rights Directive 2019/2161. | |
Alt text: "image" on product photos | • Adding accessibility attributes without genuine intent • minimum: descriptive alt text, logical focus order, correct ARIA roles. |
Table 24: Accessibility Features
Designing so everyone can actually use your app, including people who rely on screen readers, larger fonts, or switch controls. Meaningful labels for VoiceOver and TalkBack, logical focus order, dynamic type support, and the recurring principle of conveying state through more than color make the difference between an app that's usable by all and one that quietly locks people out — and increasingly, these are legal requirements, not just good practice.
| Feature | Example | Description |
|---|---|---|
Semantic labels: accessibilityLabel = "Send message" | • Provide meaningful labels for all interactive elements • avoid "button button" or "image image" by using descriptive contentDescription (Android) and accessibilityLabel (iOS). | |
Tab order matches visual left-to-right, top-to-bottom flow | • Logical focus traversal using accessibilityViewIsModal / android:nextFocusDown• test with keyboard or switch control. | |
24×24 CSS px minimum (WCAG 2.2 SC 2.5.8) | • WCAG 2.2 SC 2.5.8 sets 24×24 CSS px minimum with spacing fallback • Apple recommends 44pt, Android recommends 48dp as best practice. | |
UI scales when user increases font in Settings | • Use sp units (Android) and Dynamic Type (iOS) • test layouts with xLarge and accessibility-large sizes to prevent overflow. | |
Detect UIAccessibility.isDarkerSystemColorsEnabled | • Provide increased contrast option for low-vision users • edges, borders, and UI elements should thicken or darken. | |
Detect UIAccessibility.isReduceMotionEnabled | • Replace animations with simple opacity fades when enabled • critical for users with vestibular disorders (motion sickness). | |
Image(decorative: icon) or contentDescription = "Profile photo" | • Add descriptive alt text to meaningful images • mark decorative images as ignored by screen reader. | |
Error field has red border + "⚠" icon + error text | • Convey state with multiple cues (color + icon + text) • ensures users with color blindness or low vision understand state. | |
App fully operable with external keyboard or switch | • Every interactive element must be reachable and operable without touch • test with iOS Switch Control and Android keyboard navigation. | |
Video player with [AD] toggle for descriptive audio | • Support audio description tracks for video content • describe visual elements not conveyed in dialogue. | |
role="button" on custom touchable elements | • Assign correct semantic roles to custom components • native components (UIButton, Button) have roles built in—only needed for custom views. |