Make the next action
clear to the person using it.

A screen may be waiting for input, loading information, showing an empty result, or confirming a completed action. Each state needs an explanation that matches what the system knows. An empty list should not look identical to a connection failure.

Write labels in the language the user recognizes. If a button changes a record, explain the action rather than relying on an icon or an internal system term. A confirmation should make clear what happened and whether another step is required.

An error message should identify the problem and, where possible, tell the person how to correct it. Keep information they have already supplied when it is safe to do so. Do not imply that an action succeeded if its status is uncertain.

Consider an illustrative address-editing screen. If saving fails, the person needs to know whether the old address remains in use and whether trying again is appropriate. The wording, system response, and recovery action need to agree; visual polish cannot resolve a contradiction between them.

Include keyboard operation, visible focus, readable contrast, understandable form labels, and layouts that adapt to smaller screens. Information should remain meaningful without depending on color or motion alone.

Potential project materials include an interaction outline, a prototype, a set of interface states, and review notes tied to agreed tasks. Their scope depends on the product. A prototype demonstrates proposed behavior; it does not establish that production data, permissions, security, or service availability have been implemented.