Websites designed around what you need them to do, not around a template
A website that looks good and converts nobody is a cost. Most of the design decisions that matter here are not visual ones: what the first screen has to say, how few steps stand between interest and an enquiry, and what gets cut. The visual work comes after those, and is much easier once they are settled.
What this covers
Web Design
Visual design for websites, built to hand off cleanly into development rather than existing as a disconnected mockup.
- Landing page design
- Design systems
- Responsive layouts
UI/UX Design
Interface design for websites and apps focused on how someone actually uses the product, not just how it looks in a mockup.
- Wireframing & prototyping
- Interface design
- Usability & accessibility
Conversion Rate Optimization (CRO)
Once traffic is arriving, CRO work looks at what's actually stopping visitors from converting: page structure, copy, forms, and load speed, and tests changes against real data.
- Landing page audits
- A/B testing
- Form & funnel optimisation
How this works in practice
The decisions that matter are not visual ones
What the first screen has to say, how few steps stand between interest and an enquiry, what gets cut: those settle how a site performs, and they are mostly made before anything is drawn. A page that looks excellent and buries the one thing a visitor came for is a cost, not an asset, and no amount of visual craft rescues it.
So the early conversation is about who lands on each page, what they already know, and what you want them to do next. The visual work comes after, and it is much faster once those are agreed. Starting with the look is how projects end up with six rounds of revisions that are really arguments about strategy.
Designed on a phone, because that is where the visitors are
Most traffic in this market arrives on a phone, usually from an ad or a social post, often on a connection that is not the office wifi. A design signed off on a 27-inch monitor and squeezed down afterwards tends to produce a phone layout nobody chose: the hero crops badly, the form is below three screens of scrolling, and the call button is where a thumb cannot reach.
Designing the narrow layout first forces the hard choices early, which is exactly why it works. If something does not earn its place on a phone, it rarely earns it on a desktop either.
Speed is a design decision before it is a technical one
Most slow sites are slow because of what was designed into them: a full-screen video header, a carousel of uncompressed photographs, four webfonts, and a stack of third-party scripts each loading on every page. Those are choices made in the design, and no amount of optimisation afterwards fully undoes them.
This site runs 100 on both desktop and mobile in Lighthouse, with layout shift at zero. That is not a tuning achievement, it is the result of deciding early what the page does not need to load.
Designed around the enquiry, not around the template
A template decides the shape of your page before anyone has asked what it is for, and the result usually reads like every other site using it. That is fine for a brochure and expensive for a page you are sending paid traffic to, where the gap between a good layout and an adequate one shows up directly in cost per enquiry.
The part most sites get wrong is the ask. One clear action per page, repeated where a reader is actually ready rather than only at the bottom, and a form that requests the minimum. Every extra field costs you completions, and most forms collect three things nobody ever reads.
Handover, and what you own
If someone else builds what I design, the handover is where quality usually leaks. A file a developer can build from has the states drawn rather than implied: hover, focus, error, empty, loading, and the breakpoints between. Without those, a developer invents them, and the result is a site that resembles the design rather than matching it.
You own the design files, the domain and the hosting account, regardless of who builds it. That sounds like a formality until the relationship ends and you discover the site is somewhere you cannot reach.
Frequently asked
- Do you design in Figma or straight in code?
- Figma for anything with stakeholders, because changing a decision is cheap there and expensive once it is built. Straight into code for a landing page where the layout is settled and the work is in the detail. I will tell you which one your project is rather than defaulting to the one that bills more hours.
- Can you design it if someone else builds it?
- Yes, and the handover is where these projects usually lose their quality. I hand over a file a developer can actually build from, with the states, the breakpoints and the edge cases drawn rather than implied. If you want, I will review the build against the design before it goes live.
- What about WordPress or Wix?
- Both are fine, and for a lot of businesses they are the right answer — you can run the site yourself without calling anyone. The design work does not change much; what changes is how much of it survives the platform. I will say early if what you want is going to fight the tool you have chosen.
- How is this different from a design agency?
- You work with the person designing it. There is no account manager translating your feedback and no junior doing the work the pitch was won on. The trade is capacity: one person has a ceiling. If you need several designs a week across several brands, an agency is the better answer.
- Do you do the copy as well?
- I write the structure and the working copy, because layout and words are the same decision — you cannot design a page around content that does not exist yet. If you have a writer or a brand voice, I design to it and say where the structure is fighting the words.
- Can you redesign without rebuilding everything?
- Often, yes, and it is usually the better value. Many sites need the homepage, the main service page and the enquiry flow rather than all forty pages. I would rather fix the three that carry the traffic than quote a full rebuild you do not need.
- Do you work with my developer?
- Yes. I hand over a file they can build from and, if you want, review the build against the design before launch. That review is worth more than it sounds: it is where the small differences that add up get caught, while they are still cheap to fix.
- How many revisions do I get?
- Enough to get it right, and the honest answer is that rounds are a symptom rather than a unit. Projects that need six usually did not settle the strategy before the design started. If we agree who the page is for and what it has to do first, the visual revisions are normally small and few.
- Will my site rank better after a redesign?
- Not automatically, and a redesign done carelessly makes it worse. The usual damage is URLs changing without redirects, which throws away whatever ranking history those pages had. This site had to repair exactly that after a migration, so it is not a theoretical risk. Keep the URLs, or redirect every one of them.
Still not sure if this is what you need?
Send it here and it comes straight to me. You will get a straight answer about whether I am the right fit, including when the answer is no.
Have a project in mind? Let's start it.
Whether it's a paid campaign, a website or app, or ongoing design and social support — tell me what you need and I'll get back to you with next steps.