Contact Form Mockup Review: Decide What Happens Before and After Submit

A contact form mockup often shows only its clean, empty state. That can hide the decisions that matter most when someone actually tries to send an enquiry. Which fields are required? What happens when information is missing? What does the confirmation message promise?

A useful client review looks at the experience before, during and after submission. The design establishes the intended communication. The working website still needs testing to confirm that validation, delivery and any integrations behave as expected.

Start with the purpose of the enquiry

Ask the business what information it needs to respond usefully. A request for a service quote may need different details from a general question. Avoid adding fields just because another website uses them or because a team member might find the information interesting later.

For each field, write down who uses the answer and what decision it supports. If there is no clear use, question whether it belongs in the first interaction. A shorter form is not automatically better, but every requested detail should have an understandable purpose.

Review labels with actual examples

Use visible field labels that explain the requested information. Placeholder text can provide an example, but it should not be the only explanation once someone starts typing. Review confusing terms with the client before they become part of the published interface.

Show representative values, including a long name, a detailed message and a realistic email address. This exposes spacing and wrapping issues that blank fields conceal. If a field accepts a specific format, document the instruction rather than expecting an error message to teach it later.

Make required and optional choices clear

The designer needs the business rules before deciding how to present them. Identify which details are essential to send the enquiry and which can be supplied later. Do not let the visual layout accidentally determine the required information.

Review the explanation as a whole. If every field is required, an explicit instruction may be clearer than unexplained symbols. If only some are required, make the distinction understandable and consistent. The implementation must preserve that meaning beyond the visual styling.

Design errors as part of the form

Prepare a state with a missing required field and another with an invalid entry. The message should explain what needs correcting without blaming the person. Keep it close enough to the relevant field that the connection is clear.

Also discuss a submission failure that is not the visitor's fault, such as a temporary service problem. Decide what the message should say and whether the entered information remains available. A mockup can define this expectation, but the development team must implement and test it.

Write an honest confirmation message

After submission, explain what happened and what the visitor should expect next. Do not promise a response within an hour unless the business can support that commitment. If the enquiry has only been received, avoid wording that implies a booking or purchase is already confirmed.

Ask whether the visitor needs a reference, a copy of the message or another action. These choices may involve backend work and should be recorded early. The visual review should not silently add a workflow that the implementation does not include.

Check mobile and long-content states

Review the form on the narrow layout using realistic text. Labels, instructions and error messages need room to wrap. Large blank spaces on desktop may become unnecessary scrolling on mobile, while compact side-by-side fields may feel cramped.

Once built, test with the on-screen keyboard, keyboard-only navigation and browser zoom. A static design cannot show how the viewport changes when the keyboard opens, nor can it confirm that focus moves appropriately after a validation error.

Turn approval into an implementation brief

Record the fields, required rules, example values, error messages, confirmation copy and delivery expectations. Keep this brief with the approved visual reference so the developer does not need to infer behavior from a screenshot.

Use Swelik to share the design states and collect comments on wording and placement. Keep implementation testing separate from visual approval. The website content checklist can help the client supply the missing instructions and response information before the final review.

Work through an enquiry from start to finish

Imagine a visitor asking a home-improvement company about a kitchen project. The business needs a contact method, a broad project description and enough location information to assess service coverage. It may not need a detailed budget breakdown or several attachments before the first conversation. Review each proposed field against the actual response process.

Ask the person who handles enquiries what they do with the information. If the team routinely asks the same follow-up question, consider whether the form should include it. If a field produces data nobody uses, question why it is required. The design should reflect the workflow rather than a generic idea of what a professional form looks like.

Build a field specification

For each field, record the label, purpose, required status, example value, instruction and error condition. This gives the designer and developer a shared reference. It also allows the client to approve the requested information separately from the arrangement of the controls.

A field note might read: “Project location / Used to check service coverage / Required / City or postcode / No full address needed for the initial enquiry.” The wording should reflect the business's actual needs. Do not collect detailed personal information just because a standard template contains the field.

Review a partially completed form

Fill the mockup with representative content and deliberately leave one required field incomplete. Show the intended feedback after submission is attempted. The client should understand which information needs attention and whether the rest of the entered content remains available.

Review a long message as well. A tidy two-line example can hide whether the text area gives the visitor enough space to describe the request. The visual design does not need to prescribe every browser detail, but it should communicate the expected use and avoid a composition that only works when fields are empty.

Define the difference between validation and delivery

A form can accept valid-looking input and still fail to deliver the message. Treat these as separate states. Validation concerns the submitted information; delivery concerns what the system does with it. The wording should not tell a visitor that their enquiry was received if the system has not confirmed that outcome.

Ask the development team what result the confirmation can reliably represent. It might mean the request was recorded, queued or delivered to a destination. Use wording that matches the actual implementation rather than making a stronger promise because it sounds friendlier.

Plan for a temporary failure

Show an error state for a service problem that the visitor cannot fix by changing their email address. Explain the next useful step without revealing internal errors. Decide whether retrying is appropriate and how to avoid confusing duplicate requests if a response is delayed.

These behavior choices need implementation input. The mockup should record the intended experience, while the developer determines and tests the reliable technical behavior. Do not assume that an attractive error message is sufficient evidence that failure handling works.

Check the confirmation content with the business

Ask who responds to enquiries and whether a response timeframe is genuinely supported. If the business cannot promise a fixed turnaround, use a clear acknowledgment without inventing one. If a confirmation email is expected, include that in the scope rather than treating it as an automatic consequence of a website form.

Consider whether the confirmation should repeat the submitted message or show a reference. Those choices affect content handling and implementation. Agree on what is useful for this particular service instead of copying the confirmation pattern from an unrelated checkout or booking system.

Review privacy wording and optional choices deliberately

If the form includes a privacy notice, consent language or an optional marketing choice, have the responsible person supply and review the wording for the business's actual process. Keep optional choices distinguishable from what is necessary to submit the enquiry. The design should not make an unrelated choice appear required through confusing visual treatment.

This is a content and implementation dependency, not something the designer should silently resolve with generic legal text. Record the owner and status of the wording so the final form is not approved with an unreviewed placeholder.

Create an implementation test handoff

List the states the developer needs to demonstrate: empty submission, invalid field, successful submission, temporary failure and any conditional fields included in scope. Add the expected message and what should happen to entered values for each state. Use realistic test data appropriate for the development environment.

After the form is built, verify the actual receiving process with the client or responsible team. A success message in the browser is only one part of the workflow. The business also needs to confirm that the enquiry reaches the intended place in a usable form.

Close the design review with clear boundaries

State which labels, instructions and visual states are accepted, which wording remains open and which behaviors require testing. This prevents the client from interpreting approval of the mockup as confirmation that the contact system is already operational. The result is a better handoff and fewer assumptions at launch.

Frequently asked questions

Can a form shown in an HTML preview send enquiries?

Do not treat an uploaded design preview as a production form integration. Review the appearance there and test actual submission in the website environment built for that purpose.

Should the client approve error messages too?

Yes. Those messages are part of the experience and often contain business assumptions. Reviewing them early helps prevent contradictory instructions after launch.