Web design

What is user experience

User experience is the whole path a person travels to reach their goal, from the moment they hear your name to the moment they finish or give up. The user interface is only the surface of that path; the experience is the path itself, including every step in it that is unnecessary, unclear or tiring.

  • Lesson 7 of 12
  • Beginner
  • Free, no signup

One person path to placing an order, and where each step breaks

Under each station is the thing that stops the user at that step.

  1. 1

    They search

    Snag: the page that shows up in the results does not answer the question that was typed.

  2. 2

    They land on the page

    Snag: in the first few seconds it is not clear what is even offered here.

  3. 3

    They try to understand

    Snag: the terms, the delivery time and what is not included are written nowhere.

  4. 4

    They decide

    Snag: no price is written and there is no sign that work has been done before.

  5. 5

    They act

    Snag: the form asks for something the user does not have to hand, or says nothing afterwards.

This path belongs to a service business. Yours may have four stations or eight; what matters is that you write your own rather than copying this one.

Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.

How is user experience different from user interface?

User experience is everything a person goes through in order to reach their goal. The user interface is only one part of it: the layer you see and touch. The difference is easiest to see in one example. A shop with beautiful buttons that shows the delivery cost only at the last step has a good interface and a bad experience; the customer came all that way and now feels tricked.

So user experience also covers things that are not on the screen at all: how long it takes for someone to answer a message, where the phone number is written, what happens after an order is placed, even what the confirmation text message says. For a small business, a large part of the experience is not on the website.

One thing that usually gets missed: user experience is not a separate job that only big companies have. Every decision about the order of things, the number of steps or the words on a button is a user experience decision. The question is not whether anyone does this work; it is whether it gets done deliberately or by accident.

User experience and user interface, two jobs stuck together

Neither is more important and there is no choosing between them. Only the place where each works differs.

User experience

  • The whole path, from before the site to after the order
  • How many steps there are and which are unnecessary
  • What the user is told after each action
  • Measured by watching people

User interface

  • The surface that is seen and touched
  • Hierarchy, contrast, spacing and consistency
  • The shape of buttons, forms, menus and error messages
  • A large part of it is measured with numbers

In a small team one person does both jobs and there is nothing wrong with that. The trouble starts when only one column gets done and it gets called design.

Draw the user path, then look for where it snags

On a sheet of paper write out the path of someone who wants to buy something from you or place an order. Start from before they have heard your name and carry on until they are done. Five or six steps come out and that is enough; it does not need to look nice.

Now, next to each step, write what could stop the person there. The answers are usually embarrassing and that is the point: at the landing step you have about three seconds for it to become clear what you even sell. At the deciding step, if the price is not written, some people leave right there and you never learn that they left.

This exercise has two properties no analytics tool has. First, you see the steps that are not on the site; if it takes two days for someone to call back after a request, that is a snag too and it appears on no dashboard. Second, it hands you a list of hypotheses, and a hypothesis is something you can test later.

If you want a reliable place to start, put Jakob Nielsen ten heuristics next to that path. The first one, for instance, says the system should always tell the user what is going on; that single principle removes half the messages asking what happened to my order.

Three methods a small business can actually run

The first is the cheapest because you already have the data: the messages people have sent you. Read the last thirty WhatsApp messages, emails and contact form entries one after another and pull out only the questions. Any question that appears twice means a page did not answer it. This takes an afternoon and usually produces three or four obvious changes.

The second is the words people searched for. If your site has a search box, look at its report; someone searching inside your site is telling you they did not find it. Outside the site the Search Console performance report does the same: after ranking, the queries dimension groups the data by the exact phrase the user typed. The phrases in that list for which you have no page are exactly what people want from you and cannot find.

The third costs more but pays back the most: watch five people. Give them one clear task, something like you want a quote for your website, start here, and then stay quiet. Do not talk, do not guide, just see where they pause. Jakob Nielsen wrote in 2000 that the best results come from testing no more than five users and that you should run as many small tests as you can afford rather than one large one; that article is still the reference for this exercise.

