Mobile UI layout types: a practical guide for designers

Use stacked single-column and card-based layouts for content-first mobile apps; reserve split-view and supporting-pane layouts for tablets, foldables, and expanded window sizes. The primary mobile UI layout types every designer should know are:

• Single-column/stacked — content-first flows; onboarding; articles; forms
• Card/feed — browsable collections, social feeds, product listings
• Grid gallery — image-heavy exploration, catalogues, icon grids
• Tabbed/bottom navigation — apps with 3–5 top-level destinations
• Navigation drawer — deep hierarchies with many secondary sections
• Split/list-detail/supporting pane — large screens, foldables, productivity tools
• Modal/overlay and bottom sheet — contextual actions without losing place
• Floating action button (FAB) flows — primary creation or composition actions
• Carousel/pager — sequential content, onboarding steps, media galleries
• Masonry/waterfall — variable-height content such as images or cards
• Responsive/adaptive layouts — PWAs and web apps that reflow across window size classes

Material Design (Google) and Apple’s Human Interface Guidelines codify most of these patterns with specific component guidance. Mobbin provides real-world flow examples for each. MedwayWebDesign, led by Ian Rickard, applies these patterns to UK mobile commerce and responsive web projects — the selection criteria and resources below reflect that practical experience.

Table of Contents

• The full catalogue of mobile UI layout types
• How to choose the right mobile layout for your app
• Platform specifics that change your layout decisions
• Curated resources and pattern libraries designers actually use
• Key takeaways
• Why layout selection is more consequential than most designers assume
• MedwayWebDesign’s mobile UI and layout design services
• Further reading and canonical sources

The full catalogue of mobile UI layout types

1. Single-column/stacked layout

A single scrollable column places content in a linear vertical sequence, making it the default choice for reading-heavy screens: articles, onboarding flows, checkout forms, and settings pages. Cognitive load stays low because the user has exactly one path through the content.

Pros: maximum readability on narrow viewports; natural thumb-scroll gesture; straightforward to implement responsively. Cons: long pages require strong visual hierarchy to prevent monotony; poor for side-by-side comparison; wastes horizontal space on tablets without adaptation.

Example callout: News reader apps and long-form editorial screens almost universally adopt this pattern for body content, switching to a list-detail split only on expanded widths.

2. Card/feed layout

Cards group related content into discrete, tappable containers that can be reordered, filtered, or dismissed independently. The pattern suits social feeds, product listings, and dashboard summaries where each item is self-contained. Card UI design patterns require careful attention to spacing, shadow depth, and touch-target sizing to remain accessible.

Pros: high information density without visual clutter; each card is independently actionable; maps well to dynamic or user-generated content. Cons: inconsistent card heights create visual noise; performance degrades with large lists if recycling is not implemented correctly; accessibility requires explicit focus order.

3. Grid gallery layout

A grid arranges items in columns, typically two or three on a compact phone viewport, making it the standard for image catalogues, app icon grids, and photo libraries. Android guidance recommends a four-column base grid for mobile, with hierarchical grids for editorial screens and modular grids for uniform photo galleries.

Pros: efficient use of screen space for visual content; fast scanning for recognition tasks. Cons: text-heavy items become illegible at small cell sizes; equal-weight grid cells obscure content hierarchy; accessibility labels must be explicit for every cell.

4. Tabbed/bottom navigation layout

Bottom navigation places 3–5 primary destinations in a persistent bar at the screen’s base, keeping them within thumb reach at all times. This is the dominant pattern for multi-section apps on both Android and iOS, though the two platforms implement it differently (see Section 4 for platform specifics).

Pros: primary destinations always visible; ergonomically optimal for one-handed use; clear active-state signalling. Cons: limited to five destinations before the bar becomes crowded; not suited to deeply nested hierarchies; tab labels must be short enough to avoid truncation on small screens.

5. Navigation drawer layout

