ux

name

ux

description

Improve any product or service from the user's point of view. Follow every touch before, during, and after use; check the result, words, visual form, sound, touch, motion, waiting, response, physical setting, people, trust, and later effects; and remove parts that do not help. Use when making, changing, reviewing, or fixing any user-facing product, feature, flow, screen, API, message, animation, loading state, notification, help, payment, support path, or way to leave, and when checking ease, access, emotion, safety, privacy, speed, or reliability.

UX

Start with the whole human experience

Treat UX as everything a person can notice, act on, wait for, pay or give up, depend on, or live with because of a product or service. Include what happens before, during, and after use. Do not reduce UX to one screen or to ease of use.

A user is any person who uses or gets the result, gives help, or has to live with its effects. Give more care to people who have less power, less knowledge, limited access, disabilities, or more risk of harm.

Ask:

• Who needs to get what done, in what place and state?
• What do they think will happen? What must be true at the end?
• What reaches their senses, body, mind, money, time, work, or relations with other people?
• What work, doubt, wait, risk, cost, or loss do they take on?
• Who else gets more work, cost, risk, or harm?
• What facts show this? What is only a guess?

Keep these apart: what you saw, what users said, what measures show, what you think, and what you only guess. Do not make up user research or use a made-up user as proof. When facts are missing, make the smallest safe guess. Test it with a step that is easy to undo. Say what will show that the guess is wrong.

Imagine you are the user

Do not only look at the user from outside. For a moment, imagine that you are the user.

Forget what you know about how the product works. Move through the whole experience in your mind. Use I, not the user, and ask:

• What am I trying to do, and what else is happening around me?
• What do I see, hear, smell, taste, or feel through touch, heat, weight, or motion? What do I think it means?
• What changes, moves, appears, goes away, or makes me wait?
• What must I notice, remember, decide, move, type, say, pay, or trust?
• What feels easy, hard, calm, pleasant, tiring, unclear, slow, unsafe, or wrong?
• Can I get the result, keep my work, and get back when something fails?

Let the experience feel real. Then step back and improve what got in the way. Imagination helps you see, but it is not proof of what every real person will sense, think, or feel. Check important doubts with real users or direct facts.

Include everything that can reach the user

At every point of contact, hold three views together:

• What reaches me: the promise, price, words, data, visual form, light, sound, speech, touch, vibration, motion, heat, weight, smell, taste, space, physical thing, system state, staff action, rule, and brand.
• What I must do: find, notice, understand, remember, choose, move, reach, speak, enter, wait, change place or device, ask for help, recover, or leave.
• What happens to me: the result, time, effort, comfort, pain, emotion, confidence, control, cost, privacy, safety, place among other people, memory, and later effect.

Follow each view through time. Check the first sign, start, change, wait, end, and after-effect. Check what is missing too: silence, a blank screen, no feedback, a hidden state, a delay, a dead end, or no way out.

Do not treat the examples as a closed list. Ask three simple questions: Can I notice it? Must I deal with it? Can it affect me? If any answer is yes, include it in the experience.

Inspect the live experience

A file, code review, or screenshot can show only part of an experience. Inspect each important part in the form and time in which the user gets it.

• Run the path from its first visible or heard sign to its settled end. Watch loading, progress, changes of state, transitions, animation, flashing, scrolling, media, sound, vibration, and work that ends in the background.
• Check the full action and response: input, focus, feedback, delay, success, failure, stop, undo, retry, return, and effects on later work.
• Use fitting devices, screen sizes, input tools, assistive tools, network and processor speeds, text sizes, motion settings, languages, light, noise, privacy, and places. Use only the cases the real need and risk call for.
• Make motion explain change or give useful feedback. Remove motion with no work. Avoid flashing or motion that can harm people. Let people reduce or stop motion when it may distract, tire, or harm them.
• Make waiting clear and honest. Show useful content or state soon, show known progress, keep work safe, let people do something else when possible, and say when long work ends. Do not make a person stare at a spinner with no useful fact.
• Give sound and touch a clear cause and meaning. Match them with visual or text feedback, respect device and user settings, and avoid surprise or repeated noise and vibration.

When you cannot see, hear, feel, run, or measure a part, do not leave it out and do not call it good. Mark it as not checked. Use a real device, a recording, a trace, direct observation, or a report from a person who can experience it.

A measure can show time, change, or failure. It cannot by itself show comfort, delight, fear, dignity, trust, or whether motion feels sickening. Let real people judge these felt effects. Include people and settings that match the decision and its risk.

Keep only what helps

Make the whole experience as simple as possible while it still gives the needed result, clear meaning, user control, and safety.

Every word, button, choice, field, step, message, movement, sound, vibration, and decoration must help the user understand, choose, act, know what is happening, or get back from a problem. If taking it out keeps those things true, take it out. Show what matters now. Show more only when it becomes useful. Prefer one clear path and familiar words and patterns.

Do not make one screen look simple by hiding needed facts or moving work, doubt, or risk to a later screen or another person. Let the product carry complexity that the user does not need to manage.

See the whole journey

Map the shortest full journey that can guide the decision. Include the stages that matter:

1. The need, the event that starts it, the promise, and the place and time
2. Hear about it, find it, understand it, compare it, and choose
3. Buy or get access, receive or unpack it, agree, set up, and get the first good result
4. Do the main work, wait, come back, share, or hand work over
5. Get a change, warning, interruption, error, loss of service, or failure, and get back to work
6. Get help, deal with a person, make a complaint, and put trust back
7. Change, renew, move data, cancel, return, delete, dispose of, and leave
8. Live with later effects on the user and other people

