Web experiences
A web experience is the whole way a person meets your work online: the story the page tells, how it behaves on a phone, how fast it arrives, and what happens when they try to do the thing they came for. I design and build websites that keep that promise from end to end.
- Scope
- Structure, words, design, build
- Built with
- Semantic HTML, CSS, and light JavaScript
- Checked for
- Speed, accessibility, search basics
- Delivered as
- A site you own, on hosting you control
The short version
A good site explains itself.
Someone should be able to land on the site, understand what it is for within a few seconds, and take the next step without being told how. That sounds obvious. It is also the part most sites get wrong, usually because decisions were made one page at a time instead of for the whole experience.
The work here is about the seams: the story across the pages, the navigation between them, the weight of the images, the behaviour on a slow connection, the text a screen reader reads out, and the button that finally asks the visitor to do something.
Five things I care about
These are the tests I apply to every site, whether it is one page or twenty.
A story that leads
Pages are written in a deliberate order, each one answering the question raised by the last. A visitor should never have to guess what the site is about, and the words should sound like the organisation rather than like a template.
Navigation that behaves
Menus, links, and calls to action say what they do. The structure stays shallow enough to hold in the head, and every page answers the question of what to do next. On a phone, the same logic applies with fewer elements, not a different site.
Speed that respects people
Images are sized for the screen they appear on, fonts are served locally, and scripts are kept to what the page actually needs. Performance work is not a separate phase; a page that is quick to load is a page that respects someone's time and battery.
Markup that includes everyone
Semantic HTML, logical heading order, visible focus states, sufficient contrast, and full keyboard support come as part of the build. This helps people who use assistive technology, people on older devices, and search engines that read pages the way a screen reader does.
A next step you can see
Every page has a clear action, and the action matches the intent of the visitor who arrived there. A contact page for someone who is ready to talk, a pricing page for someone comparing options, and a guide for someone still learning are three different endings, not one.
What the work includes
Strategy
- What the site is for and who it serves
- Page structure and content outline
- What to say, and what to leave out
Design
- Layout, type, colour, and imagery
- Interactive states and small details
- Responsive behaviour for real screens
Build
- Hand-written HTML, CSS, and JavaScript
- Content management if the site needs it
- Deployment, hosting, and domain setup
After launch
- Analytics that respect privacy
- Search basics: titles, descriptions, structure
- Handover notes and a walkthrough
Where it fits
A good fit
- A business that needs to explain what it does more clearly
- A team whose current site no longer reflects the work
- A product or service that people have trouble understanding
- A site that needs to load faster or work better on a phone
Not the right shape
- A campaign that needs advertising creative rather than a site
- Work that is mostly offline and needs a brochure, not a platform
- A build that depends on features no one has asked for yet
- A site that will be replaced within a matter of weeks
What I need from you
Honest answers to a few questions are enough to get going:
- What the site is for, and what a good outcome looks like
- Who uses it, and what they are trying to do when they arrive
- What content exists today, and what you already know about the audience
- Any constraints that are real: budget, deadline, technology, approvals
You do not need a brief, a wireframe, or a list of features. Those are outputs of the work, not inputs to it.
Questions about web experiences
Do you design and build, or only one of them?
Both. Working on the whole experience means the structure, the words, the look, and the behaviour are designed together instead of negotiated between separate specialists.
What platforms do you build on?
Static sites where they fit, and a content-managed build where the site genuinely needs one. The choice follows from how the site will be maintained, not from a preference for a tool.
Will my site be accessible and fast enough?
Accessibility and speed are part of the build rather than an extra phase. Semantic markup, keyboard support, contrast, and image weight are handled while the site is being made, and checked before launch.
Can you work on a site that already exists?
Yes. Sometimes the right work is a focused improvement to a small number of pages rather than a rebuild, and sometimes it is a rebuild. The starting point is understanding what the current site is doing well and where it gets in the way.
Related work
If the site is only half of the problem, these are usually the other halves: search and growth for being found, dashboards and tools for the internal side, and connected systems for the repetitive work behind it.
Have a site in mind?
Tell me what it needs to do, and what it is doing now. That is enough to start a useful conversation.