Responsive UI Skill

Responsive UI Skill

Purpose

Ensure layouts and components adapt correctly across screen sizes and platforms without breaking other breakpoints or hiding important content.

When to Use

• Building new UI that needs to work across multiple screen sizes.
• Fixing a layout that breaks at certain widths or on certain devices.
• Reviewing a component/page for responsive correctness before handoff.

When Not to Use

• Non-visual tasks (backend logic, data layer, config).
• A component explicitly defined as fixed-size by design (e.g. an icon) where responsiveness isn't applicable.

Required Inputs

• The component/page/screen in question.
• Existing breakpoints/responsive patterns used in the project (check global styles/tokens).
• Target platforms (web only, mobile app only, or both).

Assumptions

• Mobile-first approach is used where no stronger convention exists.
• Existing breakpoints should be reused, not redefined per-component.

Step-by-Step Workflow

1. Identify existing breakpoints: check global styles/tokens for defined breakpoints (e.g. --breakpoint-sm, sm:/md:/lg: if Tailwind, or platform-specific dimension logic in Expo).
2. Identify the platform context: web (Next.js/Vite — viewport-based breakpoints) vs. native app (Expo — device dimensions, safe areas, orientation).
3. Design/implement mobile-first: start from the smallest relevant size, then add rules for larger sizes using existing breakpoints.
4. Use flexible layout patterns: flexbox/grid with relative units (%, fr, rem, flex) instead of fixed pixel widths/heights, unless a fixed size is intentional (e.g. icon size).
5. Check content at each breakpoint:
   • Does anything overflow, get cut off, or overlap?
   • Is important content hidden on small screens? If so, is that intentional and acceptable?
   • Do touch targets remain large enough on small/touch devices?
6. For Expo/native: account for safe areas (notches, status bars, home indicators) and test both portrait/landscape if relevant.
7. Verify desktop/larger sizes still work after making mobile-focused changes — don't fix mobile by breaking desktop.
8. Preserve accessibility and interactive states (focus, hover, active) across breakpoints.

Rules and Best Practices

• Reuse existing breakpoints; don't invent new ad-hoc breakpoint values.
• Avoid fixed widths/heights unless required (e.g. fixed-size icons, avatars).
• Don't hide major content on smaller screens unless explicitly requested — prefer reflow/stacking over hiding.