At each important stage, show:

• What the user wants, expects, and can notice
• What the user does, where they are, and what conditions they face
• What facts and system state the user can see, hear, or otherwise know
• What changes over time and where work or control goes next
• What work, cost, body load, mind load, and feeling the user takes on
• What may go wrong and how the user gets back
• What proof you have and who owns the stage

Put the product, package, place, website, app, email, message, call, help page, bill, payment, support, staff work, and offline step into one journey when the user meets them. Do not make one step look easier by moving work, doubt, or risk to a later step, another place, another user, or support staff.

Judge the effect on the user

At each important stage, check the effects that can change the user's result:

• Real result and value: Help the user get the result they need at a fair cost in time, money, data, attention, and energy.
• Easy to find and understand: Make the next useful thing clear in words, order, shape, and place. Fit the way the user thinks about the work.
• Easy to act on: Give a direct path with no needless work for the body, mind, or feelings. Make targets, input, and gestures fit the person and device.
• Open to different people: Support needed bodies, senses, languages, devices, places, skills, and ways of access. Do not make one made-up user the rule for all people.
• Comfortable and fitting: Avoid needless strain, pain, sickness, stress, shame, noise, glare, or overload. Make the look, voice, motion, and feeling fit the need; serious work may need calm more than delight.
• Clear in time: Give prompt, steady feedback. Make waits, progress, motion, interruption, timeout, old information, and work in the background fit the user's need.
• Under user control: Show what is happening and what will happen. Let the user choose, stop, undo, correct, and get back from a problem.
• Joined and known: Keep meaning, state, work, and identity clear across time, devices, places, people, channels, versions, and handoffs.
• Honest, private, safe, and fair: Make it clear who is acting, why, at what price, and with what agreement. Protect the user and other people from hidden use, tricks, unfair treatment, and avoidable harm.
• Supported through the end: Make help easy to find and able to put problems right. Make change, return, cancel, export, delete, and leaving as clear as joining.
• A promise that can be kept: Make sure the product, business, service team, law, and system can keep the promise made to users.

Business numbers and system limits are real inputs, but they are not user results. Make any conflict clear. Do not use tricks, hidden results, hard-to-stop service, or false choices to make a number look better.

Work from facts to a full result

1. Name the user groups, situation, old experience, wanted result, important limits, and one full case that must work. Add people who do not use the product but may get its effects.
2. Look at the real experience. Watch and talk with users in the settings, devices, papers, and usual distractions that matter. Run the live path. Check its words, pictures, motion, sound, touch, timing, system state, physical setting, and staff work. Read use measures, search and help records, complaints, access tests, failures, rules, and staff reports. Say where facts are weak or do not agree.
3. Map the whole journey and every user-reachable part that matters. Find breaks in what users expect, sense, understand, control, or trust. Follow each break through time, words, controls, rules, work steps, data, code, and service work to its cause.
4. Imagine that you are the user. Walk through the main path, wait, failure, help, and leaving. Add other cases only when the task, facts, or risk make them important.
5. Put user harm and blocked results first. Then weigh hard-to-undo actions, trust, body and mind load, how many users meet the problem, how often and how long it happens, how easy it is to put right, how strong the facts are, and the cost and risk of change. Do not hide the choice behind one score.
6. Make the smallest full change to the affected journey. Take out parts with no clear work before adding new ones. Change every needed part: product action, physical form, screen, words, motion, feedback, wait, default, rule, help, service work, or system. Keep users safe while the new way goes into use.
7. Check the full live journey with users from the needed groups, or with the best stand-in you have. Check the main path, wait, failure, return, help, and exit as different tests. If a change was requested, make it in every needed part and prove it; do not stop at advice.

Check the result

Choose checks that can show your answer is wrong. Use only the checks that the risk needs:

• Direct proof that people can notice, understand, choose, act, wait, get back from problems, and get the wanted result
• Human reports and observation for comfort, effort, emotion, trust, dignity, motion, sound, touch, and fit with the real place
• Measures such as success, time, response, visual stability, errors, leaving, coming back, asking for help, and getting back to work
• Checks with fitting devices, settings, input and assistive tools, connection states, and user conditions
• Service checks for whether the service is up, handoffs, support results, and extra work for staff
• Guard checks for harm, people left out, privacy, safety, fairness, complaints, undoing actions, and effects on other people

Compare with the old result when you can. Look at user groups one by one when one total may hide harm. Numbers are signs with limits; they are not the experience itself. For choices that may do great harm or are hard to undo, get stronger proof from real users and make every doubt clear.

Give a clear report

Start with the user result and the most important break in the experience. Then give:

• The users, situation, facts, and important unknowns
• The full journey, the parts the user can meet, and the main breaks
• What was checked live, what was measured, what people reported, and what was not checked
• The changes, owners, costs and gains, and parts left as they are
• The full case, checks, results, safety limits, and risks that remain

Do not give a long, general checklist. Finish when the user can get the result through the full important journey; the important seen, heard, touched, timed, physical, and human parts work together; failure and exit are safe and clear; high-risk parts have proof; and all choices that remain are clear.

Use point for one local cause. Use line to keep one UX rule true in one domain. Use plane to carry a result people can see through system boundaries. Use UX to keep the full human experience in view, inside and outside the system.

Use $cluster when the experience spans independent journeys or owners; keep the complete human result and final acceptance in the root plane, with domain work in line and local findings in point.