Design guide / Qualified inquiries
Help the right visitor make an informed next step.
A lead-generation page has more work to do than attract a click. Visitors need to understand the offer, judge whether it fits, know what they are being asked to share and complete the next step without avoidable difficulty. Design that journey together with the team that receives the inquiry.
Define the conversion you mean
A submission is one event in a longer journey.
Imagine a visitor comparing providers for a service. They need to establish fit, understand the next step and send enough context for a useful response. The receiving team needs a readable inquiry and a clear owner. A button click, a successful submission and a qualified opportunity describe different things.
- Clarity supports self-selection
- Explain the work, relevant constraints and the purpose of the next step. A visitor deciding that the offer is unsuitable can be a useful outcome.
- Usability supports completion
- Make the intended action understandable and operable. A person should be able to recover from a mistake without losing their place or guessing what happened.
- Qualification needs an agreed definition
- The business must decide what makes an inquiry relevant. Design and reporting should use that definition instead of equating every contact with an opportunity.
Six visitor questions
Review the decision before redesigning the button.
Walk through an illustrative service inquiry from arrival to receipt. Each question suggests a concrete review task, not a guaranteed conversion tactic.
Understand the offer
01Visitor question: Is this relevant to the problem I am trying to solve?
- Design purpose
- Let the visitor recognize the service, its intended use and the next decision.
- Starting evidence
- The actual offer, audience questions, known constraints and the language visitors use.
- Review the journey
- Ask a representative visitor to explain the offer in their own words after reading the page. Note where headings, examples or navigation leave them guessing.
- Decision owner
- The service owner confirms the facts; the content and design team make them understandable.
- Useful evidence
- Observed explanations, misunderstood terms and a revised content hierarchy.
- Does not establish
- That every visitor understands the page or that clearer wording causes more sales.
- Handoff implication
- The receiving team should hear inquiries about the service the page actually describes.
Assess the basis for trust
02Visitor question: What supports these claims, and what is still uncertain?
- Design purpose
- Give the visitor relevant, attributable information for judging fit.
- Starting evidence
- Approved service facts, publishable work, attributable evidence and limits on disclosure.
- Review the journey
- Place supporting information near the claim it explains. Distinguish a delivery approach from a demonstrated result, and remove unsupported badges, numbers or testimonials.
- Decision owner
- The business owner approves factual claims and permission to publish evidence.
- Useful evidence
- A claim-to-source review and visitor feedback about unanswered questions.
- Does not establish
- That a polished appearance or borrowed logo establishes capability.
- Handoff implication
- The next conversation should not begin by correcting an expectation the website created.
Understand the proposed next step
03Visitor question: What will happen if I use this action?
- Design purpose
- Make the action match the visitor's readiness and the actual receiving process.
- Starting evidence
- The destination, information required, responsible team and confirmed follow-up process.
- Review the journey
- Check whether the action label predicts its destination. Explain whether the visitor is making an inquiry, requesting a meeting or completing another specific task.
- Decision owner
- The receiving owner defines what the action initiates; the designer expresses it clearly.
- Useful evidence
- A visitor can describe the next step before activating it, and the destination matches.
- Does not establish
- That a more prominent action is more appropriate for every visitor.
- Handoff implication
- Use only follow-up expectations the team can actually support.
Provide the necessary context
04Visitor question: Why do you need this information, and can I answer it?
- Design purpose
- Collect what the receiving process needs without turning the first inquiry into an unnecessary intake exercise.
- Starting evidence
- The purpose of each field, required and optional information, and valid uncertain answers.
- Review the journey
- Review each question with the receiving team. Explain unfamiliar requests, identify optional fields and use the minimum information needed for this stage. Test related questions together rather than assuming one universal form length.
- Decision owner
- The business owner justifies each request; design and engineering make the form understandable and accessible.
- Useful evidence
- A field-purpose record and observed completion with relevant users.
- Does not establish
- That fewer fields always produce better inquiries or that field count measures accessibility.
- Handoff implication
- Defer information that can be gathered more appropriately during the next conversation.
Complete and correct the interaction
05Visitor question: Can I use this, correct a mistake and know whether it worked?
- Design purpose
- Make the whole form usable across input methods and its success and failure states.
- Starting evidence
- Labels, instructions, validation rules, submission states and the receiving system's behavior.
- Review the journey
- Test keyboard access, understandable errors and confirmation. Retain appropriate entered information after validation errors and check that a reported success corresponds to the intended receipt event.
- Decision owner
- Engineering owns submission behavior; design and accessibility reviewers assess the interaction.
- Useful evidence
- Observed valid, invalid and failed submissions in an authorized test environment, including the receiving side.
- Does not establish
- That a thank-you screen proves a human has read the inquiry or that one browser check establishes accessibility conformance.
- Handoff implication
- Assign an owner for received inquiries and for delivery failures.
Use the page under real conditions
06Visitor question: Will the page respond and stay in place while I use it?
- Design purpose
- Keep loading, responsiveness and visual stability part of the actual inquiry journey.
- Starting evidence
- Representative devices, network conditions, interaction traces and available field measurements.
- Review the journey
- Inspect slow loading, delayed interaction and content movement around the action and form. Use lab checks to diagnose problems and field data to understand the experience visitors actually receive.
- Decision owner
- Engineering owns performance work; the product owner balances media and interface choices against the task.
- Useful evidence
- Scoped lab results and available field measurements, with missing coverage stated.
- Does not establish
- That a performance score establishes lead quality or a commercial effect.
- Handoff implication
- Review added media, scripts and integrations for regressions in the inquiry path.
Keep the measures distinct
Choose evidence that answers the question.
Agree event meanings and qualification rules before comparing results. Report missing or excluded data rather than turning it into zero.
| Question | Evidence | Cannot prove alone | Responsible interpretation | Example distinction |
|---|---|---|---|---|
| Was the action noticed? | Observed discovery or clicks | Understanding or intent | Design and research | Click is not submission |
| Was the form completed? | Validated submission event | Successful receipt | Engineering | Client event is not delivery |
| Was the inquiry received? | Receiving-system record | Human follow-up | Operations | Receipt is not response |
| Was the inquiry relevant? | Agreed qualification review | A sale or revenue | Business owner | Relevant is not won |
| Could people use the flow? | Task and accessibility checks | Every user's experience | Research and accessibility | Automation is partial evidence |
| How did the page perform? | Lab and field measurements | Conversion causation | Engineering and product | Fast is not persuasive |
Review one complete inquiry
Find the point where the journey stops making sense.
Start with an observed problem and a specific question. A large visual redesign is not required to investigate an unclear offer or a broken handoff.
- 01
Agree the intended visitor and outcome
Describe the relevant need and what makes an inquiry useful. Separate this from a revenue target or a general wish for more traffic.
- 02
Map the path and its claims
Follow the entry page, supporting information, action, form, confirmation and receiving process. Record where ownership or evidence is missing.
- 03
Observe a realistic task
Ask actual or likely users to complete a relevant task with neutral instructions. Include the devices and access needs that matter, and observe where they hesitate or misunderstand.
- 04
Repair the specific problem
Change the content, interaction or handoff that caused the difficulty. Test valid, invalid and failed states rather than checking only a perfect submission.
- 05
Evaluate the right result
Compare evidence against the original question. Keep usability observations, performance measurements and qualified-inquiry outcomes separate, with traffic or measurement changes disclosed.
Keep the optimization honest
Improve the decision without pressuring the visitor.
A website should help a person decide and act. Review tactics against the real offer and the responsibilities of the team receiving the inquiry.
- Use only supported proof
- Do not invent testimonials, availability, scarcity, credentials or results. An illustrative example must remain clearly distinguishable from client evidence.
- Respect the scope of the inquiry
- Explain the request and avoid collecting unrelated information. Treat follow-up and measurement permissions as decisions for the responsible organization, not assumptions embedded in the interface.
- Maintain access to the action
- Check keyboard focus, readable content, zoom and mobile behavior. Essential information should remain available without a hover, animation or precise pointer movement.
- Review quality alongside volume
- Watch for duplicate, irrelevant or misrouted inquiries. A higher count may reflect a different audience or a measurement change rather than a better visitor journey.
Questions about lead-generation design
Judge the experience through the task.
Useful answers depend on the audience, the offer and the process after submission.
- What is the difference between UX and UI here?
- UX covers the wider journey: understanding the offer, deciding what to do, completing the inquiry and knowing what follows. UI covers the visible and interactive elements through which much of that journey happens. They need to be reviewed together.
- Should the form be as short as possible?
- Ask only what is needed for the current step, with a reason for each question. A shorter form that leaves the receiving team unable to understand the request may simply move the work elsewhere. Test the questions and their purpose with the actual process.
- Will a faster page generate more qualified leads?
- Performance supports the experience, but a speed measurement does not establish a commercial effect. Google distinguishes loading, interaction and stability through Core Web Vitals and separates field experience from lab diagnosis. Lead quality needs its own evidence.
- Can an automated audit establish accessibility?
- An automated result covers the checks it performs. The inquiry flow also needs manual and task-based review, including appropriate assistive-technology coverage. Do not turn a clean scan into a claim of complete conformance.
- Should we test button colors first?
- Investigate the observed difficulty first. If visitors misunderstand the offer, cannot explain the next step or encounter a submission failure, a color experiment does not answer that problem. Use a specific hypothesis and a relevant measure.
Source basis
Sources behind the control model.
- 01
W3C Web Accessibility Initiative
Forms TutorialUpdated March 2026. Covers labels, grouping, instructions, validation and feedback. These techniques support form use but do not establish a complete conformance assessment.
- 02
W3C Web Accessibility Initiative
User NotificationExplains clear success and error feedback, identifying affected controls and helping users correct mistakes. The receiving-system check is an additional operational concern.
- 03
GOV.UK Design System
Question pagesRecommends a reason for every question, clear optional information and research-informed grouping. Government-specific layouts and button labels are not universal marketing rules.
- 04
Google web.dev
Web VitalsDefines loading, interaction and visual-stability measures and distinguishes lab checks from field experience. It does not establish a conversion result for this article.
- 05
GOV.UK Service Manual
Using moderated usability testingDescribes observing relevant users on realistic tasks with neutral instructions, including assistive-technology considerations. No fixed study size or conversion uplift is inferred.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD