The quote form on your website works. Enquiries come in. Yet the sales team phones back almost every one to ask the same questions: what flow rate, what pressure, what fluid, how many units? Some visitors give up halfway and ring instead; the ones who visit after hours never come back. It is tempting to ask a designer to make the form look nicer. Looks are not the problem.
This article follows one scenario throughout: the quote form of a mid-sized industrial pump manufacturer in the West Midlands that sells through distributors and directly to contractors. You will see what happens at each step, from research and prototyping to testing, handover and post-launch measurement, and which steps you can't skip. The same method works for a checkout or a booking flow.
Research: who do you listen to before you design?
Research starts with a plain question: what don't we know? In the pump example, that meant what customers have to hand when asking for a quote and what sales actually needs to price a job. We gathered answers from four sources.
Stakeholder interviews
One-to-one conversations, an hour at most, with someone from sales, technical support and production planning. The question is simple: when an enquiry arrives, what happens, and where does it get stuck? Two things came out. Several fields on the form were never read by anyone. And the information sales needed most, the fluid temperature and whether it contained solids, was not asked for at all.
The questions that worked best in these conversations:
- Which details are essential before an enquiry can become a quote?
- When you call a customer back, what do you ask most often?
- Which enquiries do you not take seriously, and why?
- If the form changed, what would change in your day-to-day work?
User interviews
Next we spoke to real customers: buyers at distributors and engineers at contracting firms. Even five or six interviews reveal a great deal. Ask questions that don't lead: “Talk me through the last time you asked for a quote” works; “Was our form easy?” does not. People are fairly honest when describing what they did, much less so when predicting what they will want.
If you record sessions, tell participants beforehand and get their agreement. Under UK GDPR and the EU GDPR, research recordings are personal data like any other, so you need a lawful basis and a clear privacy notice.
Analytics
In Google Analytics 4, with the form interactions option of enhanced measurement switched on, the form_start and form_submit events show how many people start the form and how many send it. That automatic event isn't reliable with every form set-up, so tracking successful submissions with a separate event on the confirmation screen is safer. A funnel exploration under Explore shows where visitors came from and where they dropped out. Session recordings and heatmaps (Hotjar or Microsoft Clarity, for instance) show where people hesitate; don't run them without cookie consent.
Competitor and pattern review
Look at competitors' quote forms and good examples from other sectors, not to copy but to see what customers are used to. A framework such as Nielsen Norman Group's ten usability heuristics keeps the review away from “I quite like this one”.
Each method answers a different question, and none is enough on its own:
| Method | What it shows | What it doesn't show |
|---|---|---|
| Stakeholder interview | Business goals, internal processes, constraints | How customers actually behave |
| User interview | Needs, context, the words customers use | How many people share the problem |
| Analytics | Where people drop out, and how many | Why they drop out |
| Session recordings and heatmaps | Hesitation, repeated clicks, scrolling | Intent and what the user was thinking |
| Competitor review | Sector conventions and gaps | Whether a competitor's solution works |
| Usability testing | Where people get stuck on real tasks | How often it happens across your audience |
Personas or jobs to be done?
Plenty of projects end their research with a persona poster: “Procurement Manager Dave, 42, two children, takes his coffee black.” Dave's age does not tell you which field should be mandatory.
The alternative is the jobs-to-be-done approach associated with Clayton Christensen. The question becomes: in what situation, and to reach what outcome, does the customer “hire” this product or this form? In the pump example two separate jobs emerged:
- The distributor: “My customer is waiting. I have a model number; I want a price and lead time quickly so I can get back to them.”
- The contractor's engineer: “I need the right pump for a new installation. I'll give you the duty point; I want the right model and the datasheet.”
One form was doing both jobs badly. The distributor didn't want to fill in fourteen fields; the engineer couldn't find anywhere to enter the technical data. The core of the fix was a single question at the start: “Do you have a model number?”
That doesn't mean binning personas. Nielsen Norman Group argues the two tools complement each other, and research-based personas that describe behaviour help a team build empathy. Our preference: for B2B forms, checkouts and tool-like interfaces, write the jobs first and add personas later if needed.
Information architecture and card sorting
Information architecture is how content is grouped and labelled: what's in the menu, which page sits under which, what the categories are based on. On the pump manufacturer's site, products were listed by the company's internal logic, by product series. Customers searched by application: wastewater, fire protection, HVAC, food processing.
You solve that with card sorting, not guesswork. In an open card sort, participants get content cards and are asked to create and name their own groups. In a closed sort the groups are fixed and participants place the cards into them. Nielsen Norman Group recommends around 15 participants for an open card sort in most projects, and tools such as Optimal Workshop let you run it online.
To validate a new structure, tree testing fits better: participants see only the menu hierarchy as text and get tasks such as “Where would you find the datasheet for a wastewater pump?” With visual design out of the picture, you measure the structure itself.
User flows and wireframes
A user flow maps the steps someone takes to reach their goal. For the quote form we drew one per job: the distributor with a model number and the engineer arriving with technical values. Draw the exceptions as well as the happy path. What if the user doesn't know the unit, the file upload fails, or the form is sent at midnight?
A wireframe is that flow in grey boxes. Colour, photography and typefaces are left out on purpose, so the discussion stays on “should this field be here?” rather than “should this be blue?” Use real copy in wireframes. A form field labelled “Lorem ipsum” means nobody has thought about its help text or error message either.
These were the decisions made at wireframe stage in the pump example:
- Two routes from the start: “I have a model number” and “Help me choose the right pump”.
- Four fields on the distributor route: model, quantity, required delivery date, contact details.
- A step-by-step form on the engineer route, one topic per step: application, fluid, flow and head, extra details, contact.
- Unit selection (m³/h or litres per second) inside the field, so nobody has to reach for a calculator.
- A “Not sure” option on every technical field. Unknown values can be skipped, and the sales team sees that in the enquiry.
Clickable prototypes and testing with a handful of users
Once the wireframes are agreed, a clickable prototype is built in Figma: not a coded site, but close enough to the real thing that buttons work, steps advance and error messages appear. Always try the mobile design on an actual phone; Figma's mobile app opens prototypes on a real screen. Remember that an engineer may be requesting the quote on site, one-handed, in the rain.
You don't need to prototype every screen, only the ones your test tasks pass through. A low-fidelity prototype in grey boxes tests flow and structure. Copy, visual hierarchy and small interactions need a high-fidelity one. Try to test both at once and participants comment on the colours while you learn nothing about the flow.
How many users is enough?
Jakob Nielsen's advice, published in 2000 and based on a model he developed with Thomas Landauer in 1993, is still the most practical starting point: test with five users to find usability problems, fix them, then test again. His reasoning is that each additional participant mostly repeats problems the earlier ones already hit, so splitting the budget across several small rounds teaches you more than one large study.
The rule has limits. If you have very different user groups (distributors and engineers, in our case), you need participants from each. If you want to measure rates, such as how many people complete the form without errors, you need a quantitative study with many more participants. A five-user test finds problems; it doesn't prove how often they occur.
Running the sessions
- Give a real task: “Request a quote using these technical values.” “Have a look at the form” is not a task.
- Ask participants to think aloud, then keep quiet. Helping, hinting or saying “you could click there” spoils the test.
- Note where they get stuck, the words they use and what they expected. Asking what they liked is the least useful question.
- Bring an observer to each session, ideally from sales. A team that watches someone struggle with its own form is persuaded far faster than one reading a report.
- If you record, tell participants, get their agreement and decide how long you will keep the recordings.
Moderated sessions, in person or on a video call, let you ask “What were you expecting just then?” Unmoderated remote tests with tools such as Maze reach more people quickly, but you lose that question. Start with moderated rounds, and recruit from customers and distributors; colleagues make the worst participants because they know the product and jargon as well as you do.
In the pump example, engineers stumbled over unit selection in the first round, and distributors didn't know where the model number was printed on the rating plate. In round two a small image of the plate was added next to the field, and that problem disappeared.
Accessibility starts at the design stage
Treating accessibility as an audit item at the end of development is the most expensive route. Most of the decisions are made in design, where fixing them takes minutes. WCAG 2.2, published as a W3C Recommendation in October 2023, added criteria that bear directly on forms:
- Target Size (Minimum), 2.5.8, AA: pointer targets should be at least 24 by 24 CSS pixels or have enough spacing around them. Tiny checkboxes and crowded links are the usual failures.
- Focus Not Obscured (Minimum), 2.4.11, AA: a field that receives keyboard focus must not be completely hidden behind a sticky header or cookie banner.
- Redundant Entry, 3.3.7, A: information already given in the same process should not be requested again; it should be filled in automatically or be available to select. Making people type the billing and delivery address twice falls foul of this.
- Accessible Authentication (Minimum), 3.3.8, AA: logging in should not require a cognitive test, such as remembering a password, unless an alternative or a supporting mechanism is offered. Blocking paste in password fields, or blocking password managers, is therefore a bad idea.
- Dragging Movements, 2.5.7, AA: anything done by dragging needs a single-pointer alternative.
Add the older rules that still get broken constantly: contrast of at least 4.5:1 for normal text, a visible label on every field (placeholder text is not a label), error messages that don't rely on colour alone and that say how to fix the problem. For businesses selling to consumers in the EU, the European Accessibility Act, applicable since June 2025, takes these out of the nice-to-have column.
Design systems and developer handover
A design system is a library of the interface's reusable parts (buttons, form fields, alerts, step indicators) together with their rules. In Figma it is built from components and variants; in code, the same components are often documented in a tool such as Storybook. A quote form looks like one page, but it hides dozens of states.
Design every state of every component: default, hover, focus, disabled, error, loading, success. Hand developers a design that only shows the happy path and they will guess the rest, each in their own way.
Handover is more than sending a file link. A good handover pack contains:
- Measurements, colour and type tokens and exportable assets, for example in Figma's Dev Mode.
- Interaction notes: when each field is validated, when error messages appear, what happens after the form is sent.
- All the copy: labels, help text, error messages, the success screen and the confirmation email.
- Accessibility notes: focus order, field descriptions for screen readers, how errors are announced.
- A measurement plan: which analytics event fires at which step.
The designer's job doesn't end at handover. Short checks during the build and a review of every state on real devices before launch catch gaps between design and live site while they are small.
After launch: measure, learn, repeat
Real learning starts when the form goes live. Write down what counts as success before launch; afterwards it is far too easy to read the numbers however you like. The pump team chose three measures: the share of people who start the form and send it, how many enquiries still need a call-back, and the time from enquiry to quote.
Two of those three live in the sales team's CRM, not in web analytics. Good UX measurement tracks the work itself, not just the clicks.
Numbers tell you where the problem is, rarely why. A one-question survey on the success screen (“Could you give us everything you needed?”), or asking a customer who abandoned the form and phoned why, sometimes explains in one sentence what analytics can't.
If traffic is low, don't expect miracles from A/B testing; a meaningful result needs enough visitors, and on a small B2B site that can take a very long time. Small usability tests every few months, regular feedback from sales and an eye on big shifts in analytics are more realistic.
Where to start
- Pick one flow: the form, checkout step or application process that earns the most or attracts the most complaints.
- Spend an hour each with sales and support, and hear from them where the flow gets stuck.
- Pull the start and completion numbers for that flow from analytics. If there is no tracking, set it up first.
- Talk to five or six real customers about their last experience and write down, in one sentence, the job they were trying to get done.
- Draw wireframes with real copy, then build a clickable prototype.
- Test with five people, fix, test again.
- Put the accessibility criteria and every component state into the handover pack.
- Write the success measures before launch and come back to them afterwards.
At AYTE Digital we start design work in this order, with research and a prototype. If you have a form or flow that is causing trouble, we can look at it together and agree which steps it really needs and which you can safely skip.
