UI design concerns the interface people interact with; UX design considers the wider experience of completing a task. Connect the two through 4 activities: research the need, map the flow, prototype the interface and observe people using it. Attractive screens are useful only when they help the intended user understand and complete the task.
A business commissioning UI and UX work should ask what decisions the design will support. A set of polished screens can leave unanswered questions about errors, interrupted journeys or accessibility. Begin with the actual user need and make the important states visible before treating the visual design as settled.
How do UI and UX differ in a practical project?
UI work can include layout, labels, controls, typography and visual feedback. UX work connects those interface decisions to the person’s context, expectations and task. The disciplines overlap: changing a button label can alter both the screen and the user’s understanding of what happens next.
W3C’s accessibility, usability and inclusion explanation describes related goals and important distinctions. In particular, accessibility retains a focus on people with disabilities rather than disappearing into a general claim that the design is easy to use. Evaluate these concerns together while preserving the needs each one identifies.
| Design activity | Question it answers | Useful output |
|---|---|---|
| Research | What is the person trying to accomplish and under which constraints? | Evidence-backed needs and unanswered questions |
| Flow design | Which steps and decisions connect the start to the outcome? | A task flow including exceptions |
| Interface design | How will the person understand and operate each step? | Labels, hierarchy, controls and states |
| Prototyping | Can the proposed interaction be explored before full implementation? | A clearly scoped testable representation |
| Usability testing | What happens when people attempt the task? | Observations tied to a specific version |
| Accessibility review | Which barriers affect people with disabilities? | Relevant checks and corrective work |
The outputs are an original project framework, not a requirement that every team produce a large set of documents. Keep the evidence proportionate to the risk and uncertainty. A short well-observed flow can be more useful than a large collection of screens whose purpose nobody can explain.
How should research shape the interface?
Ask about the task before proposing the screen. What triggers the need? What information does the person have? What would a successful result mean? A business may ask for a dashboard when the underlying problem is that staff cannot identify which request needs their attention.
Distinguish observed evidence from assumptions. A stakeholder’s explanation is valuable, but it should not automatically be presented as a finding about every user. Record who supplied the information, what remains uncertain and how it could be checked. Avoid inventing personas with unsupported statistics to make the research look complete.
Include the people who face relevant barriers. W3C explains why accessibility and usability should be addressed together while retaining attention to disability-related needs. A design tested only with the project team cannot establish that a wider range of people can use it successfully.
Translate the research into a task flow. Identify the starting condition, information required, choices made and final result. Then add the awkward conditions: missing information, an unavailable service, denied permission or a network interruption. The interface needs to explain those states rather than pretending the ideal path is the whole product.
What should a prototype demonstrate?
Choose the prototype’s fidelity according to the question. A rough representation may be enough to examine order and wording. A more detailed interactive prototype may be needed to explore focus, feedback or a complex sequence. Do not confuse visual realism with proof that the underlying integration works.
Label simulated behaviour honestly. If a prototype displays a successful payment, booking or data save without performing it, state that limitation in the test materials. The design can still be evaluated, but it does not prove that the technical workflow has been implemented.
Use this original flow-and-state review sheet:
| State or transition | What the design should explain | Test question |
|---|---|---|
| Entry | Purpose and the next useful action | Can the participant identify where to begin? |
| Input | What information is needed and why | Are labels and instructions understandable? |
| Validation | What is wrong and how to correct it | Can the participant recover without guessing? |
| Waiting | What is happening and whether action is needed | Does the interface create a false success impression? |
| Success | What actually happened and what follows | Can the participant distinguish completion from a request? |
| Interruption | What was retained and how to continue | Is prior work lost without explanation? |
| Alternative route | What to do when the main route is unavailable | Is there a meaningful next step? |
The sheet is an original practical artefact. It helps reviewers inspect a journey rather than giving isolated screens an aesthetic score. Apply it to the main task and the exceptions that matter most to the service.
How should usability testing be run?
The GOV.UK moderated usability-testing guide describes observing participants attempt specific tasks and using their behaviour to identify problems. It is service-design guidance, not a claim that the same research protocol or statutory obligations apply to every business. Adapt the method to the actual research question and participant needs.
Give a neutral task rather than instructions that reveal the answer. If you tell someone which control to select, you are testing whether they can follow your directions rather than whether the interface communicates. Observe where they hesitate, misunderstand a label or take an unexpected route.
Record observations separately from explanations. A participant failing to notice a control is an observation. Saying the colour caused the failure is a hypothesis that may need another test. Keep that distinction so that a design preference does not masquerade as research evidence.
After revisions, identify the version and issue being checked. Do not claim a problem is fixed merely because a screen changed. Test the relevant task again where appropriate, and carry unresolved accessibility or functional questions into implementation rather than hiding them behind a polished presentation.
See web development for related implementation work. To explain a UI and UX requirement, get started with the user task, current flow and evidence of the difficulties people encounter.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.