A drawer slides in from the left edge (or right in right-to-left locales) to reveal a full navigation menu, typically triggered by a hamburger icon. It suits apps with many sections that cannot all fit in a bottom bar, such as settings-heavy productivity tools or content platforms with numerous categories.

Pros: accommodates large navigation trees without cluttering the main canvas; familiar pattern for experienced users. Cons: navigation is hidden by default, reducing discoverability; the hamburger icon is less intuitive for new users; gesture conflicts with system back-swipe on Android require careful handling.

6. Split/list-detail/supporting-pane layout

Canonical layouts from Android’s developer guidance define three split-screen variants: list-detail (a master list alongside a detail pane, ideal for messaging or product catalogues), feed (a scrollable primary feed with a contextual side pane), and supporting pane (a primary content area with a secondary tool panel that only makes sense in relation to the primary content). These layouts are designed for tablets, foldables, and ChromeOS devices, and should collapse to a single-column stack on compact widths.

Pros: reduces navigation steps for exploration tasks; maximises productivity on large screens; mirrors desktop mental models for power users. Cons: inappropriate on compact phone viewports; requires careful state management when the pane collapses; list-detail chosen incorrectly in place of supporting pane leads to poor contextual coherence.

“List-detail is ideal for exploration — messaging, product catalogues — while supporting-pane layouts are best for secondary tools that only make sense in relation to primary content. Choosing the wrong one leads to poor context and confusion.”
— Android canonical layouts guidance

7. Modal/overlay and bottom sheet

Modals interrupt the current flow to demand a decision or display critical information; bottom sheets slide up from the screen’s base to present contextual options without fully leaving the current screen. UXPin’s mobile UI guidance lists bottom sheets alongside pull-to-refresh and swipe actions as foundational mobile patterns that designers should follow per platform convention rather than reinventing.

Pros: bottom sheets are ergonomically superior to top-anchored modals for one-handed use; modals enforce focus for critical decisions. Cons: overuse of modals creates interruption fatigue; full-screen modals on iOS can be confused with new screens if not dismissed clearly; nested modals are an anti-pattern on both platforms.

8. Floating action button (FAB) flows

The FAB is a circular button that floats above the content layer, representing the single most important action on a screen: compose, add, or create. It is a Material Design convention and appears less frequently in Apple HIG patterns, where toolbar buttons or navigation bar items serve a similar role.

Pros: immediately visible primary action; colour contrast makes it highly discoverable. Cons: can obscure content if positioned poorly; only one FAB per screen is permitted by Material guidelines; iOS users may find it less familiar than a navigation bar action.

9. Carousel/pager layout

A horizontal pager presents sequential content — onboarding slides, media galleries, featured product cards — one panel at a time, with swipe gestures to advance. The pattern works well for linear narratives but breaks down when users need random access to a specific item.

Pros: focused attention on one item at a time; natural swipe gesture; good for onboarding sequences. Cons: content beyond the visible panel is hidden, reducing discoverability; pagination indicators become illegible beyond five or six items; auto-advancing carousels create accessibility problems for users relying on assistive technology.

10. Masonry/waterfall layout

Masonry arranges items in columns of varying height, filling vertical space efficiently when card heights differ — common in image-heavy apps and inspiration platforms. The pattern requires more complex layout logic than a uniform grid and can increase rendering cost on lower-end devices.

Pros: visually dynamic; efficient use of vertical space for variable-height content. Cons: reading order is non-linear, which complicates keyboard and screen-reader navigation; column count must be tuned carefully for different viewport widths; implementation cost is higher than a standard grid.

11. Responsive/adaptive layout

Responsive layouts reflow content fluidly as viewport width changes; adaptive layouts switch between distinct layout configurations at defined breakpoints. Window size classes (compact, medium, expanded) provide the recommended decision framework: compact maps to a stacked single-column; medium allows a two-pane arrangement when space permits; expanded supports a full supporting pane with approximately 70% allocated to primary content and 30% to the supporting panel.

