Interaction Patterns, States and Feedback

Introduction

Interaction design concerns how people act on a digital product, how the product responds, and how users understand what has happened. A button, form, search field, menu, notification, or onboarding sequence is not merely a visual object. It is a temporary system that moves through states and communicates those states to the user.

A useful interaction must answer three questions:

1. What can the user do?
2. What is the current condition of the interface?
3. What happened as a result of the user’s action?

When these questions are answered clearly, users can act confidently, recover from mistakes, and build an accurate mental model of the system. When they are not, even visually attractive interfaces become confusing, slow, and error-prone.

This chapter presents practical patterns for controls, forms, search, selection, disclosure, onboarding, notifications, error prevention, and recovery. It also introduces a method for documenting interface states and microinteractions.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish interaction patterns from visual styling;
• identify and document important interface states;
• design controls with clear affordances, feedback, and accessibility;
• structure forms, search, selection, and disclosure interactions;
• design onboarding and notifications without creating unnecessary interruption;
• prevent errors and support effective recovery;
• specify microinteractions using triggers, rules, feedback, and loops;
• evaluate interaction designs using usability, accessibility, and ethical criteria.

1. Interaction as a State-Based System

An interaction pattern is a reusable solution to a recurring user problem. Examples include a confirmation dialog before deleting data, autocomplete in a search field, progressive disclosure of advanced settings, and inline validation in a form.

A pattern is not a fixed visual template. It includes:

• a user goal;
• an initial condition;
• one or more actions;
• system rules;
• visible or audible feedback;
• possible success, failure, cancellation, and recovery states.

1.1 States and transitions

A state describes the condition of an interface or component at a particular time. A submit button, for example, may be idle, focused, pressed, disabled, loading, successful, or displaying an error.

A transition occurs when an event changes the state. Events may include a click, key press, pointer movement, network response, timeout, or validation result.

A simple model is:

Current state + event + rule → next state + feedback

For example:

Form editing + Submit + required fields valid
→ Submitting + progress indicator

The model is useful because it exposes missing conditions. What happens if the network fails? Can the user edit while submission is in progress? Is the button disabled, or does pressing it create a duplicate request?

1.2 Common component states

A design should not rely only on colour to distinguish these conditions. Text, icons, shape, position, focus treatment, or status announcements should reinforce meaning.

2. Controls and Affordances

Controls allow users to change data, navigate, select options, or initiate operations. Their design should communicate both possibility and consequence.

2.1 Choosing the appropriate control

• Button: initiates an action, such as “Save” or “Download”.
• Link: takes the user to another location or resource.
• Checkbox: allows independent yes/no choices; several may be selected.
• Radio button: allows one choice from a mutually exclusive set.
• Switch: changes an immediate setting between two states.
• Select menu: supports a choice from a longer list when space is limited.
• Tabs: switch between related views at the same level.
• Slider: selects a value along a continuous or ordered range.
• Text input: accepts user-provided text or numbers.

The control should match the user’s mental model. A switch suggests an immediate change, whereas a checkbox often represents a choice that will be applied later when a form is submitted.

2.2 Labels, grouping, and hierarchy

Use action-oriented labels such as “Create account” rather than vague labels such as “Continue,” unless the context makes the result unmistakable. Primary actions should be visually prominent but should not obscure secondary actions such as cancellation.

Related controls should be grouped using proximity, headings, fieldsets, and consistent alignment. A group of radio buttons needs a meaningful group label; individual options alone may not explain the decision being made.

2.3 Focus and keyboard access

Keyboard users need a predictable focus order and a visible focus indicator. Removing browser focus outlines without providing an equivalent is a serious usability and accessibility defect. Focus should generally move to the next logical task after an action—for example, to an error summary after a failed submission or to newly loaded content after a search.

3. Forms: Supporting Accurate Input

Forms impose cognitive and physical effort. Good form design reduces unnecessary decisions, makes requirements visible, and provides useful feedback at the appropriate time.

3.1 Form structure

A form should have:

• a clear purpose and title;
• labels positioned close to their controls;
• instructions before the user needs them;
• sensible grouping of related fields;
• appropriate input types and mobile keyboards;
• a clear primary action;
• a review or confirmation stage for consequential actions.

Do not request information merely because it might be useful later. Data minimisation improves completion rates and reduces privacy risk.

3.2 Validation timing

Validation may occur while typing, when a field loses focus, or when the user submits. Immediate validation is helpful for constraints that can be checked without disrupting composition, such as a password length requirement. It can be irritating when every keystroke produces an error, particularly for names, addresses, or assistive-technology users.

