Usability Improvement Examples: Navigation, Input Errors, and Recovery
Shusaku Yosa

Usability improvements start with the task a person needs to complete. Observe where they hesitate, make an error, or struggle to recover, then test a specific change. Preserving search filters, explaining an input error, and making saved status visible can help in the right context. A smaller number of clicks does not guarantee a better result.
Compare screens using the same user and task
Consider a fictional quotation service. A first-time business user must compare two quotations with different staffing assumptions and save one. The question is whether that person can complete the task accurately, rather than whether a developer who knows the interface can finish it quickly.
Visual appeal, useful functionality, and the ease of using that functionality are separate questions. Nielsen’s introduction to usability distinguishes utility—the functionality people need—from usability. Making this distinction helps a team avoid polishing a function that does not address the customer’s need.
Improve finding, filtering, and comparing information
If returning from a detail screen clears every search condition, the user must repeat work. Preserving the conditions is a possible improvement. Make the active filters and reset action visible as well: silently retaining an old filter can create a different error when the user starts a new search.
Observed problem | Proposed change | Task to verify |
|---|---|---|
Filters disappear on return | Preserve filters and show how to clear them | Compare candidates after changing one condition |
Similar buttons have unclear effects | Name the resulting action, such as save or request a quote | Choose the intended action without starting another process |
Relevant details sit on separate screens | Display comparable units and conditions together | Compare eligibility and assumptions as well as price |
Button text should match what happens next. “Start free” can mislead if the next action is only a sales inquiry or involves conditions that have not been explained. Test language that lets people predict the outcome rather than copying an internal feature name directly onto the screen.
Reduce confusion and errors during input
Explain the requested information, whether it is required, and its format near the field. Automatic formatting needs care: a changed date or number should remain understandable and correct. Saving a few seconds is not useful if a person submits an unintended value without noticing.
Observed problem | Proposed change | What to observe |
|---|---|---|
The required format is unclear | Provide a relevant format and example | Whether the person enters their own correct value |
An error clears other fields | Retain input that can be kept safely and identify the problem | Repeated work and recovery actions |
Only “invalid input” is shown | Name the field and explain the required correction | Whether the problem can be found without relying on color |
For example, “Choose a date after the start date” gives a corrective action. A red border alone does not. Separate validation errors from connection failures, and make the submission state clear enough to reduce accidental repeated requests. Avoid blaming the user for an interface that has not explained its requirements.
Make saving, deletion, and recovery understandable
A screen that does not acknowledge saving can cause repeated attempts. Show the saved state and destination, or explain failure and the next action. Visibility of system status and error prevention are among Nielsen’s usability heuristics. They are useful design questions, not evidence that a particular change will increase revenue.
For deletion, weigh the consequence and reversibility of an error. Removing a recoverable draft differs from deleting a record that cannot be restored. Show the affected item and relevant consequences, and use confirmation where it serves a purpose. Warning about every routine action can make significant warnings easier to overlook.
Check keyboard operation, labels, and non-color status cues alongside the task. W3C explains the overlap between accessibility and usability. A visual redesign or a successful task observation does not, by itself, establish accessibility conformance.
Record completion, assistance, and recovery
The following is a fictional evaluation plan, not a measured business result. Keep the task, success condition, and relevant participant characteristics consistent. If the facilitator explains an answer during the task, record that assistance rather than combining it with independent completion.
Item | Fictional evaluation plan |
|---|---|
Participant and environment | A first-time user on their usual laptop |
Task | Compare two staffing quotations and save one |
Success condition | Correct assumptions and destination, with confirmation that saving succeeded |
Observations | Hesitation, errors, help, repeated input, and recovery |
Time | From the end of the task briefing to completion; record unfinished attempts separately |
Timing only successful attempts hides the people who cannot finish. Examine completion, assistance, and unfinished reasons before speed. If the same participant repeats a task, learning can affect the result. Do not attribute every difference to the screen change.
Set conditions for accepting an improvement
Compare the impact of the problem, the strength of the observation, the affected users, and implementation effort. Check side effects: removing a field may create more work later, and a saved-state message may become stale. User requests are valuable clues, but clarify the task before choosing the solution.
Repeat the task after the change and look for both the original barrier and new errors. Discovering an operational improvement in a small observation is different from proving an increase in sales or conversion. Starting with one important task makes the change and its evaluation easier to discuss.
For the next step, use a usability evaluation plan; customer onboarding process design; a worksheet for defining useful metrics.