User experience
and interface design
in Westwood

Before a single screen is drawn, a navigation menu already makes a claim about how a product works. Which things belong together, and which sit apart. Getting that claim wrong is expensive, because a visitor who cannot find a section rarely blames the menu. They assume the product does not offer what they need, and they leave to find it somewhere else.

A card sort tests that claim directly. Every page, feature or category the product could contain is written on its own card, physical or digital. A group of people who match the target audience sorts the cards into groups that make sense to them, then names each group in their own words. No designer suggests a structure in advance. The point is to see what groupings people reach for naturally, before any layout influences the answer.

Open sorts, where participants invent their own categories, surface language and groupings a design team would never have guessed. Closed sorts work differently. Categories are fixed, and participants only place cards inside them. That answers a narrower question: does this menu, already drafted, actually make sense to someone seeing it for the first time. Both versions are useful, usually at different stages of the same project.

Tree testing follows once a structure exists. Instead of cards, participants see a stripped-down, text-only version of the proposed menu, and are given a task. Find where you would go to cancel a subscription, or check a shipping policy. No visual design. No styling. Nothing to distract from the structure itself. Where people click first, and where they give up, shows exactly which labels are ambiguous and which categories overlap in the mind of a visitor.

The results rarely confirm the internal logic of the company that built the product. Departments that make sense on an organisation chart, pricing tiers that make sense in a spreadsheet, and feature names that make sense to the team that shipped them, all tend to fail a card sort with real visitors. People organise around the task they came to do. Not around how the business is structured internally.

Running this exercise late in a project, after visual design has already started, wastes the effort already spent on layout and styling for a structure that then has to change. Doing it early costs far less. A handful of paper cards, or a simple online tool, and an afternoon, settle a question that would otherwise be argued about, without evidence, for weeks.

Card sorting and tree testing also give a design team language to defend a decision later, when a stakeholder wants a favourite feature moved to the top of the menu. Instead of arguing preference against preference, the team can point to a specific test, run with real people outside the building, and to the labels those people actually reached for on their own.

None of this needs an expensive lab or a specialist recruiter. Five to eight participants, a stack of index cards or a free online tool, and an hour of moderation are usually enough to see a clear pattern emerge. The exercise repeats cheaply too, whenever a product adds enough new sections that the old menu starts to strain. A menu that made sense at launch rarely still fits two years and forty features later, and nobody inside the company notices the drift until a visitor says so out loud.

A button changes colour for a fraction of a second after it is tapped. A form field flashes red, then settles, when an email address is invalid. A list item slides out rather than vanishing when it is deleted. Small moments. None of them carry much information on their own. Together, though, they decide whether an interface feels alive and trustworthy, or simply broken.

These small animations are usually called micro-interactions. They answer one of three questions for a user, almost always without words: did that work, is something happening right now, or what changed. A page that reloads instantly with no visible signal leaves a visitor wondering whether their click even registered. Nothing moved. Nothing changed. A fair number will click again, sometimes triggering the same action twice.

Good micro-interactions are fast and get out of the way. A confirmation state that lingers a second too long starts to feel like a delay rather than feedback. A spinner shown for an action that actually completes instantly reads as slower than doing nothing at all. Timing decides this, more than the visual style of the animation. It decides whether a user experiences it as helpful, or as friction added on top of the task.

The most useful ones are tied to a real state change, rather than added for decoration. A save icon that briefly becomes a checkmark tells a person their work is safe. A progress bar can fill in proportion to an actual upload, rather than looping without end. That lets someone judge whether to wait or come back later. Purely decorative motion, hovering logos or bouncing icons with no state behind them, tends to read as noise once the novelty wears off.

Consistency across a product matters as much as any single animation. If a confirmation slides in from the top in one part of a product, and fades in from the centre in another, a user has to relearn the pattern on every screen. That costs trust. Documenting a small library of standard transitions, one for success, one for error, one for loading, and reusing them everywhere, keeps the whole interface feeling like a single, coherent system, rather than a set of screens stitched together by different people at different times.

Motion also needs an off switch. Some visitors find animation distracting. Some find it physically uncomfortable, particularly anyone sensitive to movement on a screen. An interface that respects a reduced motion preference set at the operating system level, replacing movement with an instant, static change, is not a lesser version of the design. It is simply a considerate one.

None of this is decoration added at the end of a project. Micro-interactions should sit in the same prototype and the same review as the layout. A screen that looks finished but gives no feedback when tapped will test badly with real people, however clean the static design looked in a file. Small signals matter more than they seem to, at every stage of a review.