Review complete tasks, not isolated screens
To review a business application, ask whether the intended users can complete their real tasks, understand the result and recover when something goes wrong. Start with a few representative workflows. Attractive screens are useful only when the information, permissions and actions support the work.
My work on Customiser, Medaur HIMS and Digitrack involves document review, patient records and financial information. Across those contexts, the useful unit of review is a task: enter the information, check it, complete the action and understand the resulting state.
Choose tasks and define successful completion
List the frequent tasks and the less frequent actions with significant consequences. Include creating a record, finding an existing one, correcting a mistake, approving work and exporting information where these apply. Use realistic data with permission to use it, or clearly synthetic examples.
Write the intended result before the session. “Review this screen” produces opinions about appearance. “Find the latest approved version and explain who approved it” tests information structure and understanding. Avoid telling participants which buttons to use when that is part of what you need to learn.
Include people with different responsibilities and levels of familiarity. An administrator who knows the whole data model may navigate successfully through a screen that confuses an occasional user. Keep observations tied to the role and task rather than averaging every participant into one generic user.
Check data entry and editing
Inspect labels, required fields, examples and default values. Each field should explain what information belongs there without relying on placeholder text that disappears while typing. When two values look similar, add enough context to help users choose the correct one.
Test keyboard navigation and ordinary correction. Can a person move through the form, edit a previous value and see which fields need attention? When validation fails, preserve the valid information already entered and explain how to fix the problem near the relevant field.
Worked example, for a fictional scheduling tool: a coordinator enters a customer, selects a staff member and submits an appointment without an end time. The form identifies the missing field and preserves the other values. After the coordinator fixes it, the connection drops during submission. The tool checks whether the appointment was saved before offering a retry, then shows the confirmed appointment reference. Review the whole sequence, including keyboard access and whether the coordinator can tell if another submission would create a duplicate.
Make state and consequences understandable
Review labels such as draft, approved, sent and completed against the actual workflow. A status should describe something the system knows, not a hoped-for outcome. After a save or submission, show what happened and whether another step remains.
For actions with significant consequences, make the affected record and result clear before the action is taken. Where the business rules permit it, provide a way to reverse an action or correct the record. Use confirmation only where it helps the user make a meaningful decision; repeated unnecessary dialogs become background noise.
A hypothetical document-review tool should distinguish accepting an extracted value from sending the full record to another system. Combining both into an unexplained “Done” button makes it harder to understand responsibility and recover from a mistake.
Review permissions, failures and long-running work
Test each role using the access it is supposed to have. Confirm both what appears in the interface and what the application actually permits. Hiding a button is not a substitute for enforcing the underlying permission. Error messages should explain the available next step without exposing another person’s private information.
Try empty lists, unavailable records, failed requests and interrupted connections. The interface should distinguish “there are no results” from “the results could not be loaded.” Give users a safe way to retry, and check that repeated actions do not create duplicates.
For processing that takes time, explain whether work is queued, running, awaiting review or failed. Consider whether the person can leave the page and return to the result. Unexplained spinners make it difficult to know whether to wait, retry or ask for help.
Observe behavior and prioritize the repairs
Ask participants to explain what they expect before important actions and what they believe happened afterward. Record hesitation, backtracking, incorrect assumptions and unfinished tasks. Separate an observed problem from a preferred visual style; both may matter, but they require different evidence.
Prioritize issues by consequence and frequency. A mislabeled approval action can be more urgent than a spacing inconsistency. Group related problems by their underlying cause, such as unclear record identity or inconsistent status language, instead of creating a separate redesign for every screen.
Retest the changed workflow with the original task and the affected roles. Record the task, observed difficulty, consequence, proposed repair and acceptance check. This gives the designer and developer a specific behavior to improve and a way to verify the result.
