Web Design · Systems & implementation
The Best Prompt for Responsive Design
The best prompt for responsive design describes the layout you have and asks how each part should behave as the viewport narrows and widens, instead of asking for a mobile version. This prompt makes the model set the small-screen content order first, use fluid layout before adding breakpoints, and justify each breakpoint by what breaks there. You get a behavior table per component, rules for images, type and touch targets, and a test checklist.
Responsive Design Prompt
Turns one page layout into responsive rules: content order on small screens, fluid techniques, justified breakpoints and a per-component behavior table.
- Works with
- ChatGPT, Claude, Gemini
- Difficulty
- Intermediate
- Complexity
- Multi-part reply
- Variables
- 6
- Version
- 1.0
Customize this prompt
Fill in what you know. Anything left blank stays as a [bracketed placeholder]. Nothing you type leaves your browser.
6 variables · fields marked * matter most
Act as a senior front-end designer who plans responsive behavior before any CSS is written. PAGE [Page and its components] WHAT MATTERS MOST ON A SMALL SCREEN [What matters most on a small screen] BUILD CONTEXT Framework or CSS approach: [Framework or CSS approach] Breakpoint policy: [Breakpoint policy] Parts we expect to be awkward: [Parts you expect to be awkward] Deliverable: [Deliverable] WORK IN THIS ORDER 1) Narrow-screen order List the page's components in the order they should appear in a single column at 320 CSS pixels wide. Explain any component that moves relative to the desktop order, and name anything that should collapse, shorten or be removed. 2) Fluid before breakpoints For each component, say what can adapt with no breakpoint at all: wrapping flex or grid tracks, minimum and maximum widths, fluid type and spacing within set limits, intrinsic image sizing. Only what cannot be solved this way goes on to step 3. 3) Breakpoints Propose the smallest set of breakpoints that the remaining changes need. For each: the width, which component breaks without it, and what changes. Follow the breakpoint policy above. Do not name breakpoints after devices. 4) Behavior table One row per component; columns for narrow, medium and wide. Describe layout, visibility and interaction changes in each cell. Write "no change" where that is true. 5) Cross-cutting rules - Navigation: the pattern at each range and how it is opened by keyboard and touch. - Images and media: aspect ratios, cropping, and reserved space so content does not shift while loading. - Typography: minimum body size and the maximum comfortable line length. - Touch: target sizes and spacing, and replacements for hover-only interactions. - Awkward parts: a specific pattern for each item listed above, with its trade-off. 6) Test checklist The widths, orientations and settings to check, including 320 pixels wide without horizontal scrolling and text zoomed to 200 percent. RULES - Base every recommendation on the page described. Do not add components. - Do not hide content on small screens merely to save space; if something is removed, justify it by the stated priorities. - Meet WCAG 2.2 AA for reflow and target size, and say where the design is at risk. - If the deliverable includes CSS, give short, modern snippets for the trickiest two or three components only, after the table. Otherwise write no code. - Mark guesses about the existing layout as [ASSUMPTION]. OUTPUT Six numbered sections as above. Section 4 must be a table.
Use it when you are
- Planning small-screen behavior for a layout designed at desktop width
- Writing responsive rules to hand to a developer alongside a mockup
- Finding a pattern for awkward components such as data tables and mega menus
- Reviewing an existing page that scrolls sideways or feels cramped on phones
Why this prompt works
Order is decided at the narrowest width
In a single column there is nowhere to hide a weak hierarchy. Starting at 320 pixels makes the model commit to what comes first and what gives way, guided by the priority you stated. Wider layouts then become ways of spending extra room, which is an easier problem than squeezing.
Fluid techniques come before breakpoints
Modern CSS lets many components adapt on their own through wrapping tracks, size limits and fluid values. Asking what each component can do without a breakpoint first means the breakpoints that remain are the ones genuinely required, and the resulting CSS has fewer special cases to maintain.
Each breakpoint needs a reason
Naming the component that breaks without a breakpoint replaces the habit of copying phone, tablet and desktop widths. It also makes the plan reviewable: if the reason no longer applies after a design change, the breakpoint can go, and nobody has to wonder later why it was there.
A table, because responsive behavior is a matrix
Components down the side and width ranges across the top is how developers think about this work. The explicit "no change" cells matter as much as the others, since they confirm a component was considered instead of overlooked, and they save a developer from guessing.
The awkward parts get named patterns and trade-offs
Tables, dense navigation and hover interactions are where responsive plans usually go vague. Listing them as inputs and demanding a specific pattern with its cost for each forces a decision at the point where one is hardest to make, while the trade-off tells you what you are giving up by accepting it.
How to use it
- Describe the page top to bottom at its widest layout, naming each component the way your team does.
- State the small-screen priority as a task the visitor is trying to complete, not a list of sections.
- List the components you already know will be difficult. Include row and column counts for tables.
- Choose the breakpoint policy that matches your codebase. If you must use fixed widths, write them in the awkward parts field.
- Read section 1 and correct the order before relying on the table; everything after depends on it.
- Work through the test checklist on real devices or browser tools once the page is built.
AI model compatibility
| Model | Status | Notes |
|---|---|---|
| ChatGPT | Expected to work | If you attach a screenshot of the desktop layout, still list the components in text so the behavior table uses names your team recognizes. |
| Claude | Expected to work | A long page description or pasted markup is best placed inside <page> tags, following Anthropic's advice to separate supplied material from instructions. |
| Gemini | Expected to work | Keep the numbered order of work. Google's prompting guidance recommends explicit, sequenced instructions when the output has several dependent parts. |
“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.
Worked example
Scenario: A software pricing page designed at desktop width that needs to work on phones.
Act as a senior front-end designer who plans responsive behavior before any CSS is written. PAGE Header: logo left, six text links, 'Log in' and 'Start trial' buttons right. Hero: headline, one-line subhead, monthly/annual toggle. Plans: three cards side by side (Starter, Team, Business), each with price, five bullet points and a button; Team is highlighted. Comparison table: 12 feature rows, three plan columns, sticky header row. FAQ: two columns of six questions with expandable answers. Footer: four link columns and a newsletter field. WHAT MATTERS MOST ON A SMALL SCREEN Comparing the three plans and reaching the 'Start trial' button BUILD CONTEXT Framework or CSS approach: Tailwind CSS Breakpoint policy: Use my framework's default breakpoints Parts we expect to be awkward: Comparison table with 12 rows and 3 plan columns; header with six links and two buttons; tooltips on feature names that appear on hover Deliverable: Behavior rules plus CSS snippets WORK IN THIS ORDER 1) Narrow-screen order List the page's components in the order they should appear in a single column at 320 CSS pixels wide. Explain any component that moves relative to the desktop order, and name anything that should collapse, shorten or be removed. 2) Fluid before breakpoints For each component, say what can adapt with no breakpoint at all: wrapping flex or grid tracks, minimum and maximum widths, fluid type and spacing within set limits, intrinsic image sizing. Only what cannot be solved this way goes on to step 3. 3) Breakpoints Propose the smallest set of breakpoints that the remaining changes need. For each: the width, which component breaks without it, and what changes. Follow the breakpoint policy above. Do not name breakpoints after devices. 4) Behavior table One row per component; columns for narrow, medium and wide. Describe layout, visibility and interaction changes in each cell. Write "no change" where that is true. 5) Cross-cutting rules - Navigation: the pattern at each range and how it is opened by keyboard and touch. - Images and media: aspect ratios, cropping, and reserved space so content does not shift while loading. - Typography: minimum body size and the maximum comfortable line length. - Touch: target sizes and spacing, and replacements for hover-only interactions. - Awkward parts: a specific pattern for each item listed above, with its trade-off. 6) Test checklist The widths, orientations and settings to check, including 320 pixels wide without horizontal scrolling and text zoomed to 200 percent. RULES - Base every recommendation on the page described. Do not add components. - Do not hide content on small screens merely to save space; if something is removed, justify it by the stated priorities. - Meet WCAG 2.2 AA for reflow and target size, and say where the design is at risk. - If the deliverable includes CSS, give short, modern snippets for the trickiest two or three components only, after the table. Otherwise write no code. - Mark guesses about the existing layout as [ASSUMPTION]. OUTPUT Six numbered sections as above. Section 4 must be a table.
What a good response should contain
- A narrow-screen order that keeps the billing toggle and plan cards near the top and explains where the highlighted Team plan sits in the stack
- A note that the plan cards and FAQ columns can reflow with wrapping grid tracks before any breakpoint is involved
- A behavior table covering header, hero, plans, comparison table, FAQ and footer across three width ranges
- A named pattern for the comparison table on small screens with its trade-off, and a tap-friendly replacement for the hover tooltips
- A test checklist that includes 320 pixels wide, landscape orientation and text zoomed to 200 percent
This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.
Testing and editorial review
Status: Untested. Reviewed for structure and clarity by the editorial team. No recorded model test yet.
No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.
| Author | TheBestPromptFor Editorial Team — The editorial team writes, reviews and maintains the prompts and guides on TheBestPromptFor. Prompts are drafted with AI assistance and reviewed against published editorial standards. |
|---|---|
| Published | November 15, 2026 |
| Last reviewed | November 15, 2026 |
| Last tested | Not yet tested |
| Version history |
|
Limitations and things to check
- The model works from your description, not the rendered page. Real content lengths and translations can break layouts it considers safe.
- CSS snippets are starting points and are untested against your codebase and browser support targets.
- Framework breakpoint values can change between versions; check them against your project's configuration.
- Nothing here replaces testing on actual devices, with real touch input and different text-size settings.
Alternative prompts
Web Development
Responsive CSS Layout Prompt
Builds a layout with Grid, Flexbox and container queries that adapts to its content, with the reasoning and the edge cases to test.
- ChatGPT
- Claude
- Gemini
- Cursor
Web Design
Wireframing Prompt
Produces a low-fidelity wireframe of one screen as a text diagram and block spec, with content priority, states and annotations and no visual styling.
- ChatGPT
- Claude
- Gemini
Web Design
Accessibility Audit Prompt
Reviews page markup against WCAG 2.2, separating issues confirmed in the code from those needing manual testing, with fixes and a test script.
- ChatGPT
- Claude
- Gemini
Web Development
Core Web Vitals Diagnosis Prompt
Works from your own field and lab data to rank likely causes of poor LCP, INP or CLS, with a way to confirm each one before you change code.
- ChatGPT
- Claude
- Gemini
- Cursor
Related resources
Guide
How to Write a Good AI Prompt
The five parts of a complete prompt (goal, context, task, constraints, output format), with a worked rewrite and a pre-send checklist.
Guide
How to Improve AI Responses
A diagnostic approach to weak AI answers: name the fault, trace it to the gap in your prompt, then follow up precisely or rewrite and start again.
Frequently asked questions
What breakpoints should I use?
There is no universal set. The useful ones are the widths at which your own content stops working, such as a line of text getting too long or cards getting too narrow. If your framework ships defaults, using them is reasonable; the prompt will then explain which components need which default.
Is this mobile-first?
It plans from the narrowest width upward, which is the mobile-first idea, but it accepts a desktop layout as input because that is what many people start with. If you write CSS from the output, begin with the narrow column and add rules as the viewport grows.
Why does the prompt mention 320 pixels and 200 percent zoom?
Both come from WCAG. The reflow criterion expects content to work at a width equivalent to 320 CSS pixels without scrolling in two directions, and the resize text criterion expects text to scale to 200 percent without loss of content. They are practical stress tests for any responsive layout.
Sources and references
- CSS layout — MDN Web Docs
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
- Web Vitals — web.dev
Was this prompt useful?
No account needed. Do not include personal information.