The starting point
Designing an experience means understanding what a person is trying to do and what information they need to decide. Interviews, observation and task analysis distinguish a navigation problem from a problem in the underlying service. If a form requests information the user cannot know or never explains why it is needed, changing a button colour will not remove the friction. We therefore work on journeys, content and interface decisions together, looking at both the people using a product and the people maintaining it.
The visual system establishes hierarchy and states before screens multiply. Typography, contrast, spacing and components are tested with real content, long text and mobile layouts. An ideal state is only one part of the experience: there are incomplete fields, empty searches, failed validation and waiting periods. Each needs understandable guidance. Accessible components must work with keyboards and assistive technology, while interface language must help complete a task without relying on internal organisational terms.
Prototypes let teams test decisions before investing in a full build. We check whether a feature can be found, a warning understood and a process completed without assistance. Observations are recorded by task and severity so aesthetic preferences can be separated from actual obstacles. After prototyping, components move into a documented library with usage examples and constraints. This prevents each new screen from inventing a different form, set of icons or way of explaining an error.
Design work continues after publication. Completion measures, support requests and user feedback reveal where the product still demands unnecessary effort. We review those findings with engineering and editorial teams to keep the promise of an interface aligned with what actually happens. A coherent experience also depends on loading time, confirmation messages, clear permissions and a visible path out when something goes wrong. Those small moments shape whether a person returns to the service or gives up and contacts support, so they deserve the same attention as the opening screen.
Tools and method
- User research and a map of priority tasks.
- Information architecture and navigable prototypes.
- Design system with documented components and states.
- Contrast, keyboard and assistive technology checks.
- Content library and interface language guidance.
- Task completion measurement and post-launch review.
Use cases
- Service redesign with clear steps and messages.
- Component library shared across organisational products.
- Navigation improvements for a content-rich portal.
- Mobile accessibility and form error audit.
Frequently asked questions
Can this work without a complete rebrand?
Yes. Hierarchy and components can evolve within an existing identity.
When do users test the design?
During early prototypes and again when a working version is available.
What does a design system include?
Components, states, content rules, examples and accessibility guidance.
Does the design cover mobile?
Journeys are tested with real viewport sizes, content and interaction methods.
How are changes prioritised?
By task impact, problem frequency and implementation effort.