The screen is not the start
Website projects often become visual too early. A homepage appears, a navigation bar settles into place, and stakeholders begin reacting to type, spacing, imagery, and color before the team has agreed what the service is meant to help people accomplish. The work feels tangible, but the most consequential questions remain hidden beneath the screen.
User experience begins before interface design because the interface is only one touchpoint in a wider journey. People arrive with a goal, prior knowledge, uncertainty, constraints, and expectations formed elsewhere. They may move between search, email, a phone call, a physical location, a form, a person, and the website. Designing the visible page before understanding that sequence risks making one moment attractive while leaving the overall task unresolved.
The interface should make a considered journey visible, not conceal an unexamined one.
Start with the whole problem
The GOV.UK Service Standard asks teams to understand users and the problem they are trying to solve, including the context beyond the immediate government interaction. Its guidance recommends user research, quick prototypes, and available evidence to test assumptions early. The principle travels well beyond public services: begin with the outcome a person needs, then examine where the current journey supports or obstructs it.
A website brief should therefore describe recognizable user situations before it describes pages. Who is trying to do what? What triggers the need? What information do they already have? What must they decide, provide, compare, trust, or remember? Where could they be excluded or delayed? A user need framed around the outcome leaves room to find the right response. A requirement framed as a predetermined widget or page often closes that investigation too soon.
Map the journey beyond the website
Journey mapping makes the sequence visible. Digital.gov defines a journey map as a visualization of the major interactions shaping a person's experience of a product or service. GOV.UK's experience-mapping guidance adds that a map can show what users do, think, and feel over time, while exposing interdependencies, pain points, and broken parts of the service. These maps are useful precisely because they include more than screens.
For a commercial website, the map might begin with a recommendation or search, pass through comparison and internal discussion, then continue into an inquiry, qualification, proposal, delivery, support, or return visit. The useful artifact is not the polished diagram. It is the shared account of transitions, questions, evidence, owners, and failure points. When those are visible, the team can decide which moments belong on the website, which require another channel, and where the experience needs coordination rather than another page.
Structure the content before composing the interface
Once the journey is understood, content can be planned around what people need to know or do at each stage. Digital.gov describes information architecture as the intentional organization of website information so people can find what they need. This shifts content planning away from filling a familiar set of templates and toward defining the information, relationships, labels, evidence, and actions that make the journey intelligible.
A practical content model might distinguish services, problems, audiences, proof, process, people, locations, policies, questions, and next steps. It should identify which information is canonical, which content can be reused, which claims need ownership, and how material will change after launch. Navigation and page composition can then express a real structure instead of disguising an improvised collection of copy.
Accessibility should shape the plan
Accessibility is not a treatment applied after the visual design. W3C's page-structure guidance explains that well-structured content supports navigation and processing for people using screen readers, keyboards, magnification, reading modes, and other tools. Its guidance connects meaningful regions, logical headings, and explicit relationships to orientation across a page.
Those outcomes depend on earlier decisions about hierarchy and meaning. If the content has no coherent order, if labels rely on internal language, or if essential tasks are buried inside visual arrangements, semantic markup cannot repair the underlying experience. Planning should include people with varied access needs, devices, attention, literacy, and support contexts while the journey and content are still changeable.
Prototype the riskiest assumptions first
Interface mockups are useful, but they are not the only form of prototype. A team can test a proposed sequence with paper, test labels with a simple content hierarchy, walk through a service scenario, rehearse a handoff between channels, or place unfinished content in a deliberately plain page. The GOV.UK guidance to use quick, throwaway prototypes is valuable because fidelity should follow the question being tested.
If the risk is whether people understand the offer, test the proposition and language. If it is whether they can find the right path, test the structure and labels. If it is whether the business can respond, test the operational handoff. If it is whether a form asks for information people can provide, test the questions and recovery paths. Visual polish is most useful after the team has reduced uncertainty about the experience underneath it.
Earn the interface
A sound pre-interface phase does not need to become a long ceremony. It needs a minimum useful set of decisions: a clear problem statement, prioritized user needs, a journey view, a service or channel map where relevant, a content model, accessibility considerations, operating constraints, success signals, and a list of assumptions to test. The depth should match the risk and complexity of the work.
The interface can then do what it does best. It can create hierarchy, pace, emphasis, recognition, feedback, and emotional tone around an experience that already makes sense. This sequence does not reduce creativity. It gives creativity a real problem to serve. The strongest screen is not the one that arrived first; it is the one that makes a considered journey feel clear, coherent, and possible.
References
- Understand users and their needsGOV.UK Service Manual · Accessed 2026-07-17
- Learning about users and their needsGOV.UK Service Manual · Accessed 2026-07-17
- Creating an experience mapGOV.UK Service Manual · Accessed 2026-07-17
- Map and understand a user's whole problemGOV.UK Service Manual · Accessed 2026-07-17
- Map your users' and system's journeysDigital.gov, U.S. General Services Administration · Accessed 2026-07-17
- Information architectureDigital.gov, U.S. General Services Administration · Accessed 2026-07-17
- Page Structure TutorialWorld Wide Web Consortium (W3C) Web Accessibility Initiative · Accessed 2026-07-17

