Contact page design: form, map, conversion

Contact page design: where exactly inquiries are lost

The feedback form is the only block on the contact page whose behavior is measured step by step: how many visitors opened it, started filling it out, reached the submit button.

The gap between these numbers is where losses occur, and each has a specific cause in the markup and logic.

The most expensive cause is non-obvious required fields. Until a visitor clicks the button, they do not know that a phone number is required and the question is optional: required attributes are not shown by label or field order.

Validation errors trigger only after submission, the message appears in small gray text below the field and does not say what exactly to fix. A visitor with entered data receives a rejection without explanation—and leaves instead of returning to the form again.

The second group of losses is around the directions map. A map without branch markers, without labeled entrances and opening hours makes people write a clarifying question in the form instead of calling or visiting, and that is no longer a request but a correspondence.

Finally, the absence of submission confirmation: the visitor does not see that the inquiry was accepted, clicks the button again or simply closes the tab, and the inquiry is either duplicated or lost.

We look at how this is closed. We shorten the form to the fields without which an inquiry cannot be processed, mark required fields in advance, move validation to the moment of input rather than submission.

We link the map to real addresses and entry points, and after submission show an explicit confirmation screen with the inquiry number.

What changes after rework: measurable effects

We measure the effect of reworking the contact page not by the form's appearance but by five metrics: share of completed submissions, completion time, request completeness, repeat support inquiries, and the class of failures that disappears entirely. Below is what exactly changes and how it is measured.

• Share of completed submissions. We remove fields that do not affect request processing and move optional ones to the second step. The share of those reaching the button grows, and mid-form abandonments decrease—Baymard Institute in form research shows the same relationship.
• Completion time. Clear labels, masks for phone and email address, error text next to the field rather than as a list above. We measure the median from first touch to submission: on smartphones it drops more noticeably than on large screens.
• Request completeness. We synchronize required fields with what the manager actually needs: inquiry topic, preferred communication channel, attachment with a clear limit. The request arrives understandable, without "call me back and I'll explain."
• Repeat support inquiries. Exact address and route on the map, opening hours, directions, and answers to frequent questions right on the page—some questions are resolved before the call, and the flow of identical inquiries drops.
• The class of failures that disappears. Expired session, reset form, lost attachment: the page saves what was entered, resubmission does not duplicate the request, and the error is explained in human text.

We capture all five metrics before changes and a few weeks after—based on page events, not feelings. This shows which change had an effect and which should be rolled back.

Implementation options: block, separate address, step-by-step scenario

The format for collecting inquiries is chosen not by the designer's taste but by the client's scenario: how many branches they have, which pages traffic comes from, and what happens to the request after submission. Below are the options actually chosen on a project and their limitations.

Branch selection is a separate task within any option: the list is pulled from a directory, with one office the field is hidden, with several a suggestion by city and nearest address works.

The request handler must be single: both the form and the messenger write to a common queue with a source label, otherwise inquiries are lost between channels. On the prototype we check that if one channel fails, the second continues to accept requests.

Work order: from inquiry analysis to handoff of layouts

The work order is built around one principle: first—what happens with inquiries now, then—how it should look and work. We do not start drawing until we have analyzed actual inquiries and fixed which fields and channels are really needed.

Below is the sequence the work follows; each stage is closed with approval so that changes do not surface during assembly.

1. Inquiry audit. We look at the export for a period: where requests come from, at which step people drop off, which fields they fill in again by phone. Separately, we calculate the share of inquiries that do not reach the end of the form.
2. Scenarios and block structure. We determine who needs only a phone and address, who needs a form, who needs a messenger. At this same step we fix the required minimum of fields and the order of blocks on the page.
3. Prototype with texts. We assemble a scheme without styling but with real field labels, hints, and button text. We check the form length and the path to it from mobile.
4. Visual design of all states. We draw not only the "clean" state: empty field, focus, validation error, submission, success response, unavailable handler. Responsive design—separate layouts for narrow screens.
5. Assembly and handler connection. We code the layout, connect request submission, notifications to responsible people, bot protection, and rate limiting. We check that the request is not lost on resubmission.
6. Pre-launch check. We run the checklist: delivery of requests to all channels, error texts, failure behavior, correctness of analytics goals. Only after that do we hand off the layouts and code.

Handoff includes not only design files but also rules for states—so that text edits or adding a field later do not break the form logic.

What we hand over: layouts, texts, form states

Along with the layouts, we hand over a set of artifacts that any team, not only ours, can use to build and maintain the form. Each item is self-sufficient: the developer opens the file and sees what to do, without back-and-forth or guesswork.