A practical approach is to show neutral requirements before input, validate after meaningful interaction, and provide a complete summary after submission. Error messages should identify the problem and the remedy:

• Weak: “Invalid input.”
• Better: “Enter a date in the format DD/MM/YYYY.”
• Better still where relevant: “The end date must be after the start date.”

3.3 Preserve user input

When validation fails, retain valid entries and place focus where correction is needed. Avoid clearing the entire form because of one error. For long forms, preserve data across navigation and warn users before abandoning unsaved work.

4. Search, Selection, and Filtering

Search interfaces should help users express an information need and understand the result set.

4.1 Search behaviour

A search field benefits from a descriptive label, an example or placeholder that does not substitute for the label, and a clear submission method. Autocomplete can reduce typing, but suggestions must be relevant, keyboard accessible, and distinguishable from the user’s own text.

Search feedback should communicate:

• what was searched;
• how many results were found, when meaningful;
• whether filters or sorting are active;
• what the user can do next.

An empty result should not be a dead end. Offer spelling suggestions, broader categories, removal of restrictive filters, or a link to browse.

4.2 Selection patterns

Selection controls should make current choices persistent and visible. For multiple selection, show selected items in the control and provide a clear way to remove them. Avoid requiring users to remember selections made on earlier screens.

Filtering is different from navigation: filters narrow the current result set, while navigation changes location or category. Users should be able to see and clear active filters individually. On small screens, a filter drawer may be appropriate, but it should show whether filters are applied and provide an explicit apply or close behaviour where needed.

5. Disclosure and Onboarding

Disclosure patterns manage complexity by revealing information when it becomes relevant.

5.1 Progressive disclosure

Accordions, expandable details, tooltips, and step-by-step flows can reduce initial complexity. However, hiding essential information behind a disclosure creates discoverability problems. The closed label should clearly describe the hidden content, and the expanded state should be visually and programmatically identifiable.

Use a tooltip for brief, supplementary information—not for essential instructions or long text. On touch devices, hover-only disclosure is unsuitable.

5.2 Onboarding

Onboarding should help users reach meaningful value quickly. It may include orientation, account setup, permissions, preference selection, or a short guided task. Effective onboarding is:

• relevant to the user’s immediate goal;
• skippable when possible;
• progressive rather than overloaded;
• interruptible and resumable;
• explicit about why permissions or personal information are needed.

Do not use onboarding to conceal basic usability problems. If an interface requires a long tutorial to explain ordinary controls, the underlying design may need revision.

6. Notifications and Feedback

Feedback closes the loop between action and outcome. It can be visual, auditory, tactile, textual, or structural—for example, a list updating after a filter is applied.

6.1 Feedback strength and interruption

Use the least disruptive feedback that adequately communicates the result.

A toast notification is useful for brief, non-blocking status information, but it should not contain the only copy of important instructions. It must remain readable, accessible to screen readers, and available long enough to understand. Do not stack large numbers of transient messages.

6.2 Microinteractions

A microinteraction is a small interaction that supports one task, such as toggling a setting, liking an item, copying a code, or showing password visibility. A useful specification identifies four elements:

1. Trigger: what starts the interaction;
2. Rules: what the system does;
3. Feedback: what the user perceives;
4. Loops and modes: what happens on repetition, reversal, delay, or failure.

Example specification:

Microinteractions should communicate without unnecessary animation. Motion must respect reduced-motion preferences and must not delay essential tasks.

7. Error Prevention and Recovery

Errors arise from user action, system conditions, ambiguous wording, or mismatches between the interface and the task. A mature design addresses all four.

7.1 Prevention strategies

• constrain input with appropriate controls;
• show valid formats and units;
• provide sensible defaults without silently making consequential decisions;
• preview destructive or expensive actions;
• use undo when feasible;
• prevent duplicate submissions;
• distinguish required from optional fields;
• confirm only actions with meaningful risk.

Overuse of confirmation dialogs produces “confirmation fatigue.” Users may approve warnings automatically, so the dialog should be reserved for actions whose consequences justify interruption.

7.2 Recovery design

A recoverable error should answer:

1. What happened?
2. Why did it happen, if known?
3. What can the user do now?
4. Has the user’s work been preserved?

Technical details may be useful for support staff but should not replace plain-language guidance. For network failure, “We couldn’t save your changes. Your draft is stored on this device. Try again” is more useful than “HTTP 503.”

Recovery also includes cancellation, undo, back navigation, retry, editing, and escalation to support. A good system makes the safe path easy and avoids blaming the user.

