
Your website isn’t for you: designing for the people who actually arrive
Most of the website rebuilds I work on start with a comparison something like “our competitors look better than us.”
It’s a pretty natural response. You've seen a rival’s new site. It’s sleek, loads fast, and actually works. You wish you had it.
This reminds me of The Prestige. If you’ve not seen it, it’s about two rival magicians and one trick. Christian Bale’s Borden performs The Transported Man: he steps through one door and instantly walks out of another across the stage.
His rival, Angier, can’t stand it. He tries to steal the secret, then builds his own version, pouring everything into a trick he still doesn’t understand.
It works, sort of. The trick lands every night, but Angier spends it stuck beneath the stage while someone else soaks up the applause.
What you’re seeing is the trick. What you can’t see are the decisions underneath it. Why their customers visit. The questions their sales team fields every day. Who updates the site on a Tuesday afternoon, and how long it takes. Copy the look without the thinking, and you’re Angier, stuck under the stage.
When building your website strategy, start backstage with whatever is pushing you to rebuild and work outwards from there, until the site is built around the people who use it.
It’s not magic, just human-centred web design!
Why you're rebuilding
I talk to a lot of marketing managers and business owners about their websites. Their reasons for a rebuild fall into three buckets: the problems, the wish-list, and taste.
The problems
These are the things that are broken.
Maybe the person who managed the website left and took the logins and the know-how with them. Maybe three agencies have worked on it over five years, and each one left something behind in the back end. I call that content debt: old pages, orphaned plugins, half-finished sections nobody wants to delete fearing the house of cards collapses. Maybe the menu doesn't match how people look for things. Maybe every page was written for Google for so long that a human can't get through it.
Problems are the easy ones, because you can prove them. Analytics shows where people drop off. Search Console shows how your pages perform in search. Software like Microsoft Clarity gives you heatmaps and session recordings, so you can watch people get stuck. Most of the time the data backs up what your team already knows, and those become the obvious fixes.
The wish-list
These are the wants: a quote calculator, a product configurator, a proper FAQ section. Wants are fine, wants are fun, but they need to earn their place. A want turns into a need when you can see the behaviour behind it. If people click around hunting for pricing, or leave the pages that should convert them, that calculator is now solving a real problem.
Taste
Then there's taste. "We don't look modern." It's the hardest of the three to measure but the easiest to jump to. A new look is visible and exciting in a way a fixed menu never will be.
If you start with taste, you skip the other two. And when you do the research properly, you nearly always find problems nobody came in with. Problems first, then wants, then taste.
Taste without strategy
It’s never been a better time to have no taste. You can describe your dream website to AI and have something shiny live by the afternoon. Which brings the fair question: why would I pay an agency for a strategy when I can build it myself?
What worries me is the thinking that gets skipped. A tool that builds you a homepage in ten minutes hasn't looked at your analytics, hasn't heard what your sales team gets asked, and has no idea who on your team will update the site next year.
AI is still poor at user experience, simply because it’s never had a human experience. It’s never had to cancel a subscription. It’s never filled out a form twice because it timed out. It doesn't use websites the way people do, so it can't tell you where people get stuck on yours.
You can’t polish a bad user experience, but you can polish it in glitter. Taste without strategy still tastes bad, no matter how bedazzled.
UX starts with research
People say "UI/UX" like it's one word. It's a handy thing to drop into a proposal to sound a bit more qualified. They're different jobs, though. UI is how the site looks and behaves on screen. UX is whether people can do what they came to do.
Good UX starts with research, and the research is less glamorous than you'd hope:
- An analytics baseline. GA4 and Search Console tell you which pages people land on, where they leave and what they searched to get there.
- Behaviour data. Clarity heat maps and recordings show where people click, how far they scroll and where they give up.
- The people on the front line. I talk to whoever answers the phone and whoever sells. They hear the same questions every week, and those questions belong on the website.
What comes out the other end is a short list of top tasks: the handful of things most people visit your site to do. Everything after this gets measured against that list.
User stories
I’m happy to use the word “user”. Some people in human-centred design avoid it, as if it strips the person out. But while people bring their whole lives to your website, when they’re on it they’re trying to get something done. We aren’t solving every problem in their life. We’re making that one task easy.
So instead of personas I write user stories. The format fits on one line:
As a [who], I need [what], so that I can [outcome].
For example:
- As a facilities manager, I need to see which products suit a site like mine, so that I can shortlist two before I call anyone.
- As a first-time customer, I need a rough price before I enquire, so that I don't spend a sales call on something outside my budget.
Each story becomes a requirement. If people need a rough price before they enquire, the site needs a pricing guide or a calculator, placed where they look for it. I check every story against the interviews and the data, so we build around what people in that industry do.
Your team are users too
This is the user that gets forgotten most. Business owners and marketing managers not being able to edit their own website is the biggest pain point I hear.
The problems are very familiar. You, Dilate website user, have probably experienced at least one:
- Every change needs a developer, so small updates sit in a queue.
- The page builder is slow and fiddly, and nobody trusts it.
- Mobile layouts need fixing by hand, page by page.
- Nothing is connected. Projects, services and case studies share no tags or filters, so you update the same thing in four places.
The wish-list comes back into play here too. A quoting calculator can send your sales team better-qualified enquiries. A configurator takes manual work off your staff. FAQs that answer what reception gets asked on the phone every day. Each of these helps a customer and someone inside the business at once.
Your team gets user stories like everyone else: As the marketing manager, I want to post a new project in a few minutes, so that the website stays up to date.
That story shapes how we design the back-end experience.
My standard is pretty simple. The least tech-confident person on your team should be able to make the change they need without blood, sweat, or tears. Editing your own website shouldn't feel like surgery.
Structure before style
Once the research and the user stories are done, I start on paper. Every wireframe I do begins as a pen-and-paper sketch. It's the quickest way to test a flow and actually think through each decision before anything looks finished.
Then I build a prototype in Figma, in greyscale. No images, just grey boxes where they'll go, set in our house style, which is about as exciting to look at as it sounds. Deliberately! With the glitter stripped out, we can focus on the important questions. Does this give people everything they need? Is every step clear? Can they finish their top task without hunting? Figma lets us link the screens into clickable flows, so you can walk through the site the way a customer would.
I've sat in a lot of homepage design reviews. Most of the feedback lands on colours, fonts and image choices. No one is commenting on the structure, because we are distracted by the pretty stuff. Vibe coding drops you straight into that moment and skips everything underneath.
So decide what goes on the site, and why, in the strategy, before anyone is booked for the build. That way, when design and copy start, they work on a structure everyone has already agreed on, and the conversation about taste gets to be about taste.
There's plenty more to say about search, AI visibility and conversion, and it deserves its own article.
Before you brief anyone
You don't need an agency to start.
- Install analytics and Microsoft Clarity now (with the proper consent, of course), so you have a baseline.
- Sit with the people who answer the phone and sell. Find out which questions they are sick of answering.
- List the top tasks people come to your site to do.
- List what your team struggles to update, and how long each update takes.
- Write three user stories, and make one of them for your own team.
Bring that into your first meeting with any agency and you'll get a better website, whoever builds it.
When your site is doing the job for the people visiting it and the people running it, you've got human-centred design.








