Short answer: friction is anything standing between a visitor wanting something and having it, and on most service sites almost all of it is administrative rather than persuasive. A form that asks for too much, loses what you typed, and promises a reply nobody sends will cost more enquiries than any speed problem — and all of it is fixable in an afternoon.
Three kinds of friction, and only one is about psychology
The word gets used loosely, which makes it hard to act on. It helps to separate three things that feel similar from the inside:
- Technical friction. The page is slow, something is broken, the form does not work on a phone. Unambiguous and measurable.
- Cognitive friction. The visitor has to work out what you want them to do, or what happens if they do it. Fixed by saying things plainly.
- Process friction. You are asking for work the customer does not want to do. Every field, every confirmation, every intermediate step is work they did not agree to.
Only the third is really about persuasion, and it is the most commonly ignored. Most sites have spent effort on the first and none on the third.
Nielsen Norman Group’s heuristics frame the same problem more usefully: users should not have to remember information across pages, should be able to undo mistakes, and should be told what is going on. [4] Most form failures are breaches of exactly these.
Key takeaway: friction is not persuasion resistance. It is the visitor being asked to do something unreasonable, and it is countable.
Forms are where the losses are
If you only fix one thing, fix the form. It is the narrowest bottleneck between interest and a contact, and it has an unusually well-documented set of failure modes.
Nielsen Norman Group’s form guidance is worth reading in full, but the summary is that forms fail through over-collection, unclear labelling and poor error handling — not through visual design. [1] The specific things to check:
- Placeholder text used as the label. This is worth singling out because it is so common and so bad: the instruction disappears as soon as the user starts typing, so anyone interrupted now has an empty box with no label. Their research is unambiguous on it. [2] Use a persistent label and put the hint underneath in smaller text.
- Fields you do not need. Every one costs completions. If you can infer it, infer it. If you can defer it, defer it. If you want marketing data you are not authorised to collect, buy it.
- Errors that discard input. Anyone who mistypes an email address should not have to complete the form again. This is the most reliably expensive bug on the list and it is invisible in analytics, which only counts what completed.
- No indication what happens next. If the confirmation says nothing, the visitor does not know whether it worked and many will send it twice.
The two interventions worth arguing about
A real booking calendar. For a business with genuine availability this is usually the single biggest booking improvement available, because it removes the whole enquiry conversation — no waiting, no uncertainty, no “are you actually free”. It requires one thing to work: you must be able to honour what it shows. A calendar offering slots you cannot take, or generating a confirmation you do not send, converts an honest low-commitment contact into a silently broken promise. That is worse than asking.
A published price or benchmark. “Contact us for a quote” makes every visitor do work, because the price is the actual question. Even a range, or an explanation of what drives the price, moves the conversation past that point. It will also filter out enquiries you did not want, which is usually the second benefit people notice.
Both of these are business decisions before they are website decisions. Worth having the meeting before commissioning the work.
What to check for a modal over the button
One specific thing worth auditing this month: is there a newsletter popup or cookie banner appearing over your primary call to action?
It is nearly invisible to the owner of a site, because it does not appear when you are logged in on a desktop. On a phone, for a first-time visitor, it routinely covers the button the page exists to press. This removes the action for every new visitor permanently, and it usually ships without anyone noticing because the team all have cookies set.
| Step | What it should do | What usually goes wrong |
|---|---|---|
| Land on service page | Answer what they came for | Throat-clearing intro pushes it down |
| Find the action | One obvious next step | Competing buttons and a modal over it |
| Start the enquiry | Explain what is needed | Nine fields, three of them optional |
| Make a mistake | Keep what they typed | Form resets, everything gone |
| Submit | Say what happens and when | Silence, so they send it again |
Readers scan rather than read in sequence, so the order things appear in is doing more work than the prose. [5] Read down the right-hand column of your own site. That table, filled in honestly, is your friction list — and it is a better starting point than any audit tool.
Speed: real, measurable, and smaller than advertised
Performance matters. Core Web Vitals track how quickly the main content appears and how quickly the page responds to input, and slow pages lose real people on real connections. [3] That is worth fixing.
But three claims attached to speed are not worth fixing anything for:
- That page speed determines how often AI systems crawl you. Crawl budget is a concept for sites with millions of URLs; a site with forty pages has effectively unlimited budget relative to its size.
- That a slow page gets crawled quarterly instead of weekly. Not a documented behaviour.
- That fast sites are cited more by assistants. No evidence for it.
Fix speed because your customers are waiting, not because a bot is keeping score. The responsiveness article separates the real signals from the invented ones in more detail.
What to do first
- Open your contact form on a phone, as a first-time visitor with cookies cleared. That alone finds the worst problems.
- Delete every field you do not strictly need to complete the job.
- Replace placeholder labels with real labels and a hint underneath.
- Check what happens after someone submits. Say what happens and when.
- Check for a modal covering your primary button on mobile.
- Only then look at speed.
How this connects
- Capture and book covers the whole path rather than the bottleneck.
- Direct directives covers the step before the form.
- Responsiveness and speed covers the technical half honestly.
- Headlines that command attention covers whether they get to the page at all.
