Most products treat responsive design as a CSS concern. It is not. Adaptive UI is a product decision: what content appears on which screen, how interactions change across input methods, and where you simplify versus where you preserve full functionality. Getting this wrong means a desktop experience that feels cramped on phones, or a mobile layout that wastes space on large screens.
This template helps you plan adaptive interfaces systematically. It covers breakpoint definitions, component behavior rules, input method adaptation, content priority by viewport, and a device testing matrix. Use it before design starts to align your team on how the product adapts, not just how it shrinks.
If you are building a mobile app from scratch, start with the Mobile App PRD Template to define platform requirements first. For measuring how screen adaptation affects user behavior, the mobile analytics plan covers instrumentation by viewport. The usability testing glossary entry explains how to validate adaptive designs with real users on real devices.
How to Use This Template
Audit your product's current screen support. List every viewport where users access the product today. Check analytics for device breakdown.
Define your breakpoint strategy. Choose breakpoints based on your actual user data, not generic framework defaults.
Map component behavior at each breakpoint. Decide what transforms, what hides, and what changes interaction patterns.
Define input adaptation rules. Touch targets, hover states, keyboard navigation, and pointer precision all change across devices.
Build your testing matrix. Prioritize the device/browser/OS combinations that cover 90% of your traffic.
Review with engineering and design. Adaptive UI requires agreement across disciplines before implementation starts.
The Template
Product Context
Field
Details
Product
[Product name]
Current platforms
[Web, iOS, Android, tablet, desktop app]
Primary viewport
[The screen size used by the majority of your users, e.g., "Desktop 1440px, 58% of traffic"]
Define breakpoints based on your user data and content needs, not arbitrary device widths. Each breakpoint should correspond to a layout change that improves usability.
Breakpoint Name
Min Width
Max Width
Layout Type
Primary Use Case
Mobile
0px
[e.g., 639px]
Single column
[e.g., On-the-go quick actions, viewing status]
Tablet Portrait
[e.g., 640px]
[e.g., 1023px]
[Two column / Sidebar collapse]
[e.g., Light editing, reading, reviewing]
Tablet Landscape
[e.g., 1024px]
[e.g., 1279px]
[Two column with sidebar]
[e.g., Full editing with context panels]
Desktop
[e.g., 1280px]
[e.g., 1535px]
[Full layout]
[e.g., Power user workflows, multi-panel views]
Wide Desktop
[e.g., 1536px]
None
[Max-width container or expanded panels]
[e.g., Data-heavy views, dashboards, comparison]
Breakpoint rationale. Document why each breakpoint exists:
Mobile cutoff at [X]px: [Why this number? What layout breaks below it?]
Tablet split at [X]px: [What content needs two columns at this width?]
Desktop threshold at [X]px: [What feature requires the full layout?]
Component Adaptation Matrix
For each major UI component, define how it behaves across breakpoints. "Adapts" means the component changes form. "Hides" means it is removed from the viewport entirely (accessible via alternative navigation). "Persists" means it appears unchanged.
Component
Mobile
Tablet
Desktop
Notes
Primary navigation
[e.g., Bottom tab bar]
[e.g., Collapsed sidebar]
[e.g., Full sidebar with labels]
[Transition points and animation]
Secondary navigation
[e.g., Hidden in hamburger]
[e.g., Top tabs]
[e.g., Left sub-nav]
Data tables
[e.g., Card layout with key fields]
[e.g., Scrollable table, fewer columns]
[e.g., Full table with all columns]
[Which columns hide first?]
Forms
[e.g., Full-width stacked inputs]
[e.g., Two-column layout]
[e.g., Three-column or inline]
[Minimum touch target: 44px]
Modals / Dialogs
[e.g., Full-screen sheet]
[e.g., Centered 600px modal]
[e.g., Centered 640px modal]
[Dismiss behavior: swipe down vs click outside]
Charts / Graphs
[e.g., Simplified, single metric]
[e.g., Full chart, horizontal scroll]
[e.g., Full chart with legend]
[Touch interaction vs hover tooltips]
Search
[e.g., Full-screen overlay]
[e.g., Expandable search bar]
[e.g., Persistent search in header]
Action buttons
[e.g., FAB or bottom bar]
[e.g., Inline buttons]
[e.g., Toolbar with labels]
Sidebar panels
[e.g., Full-screen drawer]
[e.g., Overlay drawer]
[e.g., Persistent panel]
[Component]
Content Priority by Viewport
Not everything can fit on every screen. Define what content is essential, useful, or optional at each viewport.
Content Element
Mobile
Tablet
Desktop
Rationale
[e.g., Dashboard summary stats]
Essential
Essential
Essential
[Users check this first regardless of device]
[e.g., Activity feed]
Essential
Essential
Essential
[Time-sensitive, needs immediate visibility]
[e.g., Detailed analytics charts]
Optional (link)
Useful (collapsed)
Essential
[Complex data needs screen space]
[e.g., Settings panel]
Hidden (menu)
Hidden (menu)
Useful (sidebar)
[Infrequent access, low priority]
[e.g., Help documentation]
Hidden (search)
Useful (tooltip)
Essential (sidebar)
[e.g., Keyboard shortcuts]
Hidden
Hidden
Useful
[No physical keyboard on mobile]
Input Method Adaptation
Different devices use different input methods. Define how your product responds to each.
Touch Input (Mobile / Tablet)
Rule
Specification
Minimum touch target
44x44px (Apple HIG) / 48x48dp (Material)
Spacing between targets
Minimum [8px] gap between tappable elements
Swipe gestures
[List swipe interactions: swipe to delete, swipe between tabs, pull to refresh]
Long press
[What does long press do? Context menu? Drag to reorder? Nothing?]
Pinch/zoom
[Enabled on: images, maps. Disabled on: standard UI, forms]
Scroll behavior
[Momentum scrolling, pull-to-refresh, infinite scroll vs pagination]
When should I use container queries instead of media queries?+
Use container queries when a component needs to adapt based on its own available space rather than the viewport width. This is common for reusable card components, sidebar widgets, and embedded content that may appear in different layout contexts. Media queries work better for page-level layout decisions like column counts and navigation patterns.
How do I handle complex data tables on mobile?+
Three common patterns work well. First, you can transform the table into a card layout where each row becomes a card with key-value pairs. Second, you can use horizontal scrolling with a frozen first column. Third, you can show a simplified view with only the most important columns and offer a "view all" toggle. The right choice depends on how users interact with the data. If they scan vertically, use cards. If they compare across rows, use horizontal scroll. Review the [UX audit template](/templates/ux-audit-template) for methods to test which approach works best with your users.
What is the minimum touch target size?+
Apple's Human Interface Guidelines recommend 44x44 points. Google's Material Design recommends 48x48dp. Both are reasonable minimums. The more important consideration is spacing between targets. Adjacent touch targets with no gap cause accidental taps. Use at least 8px of spacing between tappable elements, and increase to 12px for destructive actions (delete, archive, send) where accidental taps have consequences.
Should I build mobile-first or desktop-first?+
Build for wherever the majority of your users are. Check your analytics. If 60%+ of sessions are desktop, start there and adapt down. If mobile dominates, start there and enhance up. The "always mobile-first" advice is a simplification. The real principle is: start with the most constrained experience and add complexity for larger viewports. For most B2B SaaS products, desktop is still the primary viewport, so starting there and strategically simplifying for mobile often produces better results than trying to scale a mobile layout up.
How many breakpoints do I need?+
Most products need 3-5 breakpoints. Two is too few (you miss the tablet experience). More than five creates maintenance burden without proportional user benefit. Start with three (mobile, tablet, desktop) and add a fourth only if your analytics show a significant user cluster at a specific width that your three breakpoints handle poorly. Every breakpoint you add multiplies your testing matrix, so add them only when data justifies it.
Explore More Templates
Browse our full library of PM templates, or generate a custom version with AI.
