User Experience and Accessibility: A Complete Guide

A website visit will usually involve more than one page. Someone might begin with a search result, compare several services, open a document and continue into a separate booking or payment system. They could then return later from an email or complete the final step over the phone.

From the organisation’s point of view, the task may involve various teams, platforms and processes. To the person trying to get what they need, those differences do not matter; it is all one experience. Problems arise when navigation uses internal wording, related information is split across departments or visitors need to know which team owns a service.

Good UX reduces that unnecessary confusion. People should be able to find what they need without first having to understand how the organisation is structured behind the scenes.

User interface design, or UI design, focuses on the pages, controls and visual elements people interact with. UX looks at how those elements work alongside content, accessibility, technology and the complete task.

User research is the process of learning about the people who use a website. It examines what they’re trying to achieve, what they already know and where the current experience causes difficulty.

Organisations may already know more about website use than they realise. Analytics can show where people arrive, which pages they visit and where they leave, while search terms, support enquiries and feedback can reveal unfamiliar wording or recurring questions.

The figures do not explain everything on their own and they still need to be interpreted. Someone may leave a page because they found the answer, while an interview may uncover a problem that only affects a small number of people. The useful part comes from seeing whether the same issue appears elsewhere.

Existing organisational knowledge also matters. Staff understand services, processes, constraints and recurring problems. Research does not replace that expertise. It brings another perspective into the decisions being made.

People’s needs do not always stay the same after a website launches. Services change, new audiences appear and content grows. Devices and the situations in which people use the website change too. Research remains useful after launch because changes to services, audiences and content can alter what people need from the website.

Journey mapping begins by showing what someone currently does to complete a task. It can then highlight where they need information, where they make decisions and where they go in a different direction.

Proposed improvements should be kept separate from what is already known, so teams can see which parts still need testing.

Some tasks need several stages because people need time and information before deciding what to do. For instance, choosing a course or applying for support may involve comparing options, checking requirements and understanding what happens next. A shorter route is not always better if it removes information people need.

Looking at the stages together can show missing information, unclear responsibilities and points where someone is passed between teams or systems without knowing what happens next.

Explore this further

How do websites build confidence?

Read the guide to find out more.

8 minutes read Read the guide

Navigation That Works

More information coming soon

Coming soon

Navigation Design Explained

More information coming soon

Coming soon

Designing for Different User Needs

More information coming soon

Coming soon

Information architecture covers the categories used to group content, the labels applied to them and the relationships between pages.

That planning can be seen through navigation, breadcrumbs, internal links, search, filters and page headings. Navigation is one way of presenting the architecture, but it is not the complete system behind it.

As a website grows, adding another top-level menu item for every new service or campaign may solve an immediate need, but it gradually makes the website harder to navigate. New information should usually fit within a category people already recognise. If it does not, the categories themselves may no longer make sense.

Labels matter as well. Internal service names may be accurate but unfamiliar to visitors. A useful label should use words someone is likely to recognise, while retaining any professional or legal terminology that still needs to be used.

Content design considers what information should appear within that system and when. Someone may need to compare options before starting a task, check what’s needed before completing a form and understand what happens after submitting it.

Planning information in this way also makes future publishing easier. New pages, guidance and services can be added without repeatedly inventing new sections or changing how the whole website works.

People bring habits from other websites with them. They expect links to look like links, menus to open in familiar ways and buttons to describe the action they perform. Forms should explain what needs fixing rather than leaving someone to work it out.

These familiar patterns reduce the amount people need to learn before they can use a website. They do not prevent an organisation from creating something distinctive. Typography, colour, imagery, layout and interaction can all express its identity without making ordinary actions difficult to recognise.

Interface wording should tell people what an action will do. “Check your eligibility” is more useful than “Continue”, while navigation labels should use terms visitors are likely to recognise.

The interface also needs to respond as people use it. Buttons and links should show that they have been activated, forms should identify errors and a completed submission should confirm that the information has been received. When an action is unavailable, the reason should be explained rather than leaving an apparently inactive control.

Mobile layouts need more than a desktop design squeezed into a smaller space. Controls need room to use comfortably, content should remain in a sensible order and navigation must still be easy to follow.

Repeated tasks should behave consistently throughout the website. Controls that perform the same action should look and work the same way, so people do not have to relearn them from one page to the next. Shared layouts also make the interface easier to maintain than a collection of one-off designs.

People use websites in many different ways. Some navigate with a keyboard instead of a mouse. Others use screen readers, voice control, magnification or adapted browser and device settings. People may zoom substantially, increase text size, reduce animation or change colours to suit their needs.

Accessibility problems can appear at any point in a website’s life. An editor might publish vague link text or an inaccessible document. Elsewhere, colour may be carrying information on its own, a control may not work by keyboard or an external booking system may create barriers that the main website does not.

An inaccessible PDF, missing heading structure or poorly labelled image can affect a page even when the underlying website has been built well.

The Web Content Accessibility Guidelines, usually known as WCAG, provide an internationally recognised standard for identifying many common barriers. They give organisations, suppliers and auditors a shared set of testable requirements.

Accessibility is shared work. Content, design and development decisions all affect it, as do later updates and the third-party systems an organisation chooses. Website owners need to make sure it remains part of ongoing website management.

People gain confidence when the website gives them clear signs that it is accurate, up to date and dependable. The information should explain whether a service applies to them, what they need to do and what will happen next.

Any claims made need enough support for the decision someone is trying to make. That can include prices, timescales, policies, qualifications, case studies or named sources. The website does not need to prove everything in the same way, but people should be able to check the information that matters.

Forms often have a strong effect on confidence. People need to know why information is being requested and how it will be used. Errors should explain what needs fixing, while a completed submission should confirm what has happened and when the organisation is likely to respond.

Basic organisational details matter too. Contact information, named teams and important policies should be easy to find and consistent across the website.

Small problems can weaken confidence quickly. A service described differently on several pages, an old date in a document or a button that behaves unexpectedly may make someone question the rest of the experience.

People become more confident when the website behaves consistently and gives them the information they need at each stage.

Task-based usability testing involves asking people to attempt realistic activities using a prototype or live website. The person leading the session observes what happens rather than teaching the intended route.

Completing the task does not necessarily mean it was easy. Someone may have visited several wrong pages before finding the right one or fixed a form error without knowing why it happened. Observing someone as they work through these activities can show where the website made them work harder than it should.

Website features are usually easier to test before they go live. Development teams will often have a separate test environment where navigation, page order, wording and interactions can be reviewed while changes are still straightforward to make.

Once the website is live, testing can include the real content, devices and systems people rely on.

Analytics, form data, feedback and support enquiries can all point towards areas worth investigating. They may show where people arrive, which routes they take and where they leave or run into problems.

Those figures still need interpreting. Leaving a page may mean someone found what they needed, while a heavily visited page may be useful or difficult to understand.

The value comes from using the evidence to decide what should change, then checking whether the change improved the task. That work should continue as the website develops and new content, features or external systems are added.