The hardest part of the third method is not technical, it is behavioural. When someone gets stuck, your instinct is to explain. Explaining ruins the test. That pause is precisely the thing you came to see.

Three research methods, cheapest to most expensive

The order is by cost, not by value. Value increases in exactly the reverse order.

  1. The messages you already have

    Read the last thirty and pull out only the questions. Every repeated question means a page did not answer it.

    1

  2. The words people searched

    Your own site search, then the Search Console queries. Every phrase with no page behind it is a gap.

    2

  3. Watch five people

    Give one clear task and stay quiet. Staying quiet is the hardest part of it.

    3

None of the three shows you the people who never reached your site at all. That group is in no data set and is found only by asking the customers you already have.

What your form will never tell you

Any data you get from a form is people answering your options, not their own real question. It sounds obvious written down, and most wrong decisions come from ignoring it.

Take an example from our own site. The contact form here has a required service dropdown with sixteen options, exactly the services we sell. The last option is deliberately this: other, or I do not know and would like advice. That option came out of a user experience decision: if you force someone to classify their problem before they can speak to you, the people who most need to speak stop right there, because they do not know what their problem is called.

Every message from that form stores the chosen option in the database. So the question of which service people come for is a query here, not a guess. But that same data has a complete blind spot: it tells us what people picked from our list, and never what they wanted that was not on the list. Someone looking for a service we do not offer either picks other and disappears into our rows, or does not fill the form at all.

The way to fill that blind spot is not more data, it is a different kind of data: one free text field where people write in their own words, and then actually reading what they wrote. Numbers tell you what happened; only sentences tell you why.

From data to decision: change one thing, not ten

After any research you have a list and a temptation. The temptation is to fix all of it at once and call it a redesign. The problem with a redesign is not that it is hard; it is that afterwards you do not know which change worked and which one broke something that was fine.

So the order is this: from the list, pick the change with the most effect and the least cost. One. Make it. Wait two or three weeks. Then look. If the number of messages asking that question dropped, it worked. If not, go back and try the next one.

Accept one thing that tutorials rarely say: some user experience problems are not website problems. If people keep asking for prices and you have not written any, that is a business decision and not a design decision, and until it is made no layout solves it. Good user experience sometimes means telling someone their problem is somewhere else.

And the next step for you: read your last thirty messages today and pull out the repeated questions. It is the one method in this lesson you can run this evening.

The fast path, with AI

What takes the most time in user experience research is not collecting; it is reading. Thirty scattered messages across WhatsApp, email and the contact form give you a feeling rather than a list until they are sorted. This is exactly where a language model does real work: grouping a pile of raw text into recurring themes. The work is mechanical and a fast cheap model is enough; our current pick is in <a class="text-link" href="/en/ai/">the AI section</a>.

  1. Paste the last thirty messages one after another into a plain text file. Before anything else, strip out names, phone numbers, emails and anything that identifies a customer; this text is about to leave your organisation.
  2. Alongside it put the list of phrases people searched for that you have no page for. The two are read together, because one says what people asked and the other says what they failed to find.
  3. Run the recipe below. The key is asking the model to back every theme with real sentences; that single constraint is what stops it inventing good sounding themes.
  4. Compare the output against the original text. Delete any theme whose supporting sentence you cannot find in the file. This is the one step of the recipe you cannot skip.
  5. Pick one item from what is left and change that one only. Keep the rest of the list; next time you start from there.

Copy-ready recipe

Below are {count} real messages from the customers of a {business type} business, plus a list of phrases searched on the site.

{message text, with names and numbers removed}

Searched phrases:
{list of phrases}

Do the following:
1) Group the questions and complaints into at most six themes and describe each theme in one short sentence.
2) Under each theme, quote two or three sentences verbatim from the text above that show it. If you cannot find a verbatim sentence for a theme, do not write that theme.
3) For each theme, say which page of the site should have answered it.
4) Order the themes by how often they recur, not by how serious they sound.
5) Wherever the data is insufficient, write not enough data.