Pros: one codebase serves phones, tablets, foldables, and desktop browsers; future-proofs against new form factors. Cons: requires systematic design tokens and thorough testing across window sizes; adaptive switching logic adds engineering complexity; poorly implemented breakpoints produce awkward intermediate states.

Quick comparison

How to choose the right mobile layout for your app

The correct layout follows directly from the user’s primary goal. Exploration tasks (browsing a catalogue, reading a feed) suit card or grid layouts. Completion tasks (checkout, form submission, onboarding) suit single-column stacks. Tool usage (email composition, document editing on a tablet) suits split or supporting-pane layouts. Designing for mobile-first layout means resolving the compact viewport first, then progressively enhancing for larger widths.

Work through this decision sequence before committing to a layout:

1. Define the primary user goal. Is the user exploring, completing a task, or using a tool? Match the layout family to that mode.
2. Count top-level destinations. Three to five destinations suit bottom navigation. More than five require a drawer or a restructured information architecture.
3. Assess information density. High-density content (many items, variable heights) suits cards or masonry. Low-density, focused content suits single-column.
4. Map navigation depth. Shallow hierarchies (two levels) work with tabs. Deep hierarchies need a drawer or progressive disclosure within a single column.
5. Consider interruption frequency. Screens that frequently surface contextual options benefit from bottom sheets rather than full modals.
6. Apply the split-zone model. Samsung’s One UI design guide defines an interaction zone (bottom half of the screen) and a viewing zone (top half). Primary CTAs and navigation belong in the interaction zone; status information and headings belong in the viewing zone.
7. Check accessibility requirements. Touch targets should meet the 48 × 48 dp minimum recommended by Material Design. Contrast ratios must satisfy WCAG 2.1 AA. Screen-reader focus order must follow a logical sequence.
8. Evaluate rendering cost. Masonry and infinite-scroll card feeds carry higher rendering costs than paginated single-column layouts. Performance considerations should inform layout choice, not just visual preference.
9. Plan for window size classes. Decide at the outset how the layout transforms from compact to medium to expanded. A layout that has no expanded-width strategy will look broken on tablets and foldables.

Pro Tip: Place your primary call-to-action within the lower 40% of the screen — the interaction zone — and validate placement with a reachability test on your smallest target device. Ergonomic testing consistently shows that novice designers anchor CTAs too high, reducing one-handed task success rates.

A worked example: A four-destination UK mobile commerce app (Home, Categories, Basket, Account) maps cleanly to bottom navigation. A drawer would hide those destinations; a tab bar at the top would push navigation out of the interaction zone. Bottom navigation keeps all four destinations thumb-reachable and visible at all times, which is the correct choice for a completion-oriented commerce flow. For deeper reading on mobile commerce layout decisions, the distinction between exploration and completion modes is explored in detail.

Platform specifics that change your layout decisions

Android and Material Design

Material Design 3 (M3) governs Android layout conventions. Bottom navigation is limited to 3–5 destinations; beyond that, M3 recommends a navigation drawer or navigation rail. The FAB is an Android-native pattern and should represent the single primary action per screen. Back navigation on Android is gesture-driven (swipe from the left edge) on Android 10 and above, which creates gesture conflicts with drawers and horizontal pagers — designers must account for this in the interaction model. Dynamic colour tokens in M3 mean that layout containers adapt their surface colours to the user’s wallpaper, so avoid hardcoding background colours in layout components.

iOS and Apple Human Interface Guidelines

Apple’s HIG favours a tab bar at the bottom of the screen (functionally equivalent to Android’s bottom navigation) and large titles that collapse on scroll — a pattern that affects how much vertical space the layout has available at rest versus when scrolled. The FAB is not a native iOS pattern; primary actions typically live in the navigation bar or as prominent buttons within the content area. Swipe-back gesture from the left edge is a system-level navigation affordance on iOS, so left-edge drawers conflict directly with it and should be avoided. Safe area insets (home indicator, Dynamic Island, notch) must be respected in layout padding; ignoring them causes content to be obscured by system UI.

