06 Nov Finding Real Pain Points: What’s Actually Frustrating Your Website Visitors
*Part 3 of Start the UX Design Process — a series on the UX principles I use in client work.*
Every business owner has heard a version of this sentence: “Your website is fine, I just couldn’t find…” And then the sentence trails off, because the visitor already solved their problem somewhere else. That unfinished sentence is a pain point. It is also the most valuable information your website can give you, if you learn to catch it.
A pain point is not a vague feeling. It is a specific moment where a real person, trying to do a real job, hits friction: confusion, a dead end, a delay, a worry, or an extra step that should not exist. Finding those moments — before you redesign — is what keeps a redesign from being an expensive coat of paint on the same problems.
### Pain points are moments, not opinions
“I don’t like the homepage” is an opinion. It tells you nothing you can fix. “I opened the site on my phone in the parking lot, tapped three menus, and still couldn’t find the parking info” is a pain point. It has a person, a moment, a device, and a failed job. You can design against that. You cannot design against “I don’t like it.”
That distinction is why the interviews in the last post mattered. When you ask people about the last time they tried something, pain points show up as stories: the page that loaded too slowly on a weak signal, the form that asked for information nobody had handy, the donate page that never explained what a donation actually does, the event page that listed a date but not a time. Each story points at a fix. Opinions point at arguments.
I keep a simple test for whether something counts as a pain point. Can I describe it as a visitor trying to do one thing, and something specific getting in the way? If yes, it goes on the list. If it is just a preference — “I wish it were blue” — it waits. Preferences are endless. Pain points are finite, and they are where the lost business lives.
### Make the pain points visible: the empathy map
Stories from interviews are rich, but a stack of notes is hard to design from. The tool I use to make them visible is a simple four-square chart called an empathy map — one map per person you talked to, built from that person’s interview alone.
The four squares are: what they said, in their exact words; what they seemed to be thinking, including things their tone or hesitation suggested; what they actually did, the steps they took to work around the problem; and how they felt about it — worried, rushed, embarrassed, relieved. When a feeling was never named outright, the question “how did that make you feel?” is worth asking directly, because feelings are often the real reason a visitor quits.
Two cautions keep a map honest. First, a thought you inferred is not a fact the visitor stated: if somebody worries about a stranger in their home, you can infer they want a screened, trustworthy helper, but you cannot record that they demanded a background check unless they said so. Mark inferences as inferences and check them later. Second, do not summarize quotes into your own words in the “said” square — summaries smuggle your interpretation in; exact words keep the visitor’s voice in the room.
Once you have a map per person, lay them side by side and build one combined map for the group: the thoughts, feelings, actions, and phrases that repeat across people. That combined map is where pain points stop being anecdotes and start being evidence. A frustration that appears on one map is a lead. A frustration that appears on four maps, in different people’s words, is a design priority — and it is the material the next post groups into personas.
### Where pain points hide on a small business site
They hide in the same places, over and over. Navigation is the first one: labels written the way the business talks internally, not the way a customer searches. “Ministries” means something to a church member and nothing to a guest who just wants service times. “Programs” means something to a nonprofit’s staff and nothing to a donor who wants to give.
Forms are the second hiding place. Every field you add is a small tax on the visitor’s patience, and most forms were built by copying every question the office ever wanted to ask, not by asking what the visitor needs to give to get started. A long form is not thorough. It is a filter that only the most patient visitors pass.
The third hiding place is missing reassurance. A visitor who is about to donate, book, or register is asking silent questions: Is this legitimate? What happens next? Will somebody actually call me back? If the page never answers those questions — with a clear next step, a phone number, a plain-English explanation of what happens after they submit — hesitation turns into abandonment, and nobody ever tells you why. They just leave.
And the fourth is the phone itself. Most of your visitors are on a phone, often in a hurry, often on a weak connection. A page that works beautifully on a desktop monitor can be a pain point factory on a small screen: tiny tap targets, text buried under a photo, a schedule rendered as an image nobody can zoom or search. If you have only ever reviewed your site on a computer, you have not reviewed the version most people see.
### How to collect them without a big project
You already have three pain-point sources sitting in your business. First, the questions people ask you by phone and message. Tally them for a month. If the same question keeps arriving — “where do I park?”, “what time does it start?”, “how do I sign my kid up?” — that question is a pain point wearing a polite disguise. The site should have answered it, and did not.
Second, the tasks people abandon. A form started but never submitted, a registration page visited but never completed, a donate button clicked but never finished. You do not need fancy analytics to notice the pattern; you need to ask what the page demanded at the exact moment people left.
Third, the workaround. When visitors invent their own solution — messaging you on social media instead of using the contact form, calling to ask what the site should say, showing up and asking in person — the workaround is pointing straight at the pain point. People do not work around a site that works.
Write each pain point down in the visitor’s words, with the job attached: “Parent on a phone, trying to find the festival schedule, couldn’t find parking info.” That one line is more useful than a whole page of redesign notes, because it tells the designer exactly what to fix and how to test whether the fix worked.
### Sorting what you found
Not every pain point deserves equal attention. I sort them with two quick questions. How often does it happen? And how much does it cost when it does — a lost donation, a missed registration, a phone call your staff has to field anyway? A pain point that hits every first-time guest and costs you a visit outranks a pain point that annoys one person once a year.
The top of that sorted list is where your redesign should start. Not with the homepage slider. Not with the color scheme. With the moment that keeps frustrating the people you most want to serve.
That sorted list also feeds everything else in this series. The next post turns those repeated, mapped moments into personas — not fictional characters, but useful summaries of the real people behind the pain points — so the whole project team remembers who they are designing for.
—
*Seeing the same questions and drop-offs on your own site? I build and redesign websites for small businesses, non-profits, and churches across Eastern NC. [Get a free quote](/) or [see recent work](/web-design/).*
*Previous in this series: [Listening Like a Designer](/empathy-interviews-small-business-website-research/) · Next: [Personas That Aren’t Fiction: Building Useful User Personas for a Website](/user-personas-website-not-fiction/)*
> *This article is my own take, in my own words, on UX principles I use in client work. It is not affiliated with or endorsed by Google or Coursera.*