8. Documenting Interaction States

Design documentation should make behaviour testable by another designer, developer, or quality specialist. A state inventory can be organised as follows:

For each interactive component, document:

• default, focus, hover, pressed, selected, disabled, loading, success, and error states where relevant;
• keyboard and screen-reader behaviour;
• data persistence and cancellation rules;
• timing of temporary feedback;
• responsive changes at different viewport sizes;
• failure conditions and recovery actions.

This documentation is also a test plan. Every state transition should be represented in usability testing or functional acceptance criteria.

9. Applied Case: Illustrative Mobile Appointment Booking Service

Background

A fictional clinic is redesigning its mobile appointment service. Users must select a department, choose a clinician, provide personal details, and confirm an appointment.

Problem

The existing service presents all fields on one long page. Users frequently select unavailable times, lose their details after validation errors, and do not know whether the booking has succeeded. The service also uses colour alone to show unavailable appointments.

Analysis

The task contains distinct decisions and depends on changing availability. A single page hides important transitions. The main risks are incorrect selection, duplicate submission, privacy exposure, and uncertainty after payment or booking.

Approach and solution

The redesigned flow uses progressive steps:

1. Choose department and location.
2. Choose clinician and date.
3. Display available times, with unavailable times disabled and labelled.
4. Collect only necessary patient information.
5. Review appointment details before confirmation.
6. Submit with a loading state that prevents duplicate activation.
7. Show a confirmation containing date, time, location, reference number, and options to add to a calendar or cancel.

If the network fails, the system preserves the completed fields and displays a retry action. If a selected time becomes unavailable, the user is returned to the time-selection step with an explanation rather than losing the entire form. Screen-reader status announcements communicate loading and success. Focus moves to the first error or the confirmation heading as appropriate.

Outcome

In an illustrative usability evaluation, participants complete the task with fewer navigation errors because each step has a clear purpose and the review screen exposes mistakes before submission. The design also improves operational reliability by making duplicate submission less likely.

Learning points

The case demonstrates that interaction quality is not achieved by adding more messages. It results from modelling states, preventing predictable errors, preserving user work, and giving feedback that matches the risk and timing of each operation.

10. Accessibility, Ethics, and Contemporary Practice

Interaction design is an accessibility responsibility. Controls need semantic names, keyboard operation, visible focus, adequate contrast, sufficient target size, and status communication that assistive technologies can perceive. Error messages should be associated with fields and should not depend on colour, sound, or motion alone.

Ethically, feedback must not manipulate users into choices they would not otherwise make. Dark patterns include disguised advertisements, confusing opt-outs, forced continuity, deceptive urgency, and confirmation wording that reverses the meaning of the user’s choice. Notifications should not be designed to maximise attention at the expense of wellbeing.

Privacy-sensitive interactions should explain collection, use, retention, and sharing at the point of decision. Consent should be informed and freely given rather than obtained through unequal button emphasis or repeated pressure.

AI-assisted interfaces introduce additional states and risks. A system may be generating, uncertain, blocked, or awaiting clarification. Users should be told when content is generated or when an action is automated, given opportunities to review consequential outputs, and offered a route to correct or contest results. Designers should not represent probabilistic output as certainty.

Responsive design also affects interaction states. A desktop hover state may become a touch disclosure on mobile; a side panel may become a full-screen flow; a multi-column form may become a sequential form. Responsive behaviour should preserve task meaning, focus order, feedback, and recoverability—not merely resize visual elements.

Best-Practice Checklist

Before implementation, ask:

• Is the control appropriate to the decision?
• Can users identify its current state?
• Does every important action provide timely feedback?
• Are loading, success, empty, and failure states designed?
• Are errors specific, respectful, and recoverable?
• Is user input preserved after failure?
• Can the interaction be completed by keyboard and assistive technology?
• Does the mobile version preserve meaning and control?
• Are notifications proportionate to urgency?
• Are privacy, consent, and persuasive techniques ethically acceptable?
• Can another professional implement and test the documented behaviour?

Chapter Summary

Interaction patterns are reusable solutions to recurring user problems, but they must be understood as behavioural systems rather than visual components. Every important component has states, triggers, rules, feedback, and possible recovery paths. Controls should match the decision being made; forms should reduce effort and preserve input; search and selection should expose current conditions; disclosure should manage complexity without hiding essential information; and onboarding should support immediate value without coercion.

Feedback should be timely, understandable, accessible, and proportionate to the consequence of the action. Error prevention is preferable to error correction, but robust products also provide undo, retry, cancellation, explanation, and preservation of user work. State inventories and microinteraction specifications make behaviour clear to design and development teams. Accessibility, privacy, ethical persuasion, responsive behaviour, and transparency in AI-assisted interactions are essential parts of professional interaction design.

Key Terms

Interaction pattern: A reusable solution to a recurring interaction problem.

State: The condition of a component or interface at a particular time.

Transition: A change from one state to another caused by an event and rule.

Affordance: A perceptible indication of how an object can be used.

Feedback: Information provided by a system in response to an action or condition.

Microinteraction: A small interaction supporting one focused task.

Trigger: An event that starts an interaction.

Rule: The logic determining what the system does after a trigger.

Focus: The current keyboard or assistive-technology position.

Validation: Checking whether input satisfies specified requirements.

Progressive disclosure: Revealing complexity or information as it becomes relevant.

Autocomplete: Suggestions offered while a user enters a query.

Filter: A mechanism that narrows a set of results.

Notification: A message communicating system status or an event.

Toast: A brief, usually non-blocking status message.

Error prevention: Design that reduces the likelihood of incorrect action.

Error recovery: Assistance that helps users correct or reverse an error.

Undo: An operation that reverses a previous action.

Dark pattern: A deceptive design practice that steers users against their interests.

Responsive interaction: Behaviour that adapts to device or viewport conditions while preserving task meaning.

Review Questions

Short Answer Questions

1. What is the difference between an interaction pattern and a visual component?
2. Name four common states of an interactive component.
3. Why should error messages explain a remedy rather than merely report failure?
4. What are the four elements of a microinteraction specification?
5. Why should confirmation dialogs not be used for every potentially destructive action?

Long Answer Questions

1. Explain how state modelling improves the design and implementation of a form.
2. Compare checkboxes, radio buttons, switches, and select menus, including appropriate use cases.
3. Discuss how search, filtering, empty results, and autocomplete should work together.
4. Explain principles for designing accessible and ethical notifications.
5. Describe how responsive design can alter interaction patterns without changing the underlying user goal.

Analytical / Application Questions

1. Design the state inventory for a file-upload control, including progress, success, failure, cancellation, and retry states.
2. A payment form loses all entered information whenever one field is invalid. Analyse the usability and ethical problems and propose a recovery design.
3. Create a microinteraction specification for changing an account email address. Include triggers, validation, security feedback, success, failure, and reversal options.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an interaction state?

A. A colour selected for a button

B. The condition of a component at a particular time

C. A permanent page layout

D. A user’s personal preference

Correct Answer: B. The condition of a component at a particular time

Question 2

Which control is most appropriate when users may select several independent options?

A. Radio buttons

B. A switch group

C. Checkboxes

D. A single-select menu

Correct Answer: C. Checkboxes

Question 3

What is the most useful error message?

A. Invalid input

B. Error 403

C. Something went wrong

D. Enter a date in the format DD/MM/YYYY

Correct Answer: D. Enter a date in the format DD/MM/YYYY

Question 4

Which item is one of the four elements of a microinteraction?

A. Trigger

B. Brand palette

C. Page grid

D. Font family

Correct Answer: A. Trigger

Question 5

What should a system generally do after a form submission fails?

A. Clear every field

B. Preserve valid input and explain recovery

C. Silently reload the page

D. Disable all navigation permanently

Correct Answer: B. Preserve valid input and explain recovery

Question 6

What is a major limitation of a toast notification?

A. It cannot communicate any status

B. It is always visually distracting

C. It may disappear before important information is understood

D. It prevents all user interaction

Correct Answer: C. It may disappear before important information is understood

Question 7

Which practice best supports keyboard accessibility?

A. Removing the focus outline

B. Using hover as the only state indicator

C. Providing a predictable focus order and visible focus indicator

D. Disabling keyboard submission

Correct Answer: C. Providing a predictable focus order and visible focus indicator

Question 8

What is progressive disclosure intended to do?

A. Hide essential information permanently

B. Reveal complexity when it becomes relevant

C. Replace all labels with icons

D. Prevent users from changing settings

Correct Answer: B. Reveal complexity when it becomes relevant

Question 9

Which action is generally appropriate for a reversible deletion?

A. A quiet undo option

B. An irreversible warning on every click

C. No feedback

D. Deleting the user’s other records

Correct Answer: A. A quiet undo option

Question 10

Why should a selected search filter be visible?

A. To increase visual decoration

B. To help users understand why results are limited

C. To prevent users from clearing it

D. To replace the search query

Correct Answer: B. To help users understand why results are limited