Web Design
UI/UX design centered on your users
Good UI/UX design means a visitor knows where they are, what you offer and what to do next within seconds. We design interfaces from user research and real flows, not from what looks clever in a portfolio.
Who it is for: Businesses whose site or product looks fine but confuses visitors, loses them mid-task, or fails to turn interest into action.
Everything in this service
- User research and audience review
- Information architecture and page hierarchy
- User flow mapping for key journeys
- High-fidelity interface design for mobile and desktop
- Accessibility review against WCAG
- Developer-ready handoff files
What to expect
- Visitors who find what they need without thinking
- Key journeys completed more often
- A design your developers can build without guesswork
How ui/ux design actually works
Research before pixels: what we actually need to know
Research is not a survey and a persona document nobody reads. It is a short list of answers that change what you draw. Who arrives on this screen, what were they doing five minutes before, what do they already believe, and what is the one thing they came to do.
Most of that comes from sources you already have. Sales calls tell you the objections. Support tickets tell you where people get stuck. Search queries tell you the words users pick, which are almost never the words the business uses internally. Analytics tells you where journeys end early. Six recorded sessions of real people using the current site will teach you more than a month of internal debate, because you watch the hesitation rather than hear a reported opinion.
The output should fit on one page. A handful of user goals in priority order, the words users use, the top three friction points, and any constraint that limits the design. If a research finding does not change a layout, a label or a flow, it was interesting rather than useful.
- Read support tickets and sales objections before drawing anything
- Collect the words users actually type, then use those words as labels
- Watch a few real sessions rather than commissioning a large survey
- Write goals in priority order, because a design cannot serve five equal priorities
- Discard findings that do not change a layout, a label or a flow
Information architecture: the invisible part users feel first
Information architecture is how content is grouped, named and ordered. It is invisible when it works and infuriating when it does not. A site with beautiful pages and bad structure feels harder to use than a plain site with clear structure, because users spend their attention searching instead of reading.
Two failures dominate. The first is grouping by internal team structure rather than by user task, so a visitor has to know how the company is organised to find anything. The second is naming things in company language. A menu item called Solutions tells a visitor nothing. A menu item that names the actual service tells them everything, and it doubles as the phrase they searched for.
A card sort, even an informal one with five people, resolves most grouping arguments quickly. Give people the content items and let them cluster and name the piles. Where several people group the same way, you have your structure. Where they scatter, you have found the content that needs a clearer label or a different home. Depth matters too. Every extra level of hierarchy is another decision the user has to get right, so flatter structures with honest labels beat deep taxonomies almost every time.
- Group by what users are trying to do, not by internal departments
- Label in plain user language, never in internal shorthand
- Run a small card sort to settle grouping arguments with evidence
- Keep hierarchy shallow, each level adds a decision the user can get wrong
- Make sure every important page is reachable in two or three clicks
Visual hierarchy and how people actually scan a screen
People do not read interfaces, they scan them and stop when something matches what they want. Visual hierarchy is the tool that decides what they notice first, second and third. If everything is emphasised, nothing is, and the visitor has to read the whole page to work out what matters.
Hierarchy comes from size, weight, colour, contrast and space, in roughly that order of strength. The most reliable of these is space. Grouping related items close together and pushing unrelated items apart tells the eye what belongs with what before a single word is read. Contrast is the second lever. One strong accent colour reserved for the primary action works because it is rare. The moment a page has four buttons in the same accent colour, the accent stops meaning anything.
A practical test: squint at the screen or blur the mock-up until text is unreadable. What still stands out is what a visitor will see in the first second. If the blurred page shows a heading, one image and one button, the hierarchy is doing its job. If it shows an even grey field of similar blocks, the page will be read slowly or not at all.
- One primary action per screen, styled differently from everything else
- Use space to group, it is stronger and quieter than lines and boxes
- Keep heading levels meaningful, they guide both eyes and screen readers
- Blur the design and check what survives, that is what users see first
- Left-aligned body text at a comfortable line length beats centred paragraphs
The states designers forget: empty, loading, error and success
Most design files show the happy path with perfect content. Real products spend a lot of time in other states, and those states are where users decide whether the product is trustworthy. A dashboard with no data yet, a list that is still loading, a form that was rejected, a payment that went through. Each of these needs a design, and each is usually invented by a developer under time pressure if the designer skipped it.
The empty state is the most valuable and the most neglected. A new user sees it first, so it should explain what will appear here and offer the single action that fills it. Loading states should reserve the space the content will occupy, otherwise the layout jumps when content arrives, which is both irritating and a measurable performance problem. Error states should say what went wrong in plain words, say what to do next, and keep whatever the user already typed. An error that clears a filled form is worse than no error at all.
Write the content for these states rather than leaving lorem text. The words are the design here. A message reading Something went wrong is a placeholder pretending to be a feature.
- Design the empty state first, it is what new users meet on day one
- Reserve layout space while loading so nothing shifts when data arrives
- Errors: what happened, what to do, and never discard what was typed
- Show confirmation after a successful action, silence reads as failure
- Include the long-content case, real names and titles break tidy layouts
Accessibility is a design decision, not a development task
Most accessibility failures are decided in the design file and only discovered in the build. Colour contrast, text size, touch target size, focus order, whether meaning is carried by colour alone, whether form fields have visible labels. A developer can implement a design faithfully and still ship an inaccessible page, because the problems were baked in before the code existed.
The checks are quick at design stage and expensive later. Contrast can be tested in the design tool. Touch targets can be measured against a minimum comfortable size. Placeholder text used instead of a label disappears the moment someone types, which fails both accessibility and ordinary usability, and it is a design choice rather than a coding one. Focus order follows the order elements appear in the markup, so a design that visually reorders content creates a keyboard journey that jumps around the screen.
The practical benefit runs wider than compliance. Larger touch targets help everyone on a moving train. Strong contrast helps everyone in sunlight. Clear labels help everyone in a hurry. Designing for the hardest case tends to produce a calmer interface for the ordinary case.
- Check text and interface contrast in the design tool before handoff
- Never carry meaning with colour alone, add a label, icon or pattern
- Use visible labels on form fields, not placeholder text
- Keep touch targets generous, thumbs are less precise than a mouse pointer
- Design a visible focus style, do not let the developer remove the default
Usability testing without a lab or a large budget
Usability testing has a reputation for being expensive, which stops small teams doing it at all. It does not need to be. Five people attempting a real task on a clickable prototype will surface the majority of serious problems, and you can run that in an afternoon over a screen share.
The method matters more than the sample size. Give a task, not a tour. Ask someone to find the pricing for a specific situation and book a call, then stay quiet. The instinct to help is what ruins most sessions. When a participant hesitates, that hesitation is the finding. Ask what they expected to happen rather than whether they liked it, because opinions about appearance are cheap and behaviour is not.
Record what people do, group the problems by how many people hit them and how badly it blocked the task, then fix the top few and test again. Testing early on a rough prototype is far more useful than testing late on a finished build, because at prototype stage a fix costs an afternoon rather than a sprint.
- Five participants per round finds most of the serious issues
- Give a realistic task, then resist the urge to guide
- Treat hesitation and backtracking as data, not as user error
- Ask what they expected, not whether they liked the look
- Test the rough prototype, when changes are still cheap
A clear path, step by step
- 01
Research
We learn who your users are, what they came to do, and where the current design loses them.
- 02
Structure
Information architecture and user flows first, so the design solves the right problem.
- 03
Design
High-fidelity screens for mobile and desktop, reviewed against the flows we agreed.
- 04
Hand off and refine
Developer-ready files, then refinements once real users interact with the build.
Why choose us for this
We design from user behaviour, not taste
Accessibility checked at design stage, not patched later
Design and development under one roof, so nothing is lost in handoff
Common questions
What is the difference between UI and UX design?
UX is how the whole journey works: structure, flows, what happens when someone clicks. UI is how each screen looks: layout, type, colour, spacing. We do both together because one without the other fails.
Do you test designs with real users?
Where budget allows, yes, and it is worth it. At minimum we validate flows with clickable prototypes before development, which catches most problems at the cheapest point to fix them.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase