Actions 101: Buttons, States, Errors, and Recovery

Session 6 turns the learner from screen reader into interaction reader. In the previous sessions, she learned to frame the user moment and organize layout priority. Now she asks what the user can do, what the product promises, what feedback appears, and how the user recovers when something goes wrong.

This is where a screen becomes believable product behavior. A static mockup can look polished while hiding the most important moments: loading, saving, failing, empty results, invalid input, unavailable actions, confirmation, and undo.

The session standard is action clarity plus recovery. The learner should be able to map one action across states, rewrite vague labels, identify missing states, and make one product decision about what state or recovery path should improve first.

The sources behind this session turn interaction quality into practical checks. Apple and GOV.UK provide guidance on button roles, labels, and destructive actions. NN/g heuristics emphasize visibility of system status, user control, error prevention, and recovery. GOV.UK and Material guidance show concrete form and error patterns.

W3C accessibility guidance reminds us that controls need accessible names and state; errors need programmatic relationship, not only red styling. Figma interactive components make those states visible in prototypes and design systems.

The beginner translation is simple: the interface should tell people what they can do, what is happening, what happened, and what to do next if the path breaks.

Session 6 vocabulary helps the learner inspect product behavior. The important move is separating action, state, and message. A button label is the action promise. A state tells what is happening. A message explains a result, problem, or next step.

A weak critique says "the button is confusing." A stronger critique says "the label Submit does not say whether the application is sent, saved, or checked. I would change it to Send application because that matches the action promise."

The learner should also distinguish error types. A missing required field, a failed upload, a sold-out product, and a permission problem need different recovery paths.

A button label should answer the user question: if I press this, what will happen? Vague labels such as Submit, OK, Done, and Next can be acceptable in some narrow contexts, but they often make users guess.

The learner should write labels with plain verbs and meaningful objects: send application, save changes, continue to payment, remove item, retry upload. The label should match the real product result.

Action hierarchy matters. A screen should not present five equally strong buttons unless the task truly requires equal choices. Primary, secondary, destructive, cancel, and recovery actions should look and read differently enough to reduce risk.

A state is what is true about the interface right now. States are a form of communication. They tell users whether something is ready, focused, changing, unavailable, successful, failed, or empty.

A prototype without states can hide product risk. It may show the normal screen but not what happens during saving, after success, after failure, when results are empty, when a product is unavailable, or when the user loses connection.

The learner should not design every possible state at full fidelity in Session 6. She should learn to list the important states, identify missing states, and explain which ones matter most for the user task.

The user experience around an action has at least three phases. Before action, the interface should make the decision safe enough. During action, the interface should confirm that the product is working. After action, the interface should confirm result and next step.

This is especially important for risky actions: payment, deletion, booking, cancellation, account changes, file upload, and public posting. The user may need cost, consequence, visibility, privacy, and recovery information before commitment.

The learner should practice drawing an action timeline: before, during, after, failure, and recovery.

Disabled states require judgment. They can prevent duplicate submissions or indicate real unavailability. They can also create dead ends if users cannot understand why an action is unavailable.

The practical rule is: if users can do something to make the action available, tell them what is missing. If the condition is outside user control, explain the condition and offer a useful alternative if one exists.

The learner should avoid treating disabled as the whole design solution. Disabled is a state, not an explanation.

Not all errors should sound the same. A user-fixable input error should name the field problem and how to fix it. A system error should avoid blame and preserve progress where possible. A business-rule block should explain the condition and the next available path.

Good error messages use plain language, precisely indicate the problem, and constructively suggest a solution. They should not hide behind codes, blame the user, or say only that something went wrong.

The learner should write error messages in the pattern: what happened, where it happened, how to continue.

Forms need a recovery system, not just red text. GOV.UK guidance is useful because it shows both the error summary and the inline error. The summary helps users find all problems; the inline message explains what to fix at the field.

Keeping user input is part of recovery. Clearing fields after an error increases effort and stress. Users should be able to see what went wrong, edit the previous answer, and continue.

The learner should practice mapping a form error path: submit, error summary, affected field, corrected value, resubmit, success.

Accessible actions expose meaning, role, and state. A visual button with no accessible name is not enough. A toggle that changes only color can be unclear. An error that appears only as a red border can be missed.

WAI-ARIA guidance gives designers and developers language for states such as disabled, pressed, and invalid. The learner does not need to implement ARIA, but she should know what must be communicated to users and to assistive technology.

A useful beginner test is: if the visual styling disappeared, would the action and state still be understandable through words, structure, and behavior?

A state map lists the conditions around one user action. This is a small but powerful product-owner artifact. It helps a team see what needs to be designed, written, tested, and built.

The learner should start with one action, not a whole product. For example: save a recommendation, upload a file, book an appointment, submit a form, delete an item, or retry a failed payment.

The state map should include the label, success message, loading feedback, likely failure, recovery path, and whether input or progress is preserved.

AI is useful in Session 6 because it can help find missing states and weak labels. The danger is that AI may invent technical behavior or treat every problem as a copywriting issue.

A stronger prompt gives AI the problem sentence, screen or flow, current action labels, and known states. It asks for action roles, button promises, state checklist, prevention, recovery, disabled-state risk, rewrites, and one priority decision.

The learner should practice accept, adapt, reject: accept specific missing-state observations, adapt broad wording suggestions, reject invented backend behavior or generic redesign advice.

The course project example is a product recommendation experience. A useful action might be saving a recommendation to a shortlist. This one action has multiple states: default, saving, saved, failed, empty shortlist, and remove from shortlist.

The product decision is not only what the button looks like. It is whether the user trusts that their choice was saved, whether they can recover from a failed save, and whether they can find the saved item later.

The learner should say: I would improve the failed-save state first because losing a recommendation damages trust and may make the user repeat research.

A form error is a good beginner practice because the recovery pattern is visible. The learner can see the summary, inline error, preserved input, and resubmit path.

The same principle applies outside forms. If something fails, the product should say what happened, keep safe progress where possible, and give a next action.

The tutor should push the learner away from blame. The product should not sound annoyed that the user made a mistake. It should help the user recover.

The studio output is an action-state checklist. It should include one main action, action roles, button labels, state map, missing-state notes, rewritten messages, accessibility risks, AI critique notes, and one product decision sentence.

The artifact should stay small. The learner should not redesign the whole flow. One action is enough if it is mapped deeply.

For home study, the learner should collect five buttons from safe apps or websites. For each, she should write what the label promises, what state appears before and after pressing, and what recovery path exists if the action fails.

The lecturer can use the references below to deepen examples around buttons, validation, error summaries, usability heuristics, Material error patterns, accessibility states, and Figma interactive components.