A desktop design and a mobile design do not fully describe a responsive website. The difficult decisions often sit between those two frames: when navigation changes, how cards wrap, what happens to a long title, and how the layout responds when an editor adds more content.
A responsive Figma handover should communicate those rules, not just supply attractive endpoints. This guide provides a practical specification process for business websites built in WordPress, Wix, Shopify, Squarespace, or custom code. It works alongside our design-token guide and accessibility annotation guide, while focusing specifically on layout behaviour.
Begin with content and component priorities
List the components that matter to the project: header, service cards, pricing, testimonials, forms, article content, product information, and footer. For each one, state what the visitor needs to understand or do. This makes it easier to decide what should move, wrap, or remain visible on smaller screens.
Do not treat mobile as permission to remove useful content without discussion. A shorter introduction may help, but hiding service qualifications or pricing conditions can change the offer. Identify genuine priorities with the content owner. Mark optional decorative elements separately so developers can simplify them without accidentally removing meaningful information.
Specify fluid behaviour between example frames
For every major section, describe the containing width, spacing rules, alignment, and the relationship between columns. State whether a card stretches, keeps a preferred width, or wraps to a new row. A brief rule such as “three cards become two when the content no longer fits comfortably, then one” is more informative than three disconnected screenshots.
Figma's auto-layout documentation explains resizing options including hug contents, fill container, fixed dimensions, and minimum or maximum dimensions. Use those tools to demonstrate the intended relationships. The resulting design file still needs explanatory notes where production behaviour is not obvious; an auto-layout property is not automatically a complete implementation specification.
Choose breakpoints from the design's actual constraints
Common device widths can be useful test examples, but they should not be treated as universal laws. Identify where the content or controls stop working: a menu becomes crowded, a comparison table loses readability, or a card's text becomes excessively narrow. Those observations provide a reason for a layout change.
Document example widths and the intended transitions, then let the implementation reflect the actual platform and content. For a builder-based site, discuss available controls before approving behaviour that the chosen setup cannot maintain easily. Record any compromise, such as a different menu pattern or a simpler layout, while changes are still inexpensive.
Define navigation as a complete interaction
A header needs more than a closed mobile menu frame. Provide the open state, the trigger, the close action, submenu behaviour, focus expectations, and what happens after choosing a link. Explain whether the header overlays the banner, becomes sticky, or changes its background during scrolling.
Test long menu labels and a narrow viewport in the design. If a prominent contact button moves into the menu, make that deliberate. Avoid designs where the logo, button, and menu icon compete for the same space. Include the page's initial state and scrolled state if they differ, so the developer does not have to invent an unreviewed transition.
Set typography rules that survive real copy
Specify a readable body size, heading hierarchy, line spacing, and line-length intention. Describe how display headings scale and where wrapping is acceptable. A manual line break added to make one screenshot look balanced can create awkward fragments at another width.
Use realistic service names, article titles, and button labels in the handover. Include at least one long example. Explain whether a card title can wrap to multiple lines and how that affects alignment. Avoid requiring identical card heights by clipping meaningful text without an agreed alternative. Content resilience is part of responsive design, not a final polish task after development.
Explain image crops and focal points
An image that works in a wide banner may fail in a portrait card. Specify the intended aspect ratio, focal subject, and whether cropping is acceptable. For a portrait, identify the safe area around the head; for a product, identify details that must remain visible. Supply alternate crops only where they serve a real need.
Distinguish contain and cover behaviour in ordinary language. If the entire artwork must remain visible, explain that empty space may appear unless the surrounding layout matches its shape. If the image should fill a box, acknowledge what can be cropped. Our website image workflow covers asset preparation and publishing checks.
Include component states and content extremes
Document loading, empty, error, success, selected, and unavailable states where they apply. A three-column collection with twelve items is not the same design problem as a collection with one item or none. A form with a validation message can be taller than the approved blank form.
Use a small coverage matrix. For example, test a service card with a short title, a long title, no image, and a longer description. For a booking or enquiry flow, show both confirmation and failure feedback. Define whether a component grows naturally or has a controlled region with an accessible way to read more.
Make motion optional and purposeful
Describe what each animation communicates, when it starts, how it ends, and whether it repeats. A subtle reveal and a continuously moving banner impose different expectations. Avoid vague instructions such as “make it smooth” when motion materially changes navigation or reading.
Include a reduced-motion alternative and a usable static state. The content should remain understandable when animation does not run. Where an effect depends on a pointer, define what replaces it on touch screens and for keyboard users. Do not make essential portfolio information available only through a custom mouse trail or hover interaction.
Agree acceptance checks with the developer
Before implementation, review one complex section together. Ask the developer to explain the intended behaviour back in practical terms. Resolve ambiguous spacing, image cropping, and content rules early. This discussion can reveal platform constraints that are not visible in a polished presentation.
A fictional example is a consultancy service grid. The desktop version uses three cards, but one service name is twice as long as the others. The handover defines natural text wrapping, shared card padding, bottom-aligned actions where practical, and a single-column narrow layout. This is more maintainable than fixing each card to the height of the shortest screenshot.
Review the implementation at more than two widths
Check representative narrow, middle, and wide widths, then resize through the transitions. Use actual published content and realistic browser zoom. Inspect interactions as well as screenshots: open the menu, submit an invalid form, expand an answer, and revisit a page with a different amount of content.
Record defects against the agreed rules rather than personal preference alone. A responsive handover succeeds when the website continues to work as its content changes. If you need help preparing that specification, explore our Figma UI/UX services or discuss your website project with Ali Dev Solutions.