Skip to main content

UX foundations

User experience (UX) is the quality of a journey lived in a specific context. It includes what a person is trying to accomplish, what they understand, the effort they make, what they feel and the result they obtain.

UX is not “making a page pretty”. An elegant page can fail the task; a plain page can be highly effective. The work is to reduce important obstacles without inventing people’s needs.

The chain to observe​

Separate these levels when analysing an experience:

  1. Intent: what progress is the person trying to make?
  2. Context: where, when, on which device and with which constraints?
  3. Mental model: what do they think the system will do?
  4. Action: which choice or gesture do they make?
  5. Feedback: what changed and how do they interpret it?
  6. Outcome: did they reach the goal, and at what cost?

“Users are lost” is an interpretation. “Four people opened the menu, read the first three categories and went back” is a verifiable starting point.

Need, request and solution​

A person may request a feature because they have already imagined a solution. Reframe it:

Request: “Add a motivation button.”
Need to explore: “I do not know whether I am progressing or what to do next.”
Question: “When and why does the person abandon the session?”
Evidence: “They identify the next step and resume without help.”

Do not turn every assumption into a fictional persona. A persona helps when it groups differences that change a decision: level, context, goal, constraints and observed behaviour. A name and photograph are not evidence.

Lightweight but rigorous research​

A small study can be strong when it reduces a precise uncertainty.

Before​

  • write a research question;
  • choose relevant situations and profiles;
  • decide what will be observed;
  • prepare a neutral script and request consent;
  • do not promise product changes if they are not possible.

During​

  • ask the person to describe a real experience;
  • leave a pause before rephrasing;
  • ask “what would you do now?” rather than “do you understand?”;
  • note actions, hesitation, errors, strategies and vocabulary;
  • separate what was said from what the team infers.

After​

  • group observations by problem and context;
  • preserve counter-examples;
  • write a decision and what would falsify it;
  • collect only data needed for the question.

An interview describes a reported experience. A task test observes behaviour. A metric describes behaviour in a population and period. Combining the angles prevents a signal from becoming a certainty.

Mental models and cognitive load​

People use cues to predict an action and compare the result with expectation. Difficulties often come from a mismatch between the system and the mental model, a missing cue or too many competing elements.

Cognitive load is not all the complexity of a domain. A task may be genuinely difficult while its presentation adds unnecessary effort. Reduce that effort by showing current goal and state, grouping related choices, favouring recognition over recall, revealing detail when it becomes useful and leaving a route for advanced cases.

Decisions and bias​

People use shortcuts. That does not mean they are irrational or that design should manipulate them. Knowing bias helps us test our assumptions and avoid deceptive interfaces.

  • Anchoring: first information influences later comparisons.
  • Confirmation: people find supporting evidence more easily than contrary evidence; actively search for counter-examples.
  • Availability: an easy-to-recall event feels more frequent than it is.
  • Selection bias: volunteers or experts do not represent every situation.
  • Framing: wording changes perception of the same choice; make consequences and alternatives explicit.

The strongest guardrail is the ability to understand, compare, cancel and go back. Hiding an option or making the exit difficult may increase conversion but degrades trust.

Heuristics as a review tool​

A heuristic review is a structured inspection, not a magical verdict. For each issue, record the principle, example, impact and fix to test. Useful principles include visibility of system status, match with the person’s language, control and undo, consistency, error prevention, recognition over recall, flexibility, sober hierarchy, recoverable errors and help at the moment of need.

A heuristic raises a question for study. It does not replace testing with a person or evidence from the domain.

Ethics: facilitate without manipulating​

A healthy experience explains data collection, makes refusal as clear as acceptance, avoids shame and confusion, keeps important actions reversible when possible and respects keyboard, screen reader, zoom, slow connection and older device use. Persuasion can clarify a next step; it should not remove choice or hide a consequence.

Feynman workshop​

Explain to someone who does not know UX why an interface can be easy during a prepared demo and difficult in real life. Use one concrete example, one observation and one way to verify it.

Compare with a strong explanation

A demo shows a prepared path in a calm context. In real life, a person may be interrupted, use another device, not know the team’s vocabulary or encounter an error. Observe a realistic task, record actions and hesitation, then retest a change. “It feels intuitive” is a hypothesis, not a conclusion.

UX research checklist​

  • The question reduces an uncertainty that can change a decision.
  • Research profile and context are justified.
  • Questions are open and not leading.
  • Facts, words and interpretations are separated.
  • Counter-examples are preserved.
  • Collected data is minimised and protected.
  • Every conclusion states its limit and next verification.
  • The solution can be cancelled or compared with an alternative.

Reliable sources​

Move from research to a concrete path with information architecture, then practise in the interactive UI/UX path.