Judge the task, not the appearance
A page can look polished while making an ordinary task difficult. Perhaps customers cannot find delivery information, recognise an error or tell whether their request was sent. Visual appeal may help, but it does not establish usability. Start by identifying the tasks that make the service useful and the people who need to complete them.
Context matters. A booking form used calmly on a large screen differs from one used on a phone while travelling. An experienced employee may understand abbreviations that a new colleague cannot interpret. Describe these conditions before deciding whether a design is clear or efficient.
Look at success, effort and confidence
Ask whether the person reaches the correct result, what work it takes and how they experience the process. Speed alone is not enough. Someone may finish quickly by overlooking an important choice, while another person may take longer because the task reasonably requires careful thought. The desired balance depends on the activity.
Include recovery. People mistype, change their minds and get interrupted. A usable service helps them understand the current state and continue appropriately. Clear error messages and preserved information can matter more than removing one click from a successful path that rarely represents the full reality of use.
An illustrative supplier ordering example
Imagine a fictional café ordering supplies through a wholesaler’s website. A staff member needs to reorder the same ingredients but adjust one quantity. The page uses internal product codes as its main labels, and the final button does not explain whether it saves a draft or places the order. The screen looks tidy, yet the task remains uncertain.
The wholesaler makes product names easier to recognise and labels the final action clearly. A review step shows quantities and the intended outcome. These changes address specific observed difficulties. They are not evidence of a guaranteed sales increase, and the company still needs to examine how the revised process works for its intended users.
Distinguish usability from the wider experience
User experience includes a broader set of perceptions before, during and after use. Customers may complete an order easily but later feel disappointed by unclear delivery updates. Usability is a crucial part of that experience, focused on using the service to achieve a goal. It does not describe every aspect of the relationship.
Accessibility is closely related and asks whether people with different abilities can use the service. A convenient design for one group may still exclude another. Consider keyboard use, readable content and assistive technologies where relevant. A short usability session cannot certify complete accessibility, so do not treat one kind of check as a substitute for all others.
Observe believable tasks with relevant people
Ask participants to pursue a realistic goal without telling them the interface path. “Order the ingredients for your next delivery” reveals more than instructions naming every button. Watch what they attempt, where they hesitate and how they respond to an unexpected result. Explain that the design is being examined, not their personal competence.
A prototype can make this possible before implementation. Use content realistic enough for the question and explain simulated parts. Avoid solving every difficulty immediately for the participant. If assistance becomes necessary, record it; a task completed with coaching should not quietly become evidence that the design worked without help.
Turn findings into specific improvements
Record the task, observed behaviour, consequence and possible explanation. “The participant submitted a second order because no confirmation was visible” gives the team something concrete to address. “The site is confusing” is too broad. Distinguish a preference from a barrier that prevents an important task or causes an error with meaningful consequences.
Use prioritisation to select improvements according to task importance, severity and available evidence. Do not focus only on the easiest cosmetic fixes. If the main problem is an unclear order state, changing decorative spacing may improve appearance while leaving the costly uncertainty untouched. Recheck the changed part to see whether the intended difficulty has actually been reduced.
Use measures with a clear definition
Task completion, avoidable errors, requests for help and time on a defined task can all be useful. Define what counts as completion and whether assistance is allowed. Pair measurements with observations so you can understand what happened. A time difference alone rarely explains whether a person was confused, interrupted or simply comparing options carefully.
Small rounds can identify concrete problems, but they do not reliably estimate how often every problem occurs in the entire audience. Likewise, a high completion rate in an artificial task does not guarantee success in everyday use. Keep the sample, situation and version visible when presenting the result to others.
A practical check you can do this week
Choose one task that matters to customers or staff and ask someone appropriate to complete it. Use a plausible scenario and observe without directing their route. Note missing information, unclear choices, unexpected results and moments when help is needed. Ask afterwards what they believed happened and whether the outcome matched their expectation.
Choose a small improvement connected to a specific obstacle, then examine the task again. Keep a record of the change and observation. This is more useful than debating whether the whole website feels intuitive. Usability becomes manageable when you connect a real person, a meaningful task and a difficulty the team can understand and act on.
Common questions
Does good usability mean fewer clicks?
Not necessarily. An extra step can clarify a consequential choice or prevent an error. Remove unnecessary effort, but assess the whole task rather than counting clicks alone. People need understandable choices and feedback as well as a short route.
Can the team test its own design?
The team can catch obvious faults, but familiarity hides problems that new users encounter. Include people who resemble the intended audience and do not know the planned path. Internal checks and observation with users answer different questions and can complement each other.