Adaptive UI Template for Product Managers

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.

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.

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.

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.

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.