Responsive web and PWA considerations

“When designing responsive layouts, use window size classes to decide whether to reflow, show a supporting pane, or adopt a navigation rail for larger widths — simple scaling is not sufficient.”
— Android adaptive apps guidance

The table below summarises recommended layout transformations by window size class:

Viewport units (dvh, svh) should be used in place of vh on mobile browsers to account for collapsing browser chrome. Keyboard behaviour on mobile web differs from native: the virtual keyboard reduces the visible viewport, which can push fixed bottom bars out of view or overlap form fields — layout must account for this explicitly. Responsive design implementation requires testing across real devices, not just browser resize simulations, because rendering behaviour diverges between engines.

2026 design guidance consistently positions usability and accessibility as primary benchmarks, with visual aesthetics secondary — a principle that applies equally to native apps and responsive web experiences.

Curated resources and pattern libraries designers actually use

Selecting the right resource depends on what stage of the design process you are in. For flow research, Mobbin is the most efficient starting point: it aggregates real-world app screens and flows, allowing designers to compare multiple implementations of the same pattern before committing to one. Studying proven interaction solutions from Mobbin is considerably more reliable than inventing new flows from scratch, particularly for complex patterns such as multi-step checkout or onboarding sequences.

For component tokens, spacing systems, and platform-accurate behaviour, the canonical sources are:

• Material Design 3 — download tokens, component specs, and Figma kits directly; the canonical reference for Android layout conventions and adaptive layout guidance.
• Apple Human Interface Guidelines — covers iOS, iPadOS, and visionOS layout conventions; includes downloadable design resources and platform-specific component guidance.
• Android canonical layouts — the authoritative source for list-detail, feed, and supporting-pane implementations across phones, tablets, foldables, and ChromeOS.
• Figma Community — search for M3 Design Kit and Apple Design Resources; both are maintained by Google and Apple respectively and provide production-accurate components.
• UXPin — useful for understanding mobile UI principles and pattern definitions, particularly for designers newer to native mobile conventions.

For UI design inspiration beyond pattern libraries, Dribbble and Behance surface visual references, though real-world flow research from Mobbin is more instructive for layout decisions.

Pro Tip: Before engineering handoff, prototype your chosen layout in Figma using the platform’s official component kit, then run a five-minute usability test on a physical device. Emulators do not replicate thumb reach or the cognitive effect of holding a real handset — both of which affect whether your layout choices hold up in practice. For rapid idea validation before committing to a layout direction, Spark Concept’s idea checker can help teams pressure-test layout assumptions against business goals early in the process.

MedwayWebDesign’s approach: a UK mobile commerce example

A hypothetical UK mobile commerce client presented a common problem: a product catalogue of several hundred items, four primary navigation destinations, and a significant proportion of traffic from users on compact Android handsets. The layout decision followed the checklist in Section 3 directly. Bottom navigation handled the four destinations; a card-based grid (two columns) served the catalogue; single-column stacks handled product detail and checkout. On medium and expanded widths, the catalogue shifted to a three-column grid and the product detail adopted a list-detail split. Key metrics to monitor post-launch include task completion rate on the checkout flow, average session depth on the catalogue, and Core Web Vitals scores — particularly Largest Contentful Paint, which card-heavy layouts can degrade if image loading is not optimised. Ian Rickard and the MedwayWebDesign team apply this structured, research-led approach to every mobile UI engagement, grounding layout decisions in ergonomic data and platform convention rather than visual preference alone.

Key takeaways

The most effective mobile UI layout decisions combine ergonomic placement, platform convention adherence, and window-size-class planning — not visual preference alone.

Why layout selection is more consequential than most designers assume

The conventional wisdom in mobile UI is that layout choice is primarily a visual decision — pick what looks good, then refine. That framing is wrong, and it leads to predictable failures: CTAs placed too high for one-handed use, navigation patterns that conflict with system gestures, and split-pane layouts deployed on compact viewports where they have no business appearing.

