From Design Foundations
User Experience Fundamentals
What makes an experience easy to use?
Foundation / 10 min
After this reading, you can explain what makes an experience easy to use and check it with evidence rather than opinion.
User experience is larger than an interface. It includes what a person expects before an interaction, what they perceive and do during it, and what they remember afterward. Language, speed, physical setting, customer support, accessibility and recovery from mistakes can shape the experience as much as the appearance of a screen.
UX design therefore begins before a designer chooses components or colors. It asks what people are trying to accomplish, what makes the situation difficult, which assumptions a team is making and what evidence would show that a proposed response actually helps.
Expectation → Encounter → Action → Outcome → Memory ↑ ↑ Product, service and context
Begin with UX research
Imagine noticing a pair of jeans that appears to suit you. You ask the person wearing it about the fit, search for the same product, compare alternatives when your size is unavailable and read reviews about color, comfort, washing, stitching and delivery. Price, star ratings and the number of reviews help you compare options; descriptions and photographs help you understand experiences that numbers cannot explain. When your own pair arrives, wearing and washing it gives you direct evidence.
This everyday investigation resembles UX research: collecting and interpreting evidence about people’s experiences so a decision does not rest on personal preference alone. Primary research gathers evidence directly for the question at hand. Secondary research examines evidence that already exists, such as prior studies, support logs, analytics, reviews or market reports. Neither is automatically stronger; usefulness depends on the decision, the quality of the evidence and how closely it matches the context.
| Dimension | Type | What it can reveal | Examples |
|---|---|---|---|
| Source | Primary | Evidence gathered directly from relevant participants or situations | Interviews, observation, usability tests, surveys, diary studies |
| Source | Secondary | Existing patterns, prior findings and questions worth investigating | Literature, reviews, analytics, support records, competitor studies |
| Evidence | Qualitative | Meaning, motivation, language, sequence and context | Interview accounts, observed workarounds, open responses |
| Evidence | Quantitative | Counts, rates, magnitudes and distributions | Task time, completion rate, errors, ratings, event data |
These categories can overlap. A usability study may record completion rates and task times while also observing hesitation and asking participants to explain what confused them. Combining evidence can show both what is happening and why it may be happening, but the researcher must still account for sampling, bias, consent and the limits of each method.
Context + Behavior + Need ↓ Experience goal ↓ Flow + Content + Interface ↓ Test
Manage cognitive load
Cognitive load describes the mental resources a task demands. A long application form, for example, may already require careful recall and judgment. Unclear instructions, inconsistent controls and preventable errors add effort that does not help the person complete the application. As that burden grows, people may slow down, make mistakes or abandon the task.
| Type | Source of effort | UX example | Design response |
|---|---|---|---|
| Intrinsic | The inherent interaction among elements in the task, relative to a person’s existing knowledge | A first-time investor must understand unfamiliar financial concepts before placing an order | Sequence the task, explain essential concepts and provide appropriate support |
| Extraneous | Presentation or interaction that consumes effort without supporting the goal | A form uses vague labels, scattered fields and inconsistent validation | Clarify language, group related information and remove avoidable steps or distractions |
| Germane | Effort directed toward constructing and refining useful knowledge structures | A guided example helps someone recognize how a budgeting rule works | Use examples, practice, feedback and progressive scaffolding when learning is part of the goal |
The practical goal is not to remove all mental effort. Some tasks are genuinely complex, and learning requires attention. Reduce effort created by the design, support the effort the task necessarily requires and avoid hiding consequential complexity merely to make a screen look simple.
Use behavioral principles as guides
Many ideas taught as ‘laws of UX’ began as findings or patterns in psychology and human–computer interaction. They can help a designer generate and critique options, but they do not predict every person in every context. Treat each principle as a reasoned hypothesis, then test the resulting decision with representative users.
| Principle | What it suggests | Coffee-shop example | Design implication |
|---|---|---|---|
| Hick–Hyman law | Choice response time tends to increase with the information carried by the alternatives | Choosing among twenty unfamiliar drinks takes more comparison than choosing among three familiar ones | Prioritize, group and clarify meaningful choices; do not remove options people need |
| Fitts’s law | Acquiring a target depends on its size and distance under the conditions of movement | A grinder beside the espresso machine is faster to reach than a small control across a cluttered counter | Make important controls sufficiently large and place them near the likely interaction path |
| Jakob’s law | People bring expectations learned from other products | A familiar ordering sequence feels easier to enter than an unexplained reversal | Use established conventions unless a different pattern creates enough value to justify learning it |
| Miller and chunking | Memory and information processing are limited, while recoding can make material more manageable | A grouped recipe is easier to follow than an unstructured stream of ingredients | Organize related content into meaningful groups; do not use seven as a universal menu limit |
| Peak–end pattern | Retrospective evaluations can be influenced strongly by intense moments and endings | A remarkable first sip and a warm farewell may dominate the memory of a visit | Repair painful peaks and design clear endings, while still improving the whole journey |
| Serial-position effect | Recall can vary with an item’s position in a sequence, often favoring early and recent items under particular conditions | The first and last recommendations in a spoken list may be easier to recall | Give important information clear hierarchy and repeat it when necessary; position alone does not guarantee attention |
| Aesthetic–usability effect | People may initially perceive attractive designs as more usable and tolerate minor issues | An inviting ordering app can feel easier before its navigation has been tested | Use visual quality to support confidence and comprehension, never to excuse functional failures |
Chunk by meaning, not by an arbitrary number
Chunking reorganizes separate pieces of information into meaningful units. A phone number separated into familiar groups is easier to handle than one uninterrupted string. An assembly guide divided by stage lets a person focus on the current operation instead of holding the entire process in memory.
- Group information that belongs to the same decision or task.
- Give each group a descriptive heading so its meaning is visible.
- Use progressive disclosure when later detail is unnecessary for the current step.
- Keep critical context visible instead of forcing people to remember it between screens.
- Test the grouping with users; a chunk is helpful only when it matches how they understand the material.
Distinguish UX from usability
Usability concerns whether specified people can achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. UX is broader: it can include expectations, emotions, meaning, trust and the experience across channels and time. A product can support efficient task completion yet create a poor overall experience through misleading terms, inaccessible support or a loss of control.
| Quality | Question | Possible evidence |
|---|---|---|
| Effectiveness | Can people complete the intended goal accurately and completely? | Completion rate, quality of outcome, critical errors |
| Efficiency | What time, effort and resources does successful completion require? | Task time, steps, interaction cost, assistance required |
| Satisfaction | How does use feel to the people involved? | Post-task ratings, interviews, confidence, frustration |
| Learnability | How readily can a new user begin performing important tasks? | Time to first success, onboarding errors, help requests |
| Memorability | Can an occasional user return without learning the product again? | Success after a gap, relearning time, navigation errors |
| Error safety and recovery | Does the design prevent serious mistakes and help people recover? | Error frequency and severity, recovery success, data loss |
| Flexibility and accessibility | Can people with different abilities, preferences and situations achieve the goal? | Keyboard and assistive-technology tests, adaptable presentation, alternate input paths |
No single metric proves usability. Faster is not better when speed increases costly mistakes; satisfaction does not prove accessibility; successful completion by an experienced participant does not prove learnability. Define the users, goals and context before choosing measures.
Apply the fundamentals to a mobile banking transfer
Consider a mobile-banking flow for sending money. Because the action is consequential, the design must balance speed with comprehension, error prevention and recovery. The relevant experience begins before the transfer screen—with trust, account access and confidence about the recipient—and continues through confirmation, notification, records and support.
| Quality | Design response | What to test |
|---|---|---|
| Effectiveness | Show the source account, recipient, amount and timing before authorization | Can participants send the intended amount to the intended recipient? |
| Efficiency | Offer recent or saved recipients while keeping their identity clear | Do repeat transfers require less time without increasing recipient-selection errors? |
| Satisfaction | Use calm language, visible system status and a receipt that explains what happens next | Do people feel informed and in control at each stage? |
| Learnability | Use familiar labels and reveal advanced scheduling only when requested | Can a first-time participant complete a transfer without coaching? |
| Memorability | Keep navigation and terminology consistent across visits | Can an occasional participant repeat the task after a realistic gap? |
| Error recovery | Validate entries, distinguish similar recipients and provide a realistic cancellation or support path | Can people notice, prevent and respond to representative mistakes? |
| Flexibility and accessibility | Support text scaling, screen readers, external keyboards and clear alternatives to gesture-only actions | Can participants using different access methods complete and verify the transfer? |
A designer should not assume that an immediate ‘Undo’ can reverse a financial transaction; what recovery is possible depends on the payment system and its rules. The interface must communicate the real constraint rather than promise control the service cannot provide.
Follow one observation through
Here is how one short investigation might run; it is illustrative, not a study report. The task: five participants send ₹500 to a saved contact named Ravi Kumar, while the list also holds a Ravi K. from an earlier transfer. What you record: two of the five pause on the recipient list and scroll back once, and one chooses the wrong Ravi before correcting it on the review screen.
What you can conclude is narrow. You saw hesitation and one near-error at recipient selection, with five people, on this prototype. You did not see why. One reasonable interpretation is that two similar names with no other detail are hard to tell apart; another is that the list order changed since the last visit. Write both down, and ask participants what they were looking for before choosing between them.
If they say they were checking which Ravi was which, change one thing: show the last four digits of each account and the date of the last transfer beside the name. Then give new participants the same task. If the pauses and wrong picks fall away, the change helped for this task; if they do not, the interpretation was wrong, and the record of what you saw is still there for the next one. Either way, the result separates what was observed, what was inferred and what remains uncertain.
Turn principles into evidence
- Name the user, goal and context instead of evaluating an interface in the abstract.
- Identify the important decision and the assumption behind the proposed design response.
- Use principles such as Fitts’s law or chunking to generate an option, not to declare it correct.
- Choose evidence that fits the question: behavior, outcomes, time, errors, interpretation or reported experience.
- Test with people and conditions relevant to the intended use, including accessibility needs.
- Record what changed because of the evidence and what remains uncertain.
A useful UX decision can be explained as a chain: we observed this behavior in this context, inferred this need, chose this interaction for this reason and will test this outcome. When one link is missing, the decision may be resting on convention or preference. Fundamentals give the chain structure; research keeps it answerable to reality.
Takeaway