A landing-page design is easier to accept when the handoff package is defined in advance: the page’s purpose, the available content, what desktop and mobile layouts show, and which decisions the developer receives. The discussion can then cover the whole page rather than a single attractive opening screen.
This guide provides a practical brief and a handoff checklist for designing one page. Coding, form integration and deployment are separate work. Check the specific package in the DDRW landing-page design listing.
Start with the visitor’s action and ready content
Describe who will open the page and the action they need to be prepared to take. In an illustrative scenario, an equipment maintenance company wants visitors to understand its service and request an estimate. That purpose guides the content and enquiry form; it does not establish that the page will generate a particular number of enquiries.
The brief needs answers that can be used in the layouts:
| Question | What to give the designer |
|---|---|
What is the offer? | Its name, scope, exclusions and enquiry conditions |
Who makes the decision? | The visitor’s role, main questions and page language |
What is the primary action? | Submit one form, make contact or visit a particular offer |
What supports the offer? | Actual work, photographs, documents or facts cleared for publication |
What is ready? | Logo, brand direction, copy and images |
Who approves? | One person who consolidates the team’s feedback |
If the offer still changes every week or the copy exists only as ideas, content preparation is needed first. It affects the workload. Design based on an existing brand does not include creating a new logo, a complete identity and all the copy from scratch.
Decide whether the project needs one page or several sections before design begins. Our separate guide covers landing pages versus multipage websites.
Agree on a wireframe and the purpose of each section
A wireframe establishes the information order and route to the main action before detailed visual design. For each section, record the question it answers. Repeated words such as “quality,” “experience” and “reliability” do not yet explain why a separate section is needed.
An illustrative equipment maintenance page might use this structure:
- Offer and primary action: what the company maintains and how to request an estimate.
- Suitable tasks: the situations covered by the service.
- Scope: what the team does and what needs a separate estimate.
- Supporting evidence: genuine examples cleared for publication.
- Enquiry process: what information is needed and what happens after submission.
- Main questions and one contact form.
This is a six-section teaching example, not a mandatory formula. Another business may need its evidence earlier or have no need for a separate FAQ. Agree on what counts as a main section and which elements belong inside it. Otherwise, a series of “small additional sections” gradually changes the approved structure.
Approve the copy and section order before the visual concept. Changing the offer after the wireframe is agreed can require fresh planning even if the colours and typefaces stay the same.
Treat desktop and mobile layouts as one system
The mobile layout shows how the same information works under different conditions: narrow lines, a vertical sequence and touch input. It should preserve the offer’s meaning, field labels and primary action. A scaled-down desktop image does not explain this behaviour.
The handoff should show how long headings, buttons and actual copy behave. What happens when a service name wraps onto three lines, an image has a different aspect ratio or the visitor enlarges the text? Record wrapping rules, text-width limits and section order between the two illustrated layouts. Two static layouts do not automatically specify every intermediate width.
W3C’s reflow guidance explains how content should adapt to available width without losing information or functionality, with stated exceptions for content that needs two dimensions. During design, this prompts checks of reading order and information flow. After development, it requires checking the actual page behaviour. Static layouts cannot establish the accessibility of the finished website.
Show form states and reusable elements
A button in its default state does not describe the whole interaction. For a form, agree on the initial appearance, field focus, validation errors, submission and confirmation. Explain which values remain when an error is corrected and what the visitor sees if submission fails. The server-side processing belongs to implementation and form integration.
| Element | What the handoff should explain |
|---|---|
Field | Label, hint, required status, focus and error |
Button | Action label, states and long-label behaviour |
Notification | Where it appears, what it means and what to do next |
Repeated card | Image rules, text length and alignment |
W3C’s form notification guidance stresses clear feedback about success and errors. A red outline without a message is therefore an incomplete description of the interaction for a developer. Supply the messages and explain their relationship to the action.
Include a visible focus state for keyboard interaction. It helps a person understand which control is selected, as explained in W3C’s focus-visible guidance. The complete keyboard workflow must be checked on the implemented interface.
Consolidate revisions and check the handoff package
A consolidated revision round is one agreed set of feedback from the responsible client contact. For each comment, identify the element, the problem, the intended meaning and the priority. “Increase the heading because it gets lost beside the photo” is more useful than “make it stronger.” Resolve contradictory team comments before sending them to the designer.
The DDRW package includes one visual concept and two such revision rounds within the approved structure. A new brand, additional pages or a complete change of offer needs a separate estimate. Record which comments have been resolved, accepted as limitations or moved outside the current scope.
Before completion, check that you have received editable layouts in the agreed format, reusable components, basic dimensions and states, explanatory notes and export-ready assets. Confirm the rights to images and fonts. A view-only link can support approval, but the terms for delivering editable source files should be defined separately and fulfilled.
Separate design acceptance from website launch
The DDRW package covers one landing page with up to six main content sections, based on an existing brand. It includes an agreed wireframe, desktop and mobile layouts, the main states of one form, components and handoff notes. The deliverable is a prepared design package.
Code, hosting, analytics and enquiry routing do not come into existence because a layout is ready. Plan them separately. Once implementation is complete, check the page on devices, form errors and actual enquiry delivery. Our website acceptance guide explains that process.
View landing-page design in the shop to see the current terms and agree on the source material. For the first discussion, prepare the completed brief, ready copy and a list of what you expect in the developer handoff.