Layout is fundamentally a behavioural decision. The split-zone model makes this concrete: the bottom half of the screen is where users interact; the top half is where they read. Every layout choice either respects that division or fights it. A bottom sheet respects it. A modal anchored to the top of the screen fights it. A FAB placed at the bottom-right of the canvas respects it. A primary action buried in a top navigation bar fights it.

The second underestimated factor is platform divergence. Designers who work across Android and iOS often treat the two platforms as interchangeable, applying Material patterns to iOS screens or HIG conventions to Android. Both platforms have users with deeply ingrained expectations — swipe-back on iOS, back gesture on Android, tab bar versus bottom navigation semantics — and violating those expectations creates friction that no amount of visual polish can compensate for.

The practical implication is that layout decisions should be made before visual design begins, not after. Define the window size class strategy, the navigation depth, and the ergonomic zone allocation first. The visual layer follows from those structural decisions, not the other way around. UK mobile commerce data consistently shows that checkout abandonment correlates with interaction friction, and interaction friction most often originates in layout choices made too late in the process to correct without significant rework.

MedwayWebDesign’s mobile UI and layout design services

MedwayWebDesign delivers mobile-first UI design that begins with layout architecture, not visual styling — a distinction that produces measurably better outcomes for UK businesses building apps and responsive web experiences. Where many agencies start with brand colours and typography, MedwayWebDesign starts with window size class planning, navigation depth analysis, and ergonomic zone mapping, then builds the visual layer on top of that structural foundation.

For UK businesses, that means a mobile commerce site or app that converts on compact Android handsets as effectively as it does on a tablet, with Core Web Vitals scores that support organic search performance rather than undermining it. Services cover mobile-first UI design, cross-platform adaptation (Android, iOS, responsive web/PWA), prototyping and usability testing, and performance optimisation aligned with business web design best practice. Clients can expect improved task completion rates, reduced checkout abandonment, and layouts that hold up across the full range of devices their users actually carry. To request a layout audit or discuss a mobile UI project, contact MedwayWebDesign directly at medwaywebdesign.com.

Further reading and canonical sources

The sources below are the primary references for the guidance in this article. Each is worth bookmarking for ongoing reference during design and development.

• Material Design 3 (Google) — download component tokens, Figma kits, and adaptive layout guidance; the definitive Android layout reference.
• Apple Human Interface Guidelines — iOS and iPadOS layout conventions, downloadable design resources, and platform-specific component specs.
• Android canonical layouts (Views) — authoritative guidance on list-detail, feed, and supporting-pane patterns across phones, tablets, foldables, and ChromeOS.
• Android adaptive apps: canonical layouts — window size class definitions and recommended layout transformations; essential for responsive and adaptive design.
• Android content structure guide — column grid guidance and hierarchical versus modular grid selection for mobile screens.
• Mobbin — real-world app flows and screens for pattern research; use before prototyping to study proven interaction solutions.
• UXPin: mobile UI principles and patterns — accessible overview of mobile UI components, navigation patterns, and platform conventions.
• Samsung One UI design guide — ergonomic split-zone model and reachability guidance; directly applicable to Android layout decisions.
• CodeCondo: best practices for mobile UI design — practical overview of usability, accessibility, and performance benchmarks for mobile UI.
• Mobile design patterns (ColoriPop) — concise reference for fixed, floating, and scrolling element behaviour and their ergonomic implications.

Test on real devices when implementing any of these patterns. Browser resize and emulator testing will not surface the gesture conflicts, safe-area issues, or reachability problems that appear on physical handsets — and those are precisely the issues that determine whether a layout succeeds in production.

Recommended

• What is UI design explained: a beginner’s guide – Medway Web Design
• UI design inspiration source types: 2026 guide – Medway Web Design
• Role of card UI design patterns: 2026 guide – Medway Web Design
• Unique website layout types: a 2026 designer’s guide – Medway Web Design