User experience

User experience is what actually happens to somebody while they use your website: whether they found the thing, understood it, and got to the end without being irritated. It is a result, not a deliverable, which is the reason it cannot be added as a layer once the site is otherwise finished.

In short

• The result of using something, not the look of it.
• Set mostly by structure and wording, before any design is drawn.
• Parts of it are measurable, and the important parts are observable.
• Watching five people try one task finds more than any opinion does.

Words you will hear

• UI. The interface itself, the screens and controls.
• Usability. The measurable slice: can somebody complete the task.
• User flow. The sequence of steps between arriving and finishing.
• Friction. Anything that makes a step harder than it needs to be.
• Accessibility. Whether the site works for people using it differently, including with a screen reader or a keyboard alone.
• Heuristic review. An expert walking the site against a checklist, which is cheaper than testing and finds different things.

Experience is the result, not the artefact

The word gets used as though it described a document. It does not. Nobody hands over a user experience, in the way somebody hands over a logo or a wireframe.

What gets handed over are decisions, and the decisions that set the experience are made early. What pages exist. What they are called. What a visitor is meant to do on each one. How many steps sit between wanting to buy and having bought. The choices about typefaces and colours arrive later and adjust the experience at the margins, mostly by settling what gets noticed first. The structure decided them, and structure is the subject of information architecture.

This is why a redesign that only changes appearance so often leaves the numbers where they were. The visible thing changed and none of the decisions did.

The parts you can measure

Some of it produces numbers, and those numbers are worth having even though they describe only a fraction of it.

Task completion is the honest one: of the people who set out to do the thing, how many finished. Alongside it, the number of steps required, the proportion who abandon a form and the field they abandon it on, and the loading and stability measurements collected as Core Web Vitals. On a phone, on a connection that is not the office connection, those loading measurements stop being an abstraction quickly.

What the numbers will not tell you is why. A form abandoned at the address field might be asking for something people do not want to give, or it might simply be broken on one browser. Only watching somebody hit it settles which.

Where small businesses lose people

The failures repeat, and they are rarely the ones people expect.

• The site does not say what the business does. Visible within seconds or not at all, and no visual work compensates for its absence.
• The next step is unclear. Several equally weighted options, none of them obviously the main one.
• The phone version was an afterthought. Most Philippine traffic is on a phone, so the phone version is the site.
• Contact details are hidden. Buried on a separate page, when the reason somebody is still reading is that they want to ask something.
• Forms ask for more than they need. Every extra field costs completions, and most of the fields exist because somebody thought the data might be useful one day.

How to test it without a lab

Ask five people who match your customers to do one specific thing on your site. Find the opening hours. Order the small size. Get a quote for a job like theirs.

Then say nothing and watch. The instinct to help is strong and it destroys the test, because the moment you explain the interface you are no longer measuring whether the interface explains itself. Note every hesitation and every wrong turn. The list you end up with will be short, will be embarrassing, and will be more useful than any meeting about the design.