User Interfaces: Make Actions and State Understandable
A user interface is the part of a system through which a person understands its state and takes action.
- Author
- absequ
- Published
- Updated
- Category
- UI and UX
- user interfaces
- ui and ux
- practical guide
A user interface is the part of a system through which a person understands its state and takes action. For a website, that includes language, controls, navigation, feedback and the order in which information appears. Attractive styling helps, but a useful interface first makes the next step understandable and the result of an action observable.
On this page
The mental model
Think in terms of tasks rather than collections of components. A contact form is not just four text boxes: it has an empty state, editing state, invalid state, submission state and a result. Each state changes what a person needs to know. The same task may be performed with a pointer, keyboard, touch input or assistive technology.
Native HTML elements carry behavior and semantics that visual styling alone does not provide. A button triggers an action; a link navigates to a resource. Choosing the correct primitive gives users familiar keyboard behavior and gives other software a useful model of the page. Styling a div to resemble a button does not supply those contracts.
A practical workflow
Write the user's goal in one sentence and identify the minimum information needed to complete it. Put the primary action close to its context, name it with a concrete verb and communicate prerequisites before submission. Keep secondary navigation available without allowing it to compete with the task.
Design feedback as part of the workflow rather than a decoration added at the end. Pending feedback should prevent accidental duplicate work where appropriate. Errors should identify a correctable condition in useful language, while success should explain what happened without promising an unimplemented follow-up. Preserve entered data when a recoverable error occurs.
Worked example
<form>
<label for="work-email">Work email</label>
<input id="work-email" name="email" type="email" required
aria-describedby="email-help" autocomplete="email">
<p id="email-help">Use an address where you can receive our reply.</p>
<button type="submit">Send enquiry</button>
<p role="status" aria-live="polite"></p>
</form>This small structure supplies a programmatic label, a browser-recognized input type and a native submit control. It deliberately does not include a backend or claim that a message was delivered. Server validation, abuse protection and accurate response handling remain separate responsibilities. Client-side required validation improves the experience but cannot establish that submitted data is trustworthy.
Evaluate the interface with actual task attempts. Can someone identify the primary action without an explanation? Does focus move predictably? Can a user recover after an invalid email or a network interruption? Inspect a narrow viewport and enlarged text rather than assuming a desktop screenshot demonstrates usability.
Failure modes and security
A visually hidden control can still be reachable if it remains in the accessibility tree or tab order. Conversely, removing an outline can make a working control practically unusable for keyboard users. Keep visible focus, clear labels and adequate contrast in every theme, including hover, disabled and error states.
Do not reveal confidential implementation details in error messages. An interface should not expose raw database errors, account-enumeration clues or private request bodies merely because the server returned them. Review both the happy path and the failure language as part of the product contract.
Practice and verification
Choose one existing page and list its states before changing its colors. Give each state an observable entry condition and an accessible presentation. Test the page with keyboard-only navigation, a long translated label and a failed request. Record whether the user can still finish the task. Use a shared visual pattern when it reduces inconsistency, but do not force unrelated workflows into the same template merely because their screenshots look similar.
References
WAI interaction patterns — W3C
Usability heuristics — Nielsen Norman Group