Responsive Layout Design

Responsive Layout Design

When to Use

Use this skill when:

• User needs a complete multi-device layout specification covering breakpoint definitions, grid systems, component behavior rules, content priority ordering, typography scaling, and spacing tokens -- ready for developer or designer handoff
• User wants to define how specific components (navigation, data tables, hero sections, card grids, forms, sidebars) reflow, collapse, reorder, or transform across screen widths
• User is designing a new interface and needs to establish the responsive foundation before any visual design or CSS work begins
• User has an existing single-device layout and needs to extend it to a full responsive specification covering mobile, tablet, and desktop breakpoints
• User needs to audit or redesign an existing responsive layout that has specific failure points (text overflowing, images breaking, navigation collapsing poorly, tables truncating)
• User wants to specify content priority ordering so development teams know what to hide, deprioritize, or restructure on smaller viewports
• User is creating a design system or component library and needs standardized responsive behavior rules that apply consistently across many screens

Do NOT use when:

• User wants a wireframe for a single specific device or viewport only -- use wireframe-specification instead, which produces screen-level layout artifacts without multi-breakpoint complexity
• User wants to define transitions, animations, or micro-interactions that occur during viewport resize or between screen states -- use prototype-spec for motion and transition behavior
• User wants to write the actual CSS, Sass, or media query code that implements the responsive layout -- use a software-development skill (the spec produced here is the input to that work, not a substitute for it)
• User wants to map how users navigate between screens or pages across devices -- use user-flow-mapping, which handles navigation paths rather than layout structure
• User wants a visual brand identity or style guide -- responsive layout specs are structural artifacts, not visual direction documents
• User wants to design a native mobile app layout (iOS/Android) -- native apps use platform-specific layout systems (UIKit Auto Layout, Jetpack Compose) that differ fundamentally from viewport-based responsive web design

Process

Step 1: Establish Context and Design Direction

Before drawing any boxes, collect the five parameters that determine every subsequent decision:

• Content type classification: Identify which layout archetype the screen belongs to. Each has different responsive priorities:

  • Reading content (articles, documentation, blogs): Line length control is paramount. Single-column prose is ideal on all devices. Sidebar is supplementary.
  • Task-oriented interfaces (dashboards, admin panels, forms): Desktop-first thinking. Data density matters. Mobile versions often need significant restructuring, not just reflow.
  • Commerce and conversion pages (product pages, landing pages, checkout): Mobile-first is essential -- over 60% of e-commerce traffic is mobile. CTA visibility and form usability on thumb-zone areas are critical.
  • Content grids (news feeds, portfolios, galleries): Column count reduction is the primary responsive strategy. Image cropping and aspect ratio management matter.
  • Mixed editorial (marketing pages, homepages): Each section may use a different responsive strategy. Treat each section as a separate layout unit.

• Priority device and traffic profile: Ask the user where most traffic originates. Use this to determine design direction:

  • Greater than 60% mobile sessions: mobile-first layout (design mobile layout first, progressively enhance for larger screens)
  • Greater than 60% desktop sessions: desktop-first (design full layout first, gracefully degrade for smaller screens)
  • No data available: default to mobile-first. It is harder to add complexity than remove it.