• Layouts for all states: empty form, filled form, error for each individual field, submission, success, request intake service unavailable, resubmission after network failure.
• Ready texts and hints: field labels, input examples, error wording indicating what exactly to fix, button text, confirmation screen.
• Validation rules: what is checked before submission, what only on the server, phone and email formats, required fields, submission rate limiting, and automatic spam protection.
• Data transfer scheme: which fields are sent, in what form, where—email, CRM, or internal receiver; behavior when the service fails, retries, inquiry log.
• Accessibility requirements: label associated with field, keyboard tab order, visible focus, contrast, error announcement by screen reader software.
• Map settings: marker address, zoom, behavior on narrow screens, fallback without a map—a static snapshot with a link to the route.
• Instructions for self-editing: where to change phone, opening hours, address, and texts; how to add a field without breaking layout and validation.
• Acceptance checklist: scenarios we run on real devices and browsers, with a note on what counts as passed.

Case study: how form rework reduced incomplete submissions

Inquiries were left through a single full-width form of eleven fields: contact, company, city, task type, description, attachment, consent.

According to Yandex Metrica, 23% of those who started filling it out reached the end, average completion time was 3 minutes 40 seconds, and in 6 out of 10 requests that got through, the manager asked a clarifying question in the first email: task type and deadline were not selected because people did not understand the difference between the options.

What we changed

Completion was split into two steps: first inquiry type and contact, then details. Four required fields remained, the rest is filled in automatically—city is determined by network, company by email domain, so manual input was cut in half.

We removed the robot check: instead, a hidden honeypot field and server-side submission rate control, so an honest visitor no longer solves an unnecessary task.

We added a phone mask, format hints directly in the field, and draft saving—if the connection drops or the visitor returns, what was entered is not lost.

What became

The share of inquiries completed to the end grew from 23% to 61%, incomplete submissions stopped being the main traffic loss, and completion time dropped to 1 minute 20 seconds.

The share of requests that required a clarifying question fell from 60% to 18%: the options in the first step are worded so that task type is chosen consciously.

In 9 out of 10 inquiries, task type and deadline are indicated immediately—the manager responds to the point instead of sending a questionnaire afterward.

What to do if the form is already built and cannot be broken

No need to break it: we leave the markup, handlers, and request transfer to the accounting system as they are, and rework the presentation layer and field order.

Changes in markup and styles do not change where the request goes—the working scenario is not lost, and the contact page design is improved point by point, without restarting the project.

Field order is the first lever. Simple and "cheap" fields for the person go first, heavy ones—company, budget, comment—after, when they have already invested in filling it out.

We move hints from disappearing placeholders inside the field to a permanent label: on narrow screens and with autofill, the placeholder disappears, and the person loses orientation.

Errors and confirmation are the second lever. Validation is shown next to the specific field, not as a single line under the button: it is clear what exactly to fix, and there is no need to recheck the whole form.

After submission—explicit confirmation: who will contact you, through which channel, and within what timeframe; a second click does not create a second request.

Step analytics closes the work. Events on focus, first change, validation error, and successful submission show at which field people drop off and how many steps they actually pass.

Then changes target the bottleneck, not the entire form, and the result is compared with previous numbers on the same funnel.

Technical doubts: validation, map, spam protection

The contact page is the only place on the site where a visitor leaves their data, and mistakes in it are immediately visible: some requests are lost in the middle of the form, some do not arrive because of a third-party module failure.

Below is a breakdown of the questions that most often come up during evaluation: required fields, map behavior on a weak connection, protection from automatic submissions, and form suitability for keyboard and screen reader.

What about the map if the connection is weak?

The map loads separately from the form and does not block its operation: while the interactive layer is not ready, we show a static fragment, and duplicate the address and landmarks in text.

Request submission does not depend on map loading—with third-party scripts disabled, the form continues to work.

How do you stop automatic submissions?

Three lines of defense: a hidden honeypot field, completion time check, and rate limiting of inquiries from one address. Character-entry protection is installed last—it noticeably cuts the number of real inquiries, so we enable it only when there is a real flow of junk.

Does the form work with keyboard and screen reader?

Yes, and this is checked before release, not after. The field tab order matches the visual order, each field has an associated label, error messages are read as text, not only by border color.

Each element receives visible focus—otherwise keyboard navigation formally exists but cannot be used.

Let's discuss the task: contact audit and rework plan

To move from general words to an estimate and plan, we need access to the current state of the contact page and data on how requests actually reach the manager.

Based on these inputs, we calculate the scope of work, give timelines, and show which form fields and checks produce growth—without assumptions about "how your setup is configured."

Below is what needs to be sent at the start. If something is missing, we will restore part of it ourselves, but this will shift the timelines.

• Access to analytics for the contact section: path from view to submission, sources, failure share, statistics on calls and messenger transitions.
• Current layouts—source files in a working format or an export with grid, fonts, and field states, so that what has been approved is not rebuilt from scratch.
• Description of the request handler: where the email goes, how it is duplicated in the accounting system, who is responsible, and how notifications are configured.
• Examples of inquiries from recent months, including empty, erroneous, and repeat ones—they show which fields are missing.
• Platform constraints: website management system, mobile version, security department requirements, and personal data storage rules.
• Data on addresses and the map: legal address, points, time zones, whether route plotting is needed.
• The person responsible for acceptance and the procedure for approving changes.

Describe the task in free form—we will come back with an estimate and plan: what we do first, where the bottleneck is, and what result we will check a month after launch.