Produce no statistics, and never present a sentence that is not in the text above as a quote.

Before you trust the output: Two constraints without which this recipe is dangerous. First privacy: a customer message is personal data and, depending on the service, the plan and the settings, it may be used to train the model; strip names and numbers before sending, and read what that service own data usage page says. Second accuracy: if the model does not find a theme it will invent one, and an invented theme sounds extremely reasonable. That is why step four is mandatory; a theme with no real sentence behind it does not exist.

AI in this kind of work

In user experience AI is good at sorting and bad at judging, and that distinction matters here more than in any other topic. Useful: condensing a pile of messages into themes, writing several versions of a button label or an error message so you can test them, and finding places where the wording across the site disagrees with itself. Not useful and dangerous: generating personas and guessing user behaviour. The model has never seen your users, and anything it says about them is a guess that looks like a finding.

Tools that actually help

  • NotebookLM Built for exactly this: you give it files and get answers cited back to those files, which is precisely the every theme needs a real sentence constraint. Google own help says it works in the same regions where the Gemini app works, and Iran is not on the supported-countries list for the Gemini apps.
  • Claude Good at grouping long texts and at writing several versions of a button label. Iran is on neither of Anthropic two supported-countries lists; we read that on Anthropic own page.
  • Gemini Understands Persian messages well and is enough for this kind of grouping. Google own page says the Gemini web app runs in over 230 countries and territories, and Iran is not on that list.

Where it backfires

Two risks, and both are specific to this topic. First privacy, because user experience data is made of what people said: customer messages, phone numbers, sometimes order details. Where those texts go after you send them and whether they are used to train the model depends on the service, the plan and the settings, and the real answer is written only on that service own data usage page. The right move is simple: strip anything that identifies a person before sending.
Second hallucination, which takes a particular shape here. Ask a model to describe your users and it will, confidently and in detail, without having met one of them. Anthropic own guidance says models sometimes make things up when they do not know an answer, and its advice is to make the model ground its answer in reference documents. That is our position: ask the model to sort your texts and to prove every claim with a sentence from those texts; never ask it what your users think. For how each tool can be paid for from Iran, see the buying guide.

Sources: Anthropic: reduce hallucinations Anthropic: supported countries Google: where Gemini Apps are available

Where this advice stops

All three methods in this lesson show you only the people who reached you. Those who saw your name and did not click, or came in and left within three seconds, are in none of this data and are always the largest group. Second, watching five people finds problems but does not prove which solution is better; for that you need traffic that most small sites do not have, which makes A/B testing meaningless for them. Third, some of what this research turns up is not a design problem at all; a missing price or a slow reply is a business decision and no layout solves it.

From our own work

The reviewable example is this site, and you can open it yourself. The rgb.ir contact form has a required service dropdown with sixteen options, the services we actually sell, and its last option is deliberately other, or I do not know and would like advice. That option is a user experience decision, not a spare line: someone who does not yet know whether their problem is called SEO or speed or hosting has to guess or abandon the form without it, and they are precisely the person who most needs the conversation. Every message from that form stores the chosen option as its own field, so which service people come for is a query here, not a guess. And the honesty it needs: that same data only says what people picked from our list, and never what they wanted that was not on it. Which is why the free text field on that form is, to us, worth more than the dropdown, even though it is harder to analyse.

Real follow-up questions

How many people do I need for user experience research?

To find problems, five. Jakob Nielsen wrote exactly that in 2000, and his advice was to run several small tests rather than one large one. To prove which solution is better the number is completely different and you need traffic.

How do I start with no budget?

With what you already have: the last thirty customer messages. Read them and pull out the repeated questions. It takes an afternoon, costs nothing, and usually produces three or four obvious changes.

Is Google Analytics enough for user experience?

No, but it does the other half of the job. Numbers say where people left the page and never say why. For the why you have to read what people wrote or watch them; the two complete each other.

Keep learning