Give the build a clear starting point.

Identify the designs that are ready to build.

Keep the approved pages together and distinguish them from earlier explorations. Name the layouts and components consistently, and record any decisions that are still open. The development brief should say which screens are included and who can approve a change, so a polished concept is not mistaken for a complete specification.

• Share the current source file with the agreed access.
• Mark approved pages and outstanding decisions.
• Identify repeated sections and intentional variations.

Explain how the layout changes between screens.

Desktop and mobile layouts are useful, but the space between them needs decisions too. Describe what wraps, stacks, hides, or changes order. Use real headings and content where possible, including long titles and missing images. These examples help the developer understand the rules behind the design instead of copying a single frame size.

Define states and behaviour.

An open menu, a selected filter, a form error, and an empty list are part of the experience. Record the states that matter and explain the purpose of motion. Agree keyboard behaviour, focus treatment, and a reduced-motion version where needed. A short note beside a component can resolve more ambiguity than another static page.

• Show navigation and interactive component states.
• Include form labels, required fields, and confirmation messages.
• Describe what should happen when content is absent or unusually long.

Connect the design to the content model.

A resource card might draw from a CMS entry, link to an external document, or be written directly on the page. Make that distinction before the build. List the content types, fields, and relationships the team expects to maintain, then identify who supplies the copy, images, links, and metadata.

Agree how the build will be reviewed.

Check the first representative pages before repeating the pattern across the site. Review responsive behaviour, content, interactions, and editing as well as visual detail. Keep feedback in one agreed place and resolve design decisions with the person responsible for approval. New functionality or unfinished design work should be identified before it changes the delivery scope.