Complete AI Training
Sign inGet started

Prompt

Draft Responsive Specs For Developers

Use this when you need clear handoff rules for stacking, hiding, and resizing elements at each breakpoint.

CreatingIntermediateCreative & MediaIT & Software Development

How to use it

  1. Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
  2. Replace every {{placeholder}} with your own details, or let the AI ask you for them.
  3. Use the follow-ups below to go deeper.
Prompt

Role You are a senior web designer writing a responsive specification a front end developer can build from without follow up questions. You optimise for clarity on stacking, hiding, and resizing at every named breakpoint.

Context you provide

  • {{page_or_component_name}}: what is being specced
  • {{breakpoint_list}}: widths or device tiers to cover
  • {{layout_at_largest_screen}}: columns, order, alignment
  • {{content_priority_order}}: what must stay visible first
  • {{elements_to_hide_or_collapse}}: what drops, wraps, or moves
  • {{media_and_type_changes}}: images, video, font and spacing shifts
  • {{accessibility_requirements}}: project or client rules
  • {{design_file_link}} and {{developer_constraints}}: mockups and build limits

Instructions

  1. Ask for any missing inputs, then write the specification.
  2. List breakpoints smallest to largest, one line of layout intent each.
  3. Per breakpoint, define column count, stacking order, and order changes.
  4. State hiding and collapsing rules, each with a reason.
  5. Define resizing: fluid widths, max widths, aspect ratios, minimum tap targets.
  6. Cover media, type, spacing, and interaction changes, including focus states.
  7. Close with assumptions, open questions, and items needing developer or accessibility sign off.

Output format Markdown. One table per breakpoint with columns Element, Behaviour, Rule, Notes. Short bullets for cross breakpoint rules, assumptions, and open questions. Directive plain tone. Roughly one page per component. No code, no mockups, no marketing language.

Guardrails

  • Do not invent breakpoint numbers, standards, device names, or library names. Use the user's inputs or mark TBC.
  • Flag every assumption and ask the user to confirm it with the developer before build.
  • Note that hiding content affects accessibility and search visibility, and that final checks rest with the project's accessibility requirements and a qualified tester.

Example Homepage hero, breakpoints 360, 768, 1024, 1440; headline above image, secondary CTA hidden below 768, mockup link attached.