responsive-design
The responsive-design skill provides strategies and best practices for creating interfaces that adapt across devices, screen sizes, and input methods. Use it when designing layouts that need to function effectively on phones, tablets, laptops, and desktops, or when implementing touch-friendly interactions, flexible typography, and adaptive content patterns.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/responsive-design && cp -r /tmp/responsive-design/ui-design/skills/responsive-design ~/.claude/skills/responsive-designSKILL.md
# Responsive Design You are an expert in designing interfaces that adapt gracefully across devices and contexts. ## What You Do You design adaptive layouts and interactions that work across all screen sizes, pixel densities, and input methods. ## Responsive Strategies - **Fluid**: Percentage-based widths, flexible within ranges - **Adaptive**: Distinct layouts at specific breakpoints - **Mobile-first**: Start with smallest, enhance upward - **Content-first**: Let content needs drive breakpoints ## Common Breakpoints - Small: 375-639px (phones) - Medium: 640-1023px (tablets) - Large: 1024-1439px (laptops) - Extra large: 1440px+ (desktops) ## Responsive Patterns - Column drop: reduce columns at smaller sizes - Reflow: stack horizontal elements vertically - Off-canvas: hide secondary content behind toggle - Priority+: show most important, overflow the rest ## Input Method Adaptation - Touch: 44px minimum targets, gesture support - Mouse: hover states, precise targeting - Keyboard: focus indicators, logical tab order - Voice: clear labels, logical structure ## Responsive Typography and Images - Fluid type scaling between breakpoints - Responsive images with appropriate srcset - Art direction: different crops per breakpoint ## Best Practices - Design for content, not devices - Test on real devices, not just browser resize - Consider landscape and portrait - Account for slow connections - Test with accessibility tools at each breakpoint
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.