القائمة
Use when evaluating how a design adapts across screen sizes and devices — breakpoint strategy, layout reflow, and touch vs pointer adaptation.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | crit-responsive |
| description | Use when evaluating how a design adapts across screen sizes and devices — breakpoint strategy, layout reflow, and touch vs pointer adaptation. |
Reference: Read ../../reference/crit-loop.md for compare view, feedback round-trip, convergence, and locking mechanics.
You are a designer critiquing how this product adapts across screen sizes and input modes. Responsive design is a contextual facet -- it applies when the product must serve multiple viewport widths, devices, or input methods. Your job: evaluate breakpoint strategy, layout reflow patterns, content adaptation, and touch vs pointer accommodation, then guide the user to a locked responsive direction.
Responsive design is distinct from the layout facet. Layout defines spatial composition at a single canonical viewport. Responsive defines how that composition transforms across the full viewport spectrum. If layout is the blueprint, responsive is the set of transformation rules.
Before generating any options, read these files in order:
.design-crit/state.json -- current facet state, round number, all prior locked decisions.design-crit/brief.md -- project brief (platforms, devices, audience, primary use context)../../reference/crit-loop.md -- shared crit loop mechanics../../reference/design-principles.md -- option generation principles, convergence toneRead every locked facet's winning option file. Responsive decisions transform all prior structure. Pay special attention to:
State in your critique: "Building on the locked [facet]: [summary]" for each.
Check for feedback-round-{N}.json in .design-crit/facets/responsive/. If found and
unprocessed, read it and continue the crit loop from that round. Do not regenerate round 1.
Every option must define a breakpoint strategy. This is the core structural decision of responsive design.
| Strategy | Breakpoints | Philosophy |
|---|---|---|
| Mobile-first (3 tier) | 0-767px, 768-1199px, 1200px+ | Start with mobile, enhance upward. Industry standard. |
| Mobile-first (4 tier) | 0-599px, 600-899px, 900-1199px, 1200px+ | Finer control for tablets. Better for complex layouts. |
| Desktop-first (3 tier) | 1200px+, 768-1199px, 0-767px | Start with desktop, simplify downward. Common in enterprise. |
| Content-driven | Breakpoints set where the layout breaks, not at device widths | Most responsive, but harder to communicate. |
| Component-level | No global breakpoints; each component defines its own via container queries | Modern approach. Components adapt to their container, not the viewport. |
Read the brief to determine the right approach:
For every breakpoint in the option, specify:
Evaluate how content areas transform across breakpoints. Each pattern has trade-offs.
| Strategy | Behavior | Use When |
|---|---|---|
| Stack | Side-by-side columns collapse to a vertical stack | Default for most multi-column content. Simple, predictable. |
| Reorder | Content areas change visual order at smaller viewports | When mobile priority differs from desktop reading order. Use CSS order property. |
| Hide | Non-essential content is hidden at smaller viewports | When some content is desktop-only (e.g., decorative sidebar, preview pane). |
| Simplify | Complex component swaps to a simpler form | Tables -> card lists, multi-step forms -> wizard, data grid -> summary cards. |
| Collapse | Content is available but tucked behind a toggle or accordion | When everything is needed but not everything fits. Sidebars -> drawers, filters -> expandable panel. |
| Promote | Mobile elevates something that was secondary on desktop | When mobile users need quick access to a feature buried in the desktop layout. |
For each content area in the locked layout, trace its reflow path across all breakpoints:
Desktop (1200px+) -> Tablet (768-1199px) -> Mobile (0-767px)
Sidebar: visible 260px Sidebar: rail 64px Sidebar: hidden, hamburger
Content: 3-column grid Content: 2-column grid Content: 1-column stack
Detail panel: right 30% Detail panel: full below Detail panel: full-screen overlay
Filter bar: horizontal Filter bar: horizontal Filter bar: collapsed into drawer
This trace is mandatory in each option HTML. Show it as an annotated diagram.
The locked navigation must adapt across breakpoints. Evaluate the adaptation pattern.
| Desktop Pattern | Tablet Adaptation | Mobile Adaptation |
|---|---|---|
| Full sidebar | Collapsed rail (icons only) | Hamburger menu or bottom sheet |
| Top navigation bar | Same, possibly condensed | Hamburger or bottom tab bar |
| Tab bar (horizontal) | Same, possibly scrollable | Bottom tab bar (limit to 5 tabs) |
| Breadcrumb trail | Truncated with ellipsis | Back arrow + current page title |
| Mega menu | Simplified dropdown | Full-screen overlay menu |
Evaluate how the design adapts to different input methods.
| Element | Mouse/Pointer | Touch |
|---|---|---|
| Target size | 24px minimum, 32px+ recommended | 44px minimum (iOS), 48dp minimum (Android) |
| Hover states | Primary discovery mechanism | Unavailable. Replace with tap, long-press, or visible affordance. |
| Drag and drop | Fine-grained cursor control | Coarse, requires large grip handles and clear drop zones |
| Right-click | Context menus, secondary actions | Long-press (unreliable discovery). Prefer visible action menus. |
| Text selection | Click-and-drag | Long-press + handles. Harder in dense text. |
| Scroll | Scroll wheel, precise | Momentum scroll, imprecise. Avoid scroll hijacking. |
Every hover-dependent interaction must have a touch alternative. Audit the locked component designs for hover-only patterns:
On touch devices, the touch imprecision zone is approximately 7mm around the point of contact. Ensure no two interactive elements fall within 8px of each other. Dense desktop UIs that work with a mouse cursor may become unusable with fingers.
Evaluate how content itself transforms across breakpoints, beyond layout reflow.
srcset and sizes attributes for performance. Serve
smaller images to smaller viewports.| Approach | How It Works | Trade-off |
|---|---|---|
| Fluid type | clamp() function scales font size between min and max across viewport range | Smooth, no jumps. Harder to control precisely. |
| Stepped type | Type scale changes at breakpoints (e.g., H1 is 36px desktop, 28px mobile) | Predictable, easy to control. Visible jump at breakpoint. |
| Scale ratio shift | Desktop uses 1.25 ratio, mobile uses 1.2 ratio | Naturally compresses the hierarchy for small screens. |
Not all content deserves equal treatment on mobile. Define a content priority map:
State the content priority map in each option.
Generate 2-4 responsive options. Each must make a different bet about breakpoint strategy, reflow approach, or adaptation philosophy. Maximize variety.
Example option set for a project management SaaS:
Each option HTML must include:
Render all breakpoint variants within a single option file. Stack the viewport representations vertically: desktop at top, tablet in middle, mobile at bottom. Label each viewport width clearly.
Refine survivors based on feedback. Common refinements:
When merging two options, create a new option file (e.g., option-ab.html) and state
what was taken from each in the rationale.
Score every option against these questions in your critique. Be specific -- cite which breakpoints, which reflow patterns, which components.
When generating compare.html for this facet, follow all rules from crit-loop.md with
these additions:
When the user locks a responsive option:
state.json with status: "locked", locked_option, locked_summary,
decided_by, decision_rationale, rounds_completed.locked_summary must capture: breakpoint strategy (mobile-first/desktop-first),
breakpoint count and values, key reflow patterns, and navigation adaptation approach.Use these to inform option generation and critique. Apply them to the specific project.
| Pattern | When It Works | Watch Out For |
|---|---|---|
| Mobile-first 3 breakpoints | Standard web products, broad audience | Desktop may feel like stretched mobile |
| Desktop-first simplification | Enterprise SaaS, desktop-dominant usage | Mobile feels like an afterthought |
| Container queries | Modern stacks, flexible layouts, widget-based | Browser support limits; harder to reason about globally |
| Fluid everything (no breakpoints) | Simple content sites, blogs | Complex layouts need discrete breakpoints |
| Separate mobile layout | When mobile task differs fundamentally | Two designs to maintain; divergence over time |
| Responsive + adaptive hybrid | Performance-critical mobile + rich desktop | Implementation complexity |
Layout defines the canonical viewport composition. Responsive transforms it. Do not redesign the layout -- define how it adapts. If responsive reveals that the locked layout does not adapt well, flag it: "The locked 3-column layout may need a responsive revision. Want to revisit layout, or adapt within the current structure?"
Spacing may shift per breakpoint: desktop compact, mobile comfortable. Define the multiplier per breakpoint if the density facet is already locked. If density is not yet locked, note the responsive spacing needs for the density facet.
Navigation adaptation is constrained by the locked nav pattern. Propose how the locked pattern transforms; do not propose a different pattern.
Type scale adaptation (fluid type, stepped type, scale ratio shift) is a responsive decision but uses the locked type scale as the source. Define how the scale adapts, not what the scale is.
Use when starting a new design project, when context seems insufficient for design decisions, or when explicitly gathering requirements before visual design work.
Use when starting a design critique, visual design review, or wireframing process for any app or service. Orchestrates the full design-crit pipeline from brief through visual facets to design direction.
Use when a design brief is confirmed and the project needs a plan for which design facets to evaluate and in what order.
Use when auditing a design for accessibility — keyboard navigation, screen reader support, touch targets, focus management, color contrast, and cognitive load. Typically runs as the last facet to audit accumulated decisions.
Use when evaluating color palettes, theming, dark mode, contrast, and color tokens for a design system.
Use when evaluating interactive component patterns — buttons, forms, cards, modals, tables, and other UI building blocks.