Interaction Design, Task Flows and Interface Patterns

Introduction

Interaction design concerns the way people accomplish goals through a digital product. While visual design determines much of an interface’s appearance, interaction design determines what users can do, how actions are performed, what information is required, and how the system responds. A visually attractive interface can still fail if users cannot understand its controls, predict its consequences, recover from errors, or complete tasks efficiently.

For UI/UX designers, interaction design provides a bridge between user research and interface production. Research reveals user goals and constraints; interaction design translates those findings into task models, flows, states, controls, forms, onboarding sequences, and feedback mechanisms. The designer’s responsibility is not simply to place interface elements on a screen, but to construct a coherent relationship among user intention, system behaviour, and visible feedback.

This chapter presents practical foundations for designing reliable interactions. It focuses on task flows, interface states, controls, forms, onboarding, feedback, consistency, constraints, error prevention, progressive disclosure, and established web and mobile patterns.

Learning Objectives

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

1. Explain the relationship between user goals, tasks, actions, and system responses.
2. Model common user journeys using task flows and decision points.
3. Identify interface states and design appropriate feedback for each state.
4. Select controls and form patterns according to user needs and context.
5. Apply consistency, constraints, error prevention, progressive disclosure, and visibility of system status.
6. Design effective onboarding and recovery experiences.
7. Evaluate established web and mobile patterns critically rather than copying them mechanically.
8. Analyse an interaction design problem and propose a practical solution.

1. Interaction Design as a Cycle of Action and Feedback

An interaction is a cycle. The user forms an intention, chooses an action, performs that action through an interface, and interprets the system’s response. The response may confirm success, display a result, request more information, or report a problem. The user then decides what to do next.

A useful simplified model is:

Goal → Intention → Action → System response → Interpretation → Next action

For example, in a banking application:

• Goal: transfer money to a friend.
• Intention: open the transfer function.
• Action: select a recipient and enter an amount.
• System response: display the transfer details and a confirmation option.
• Interpretation: verify that the recipient and amount are correct.
• Next action: confirm, edit, or cancel.

Good interaction design makes each stage understandable. The interface should make possible actions visible, indicate which actions are available, provide appropriate constraints, and show what happened after an action. Poor design often creates a gap between the user’s mental model and the system’s actual behaviour. A person may believe that pressing “Save” completes a process, while the system may only save a draft.

Important principles

Several principles are especially useful at certificate level:

• Visibility: Users should be able to perceive relevant options and system status.
• Affordance: An element should suggest how it can be used. A button should look actionable; a text label should not misleadingly appear to be a control.
• Feedback: The system should communicate the result of an action.
• Mapping: The relationship between a control and its effect should be understandable.
• Consistency: Similar actions and concepts should behave and appear similarly.
• Reversibility: Users should be able to undo, cancel, or recover from actions where feasible.
• Error tolerance: The design should reduce the likelihood and cost of mistakes.

These principles are not isolated rules. For example, a destructive action can combine visibility with constraint and reversibility by displaying a clearly labelled “Delete” button, requiring confirmation, and offering an undo option after deletion.

2. From User Goals to Task Models

A user goal is an outcome the user wants to achieve. A task is an activity undertaken to reach that goal. A subtask is a smaller component of a task. An action is a specific operation performed by the user or system.

Consider an online appointment service:

• Goal: arrange a medical appointment.
• Task: search for a provider, choose a time, enter patient information, and confirm the booking.
• Subtasks: select location, filter availability, compare times, and submit contact details.
• Actions: tap a date, select a time slot, type a phone number, or press “Confirm booking.”

Task analysis asks questions such as:

1. What is the user trying to accomplish?
2. What triggers the task?
3. What information does the user possess at each stage?
4. What decisions must be made?
5. Which steps are essential and which are created by the interface?
6. What can go wrong?
7. What outcome indicates success?

A well-designed task model separates the user’s objective from the organisation’s internal process. An organisation may require several administrative checks, but the interface should not expose unnecessary complexity if those checks can occur in the background.

Hierarchical task analysis

Hierarchical task analysis decomposes a goal into tasks and subtasks. A simple representation might be:

Book an appointment

1. Identify a service.
2. Choose a provider or location.
3. Select a date and time.
4. Provide required details.
5. Review information.
6. Confirm the booking.
7. Receive confirmation.

The decomposition should stop at a useful level of detail. If it is too broad, designers overlook important decisions. If it is too detailed, the model becomes difficult to use. The appropriate level depends on the design question. A form designer may need to analyse individual fields, while a product manager may need only the major stages.

3. Task Flows and User Flows

A task flow describes the steps required to complete one specific task, often assuming a relatively direct route. A user flow represents the broader paths users may take through a product, including alternative routes, decisions, errors, and interruptions.

For example, a task flow for resetting a password could be:

1. Select “Forgot password.”
2. Enter email address.
3. Submit request.
4. Open the email link.
5. Enter and confirm a new password.
6. Receive confirmation.

A fuller user flow also considers an unrecognised email, an expired link, a mismatched password, a cancelled process, and a user who returns to the sign-in screen.

Flow notation

A practical flow diagram uses:

• Rectangles for screens or actions.
• Diamonds for decisions.
• Arrows for movement or sequence.
• Notes for rules, constraints, or system conditions.
• Clearly labelled outcomes for success and failure.

A flow should show who performs an action. Some steps are user actions; others are system actions. This distinction prevents designers from assuming that a system response is automatic when it actually requires user confirmation.

Designing a flow

Begin with the user’s entry point and desired outcome. Then identify the minimum sequence that can achieve the outcome. Add decision points only when they represent a genuine difference in path. For each step, ask:

• What does the user know at this point?
• What action is possible?
• What feedback will follow?
• What happens if the user pauses, goes backward, or makes an error?

Avoid designing only the ideal path. A flow that works only when users enter perfect information is incomplete. Include empty states, loading states, failures, permission restrictions, and recovery paths.

Flow quality criteria

A useful flow is:

• Goal-oriented: every step supports a user or system requirement.
• Understandable: labels and transitions are predictable.
• Efficient: unnecessary steps and repeated data entry are reduced.
• Recoverable: users can correct mistakes and return to earlier stages.
• Inclusive: it works with different abilities, devices, languages, and levels of experience.
• Testable: each state and transition can be evaluated with users.

4. Interface States and System Status

An interface is not a collection of static screens. Each screen may have several states. Common states include:

A loading indicator alone is not sufficient if an operation takes a long time. The user may need an estimate, cancellation option, or explanation. Similarly, a generic message such as “Something went wrong” gives little assistance. Good feedback identifies what happened, what was affected, and what the user can do next.

State transitions

A control should have an intentional appearance and behaviour in relevant states. A submit button might be enabled when valid required information is present, show a progress state after activation, and display success or failure after the server responds. It should not allow repeated submissions while the first request is processing unless repeated actions are safe.

Designers should distinguish:

• Visual state: how an element appears.
• Interaction state: what the user can do with it.
• Data state: what information the system currently holds.

A disabled-looking control that remains clickable is misleading. A form that visually clears after a failed submission risks data loss. State design must therefore be coordinated with content, accessibility, and technical behaviour.

5. Controls and Interface Patterns

A control is an interface element through which the user initiates or changes an action. Common controls include buttons, links, text fields, checkboxes, radio buttons, switches, menus, tabs, sliders, date pickers, search fields, and dialogs.

Choosing a control

The choice should reflect the decision being made:

• Button: performs an action, such as “Save” or “Download.”
• Link: moves the user to another location or resource.
• Checkbox: permits independent selection of zero, one, or several options.
• Radio button: requires one choice from a small mutually exclusive set.
• Switch: changes an immediate setting between two states.
• Select menu: chooses one or more items from a larger set when space is limited.
• Tabs: switch among related views at the same level of hierarchy.
• Text input: captures information not efficiently represented by predefined options.

A common error is choosing a control because it is visually fashionable rather than semantically appropriate. For example, a switch suggests an immediate on/off setting. It is less suitable for a choice that requires a subsequent “Apply” action or for mutually exclusive alternatives with more than two possibilities.

Consistency and standards

Consistency reduces learning effort. It may be:

• Internal: consistent within one product.
• External: consistent with familiar platform or web conventions.
• Semantic: labels and icons maintain the same meaning.
• Operational: the same gesture or action produces the same kind of result.

Consistency should not become rigid uniformity. A familiar pattern may be inappropriate in a specialised context, and accessibility or safety may require deviation. When deviating, provide stronger explanation and test the result.

6. Forms: Asking for Information Responsibly

Forms are among the most common interaction structures and among the most frequent sources of friction. A form should request only information that is necessary, explain why sensitive information is needed, and support accurate completion.

Form design principles

1. Use clear labels. Labels should remain associated with their fields and should not depend solely on placeholder text.
2. Group related information. Contact details, payment details, and preferences should not be mixed without purpose.
3. Use a logical sequence. The order should match the user’s expectations and the task’s dependency structure.
4. Provide suitable input types. On mobile devices, an email, telephone, numeric, or date input can present an appropriate keyboard or picker.
5. Make required status clear. Do not assume that users understand an unexplained asterisk.
6. Validate at the right time. Immediate validation can be helpful, but premature error messages can interrupt concentration.
7. Preserve entered data. A failed submission should not erase the user’s work.
8. Support correction. Error messages should identify the field, describe the problem in plain language, and state how to fix it.

Validation

Validation can occur at three levels:

• Syntactic validation: Is the format acceptable, such as a valid email structure?
• Semantic validation: Is the meaning acceptable, such as a delivery date in the future?
• Business-rule validation: Does the input satisfy a policy, such as an order quantity within stock limits?

Client-side validation can provide fast feedback, but it should not be the only protection. Server-side validation remains necessary because client-side controls can be bypassed or may become inconsistent with current data.

Error messages should avoid blame. “Enter a valid postal code” is more useful than “Invalid input.” If the system knows the correct format, it should show an example. For sensitive or regulated information, designers must also consider privacy, security, retention, and consent.

7. Constraints and Error Prevention

A constraint limits available actions or values so that an invalid or harmful result is less likely. Constraints may be:

• Physical: a date picker prevents impossible calendar dates.
• Logical: choosing one delivery method may remove incompatible options.
• Semantic: a field labelled “Number of passengers” should not accept alphabetic words.
• Cultural or conventional: familiar formats help users interpret dates, currencies, and symbols, although localisation is essential.

Constraints should prevent genuine errors without unnecessarily blocking legitimate behaviour. A rigid password field that rejects a valid passphrase can create frustration. A safer approach is to communicate requirements clearly and support strong alternatives.

Error prevention is preferable to error correction, but prevention should not hide system rules. Users need to understand why an action is unavailable. Where prevention cannot eliminate risk, combine confirmation, clear consequences, undo, and recovery.

8. Progressive Disclosure and Complexity Management

Progressive disclosure presents essential information first and reveals additional detail when it becomes relevant. It reduces initial cognitive load while preserving access to advanced options.

Examples include:

• Showing basic search filters initially and placing advanced filters behind an expandable section.
• Displaying a summary of an order with an option to inspect item-level details.
• Asking for additional information only when a selected option requires it.
• Providing expert settings without placing them in the primary path of beginners.

Progressive disclosure should not be used to conceal important costs, risks, permissions, or terms. Information that affects informed consent must be visible at the appropriate decision point. The designer must balance simplicity with transparency.

9. Onboarding and First-Use Experiences

Onboarding helps users understand value, establish necessary settings, and complete an initial task. Effective onboarding is task-oriented rather than merely promotional.

A strong onboarding sequence generally:

1. States the product’s immediate value.
2. Requests only essential information.
3. Explains unfamiliar concepts at the moment they are needed.
4. Allows users to skip nonessential guidance.
5. Provides visible progress when several steps are required.
6. Leads to a meaningful first success.

A lengthy carousel of feature descriptions may explain the product but fail to help users accomplish anything. Contextual guidance, sample content, checklists, and just-in-time prompts often create more useful learning.

Onboarding also requires ethical care. Do not make privacy-invasive defaults difficult to change, disguise marketing consent as necessary setup, or use countdowns and confusing button labels to pressure acceptance. A user should understand what is optional, what is required, and what data is collected.

10. Feedback, Confirmation, and Recovery

Feedback can be visual, textual, auditory, haptic, or structural. It should match the importance and urgency of the event. A subtle status message may be enough for an autosave; a financial transfer may require a detailed confirmation and transaction reference.

Useful feedback answers three questions:

1. What happened?
2. What is the current status?
3. What can the user do next?

Confirmation patterns

Confirmation is appropriate when an action is consequential, difficult to reverse, or likely to be accidental. It is not necessary for every minor action; excessive confirmation creates “confirmation fatigue.” Alternatives include undo, delayed commitment, or a clearly reversible state.

Error recovery

A recovery experience should:

• preserve user-entered information;
• identify the affected part of the task;
• use understandable language;
• distinguish user error from system failure;
• offer a specific next action;
• provide support or escalation when self-service is insufficient.

A network failure should not be presented as though the user entered incorrect information. This distinction affects trust and directs the user toward the right response.

11. Responsive and Platform-Aware Patterns

Interaction patterns must account for device, input method, screen size, connectivity, and context of use. A desktop interface may support hover descriptions and a large multi-column form, while a mobile interface must support touch targets, one-handed use, limited space, and interruptions.

Responsive design is not simply shrinking a desktop layout. It may require changing navigation structure, grouping fields differently, converting a table into cards, or replacing hover-dependent interactions with visible controls. Platform conventions can improve usability, but designers should not assume that every platform convention is accessible or universally understood.

Accessibility should be integrated into interaction design. Controls need meaningful names, keyboard access where applicable, visible focus, sufficient contrast, appropriate status announcements, and error information that does not depend only on colour. Touch targets should be large enough and sufficiently separated to reduce accidental activation. Motion should not be the only way to communicate state, and users should be able to reduce nonessential animation.

12. Applied Case: Illustrative Redesign of a Library Renewal Flow

Background

A fictional university library allows students to renew borrowed books through a web portal. Students report that renewals sometimes fail without explanation, and many do not know whether a book has been successfully renewed.

Problem

The existing flow displays a list of books with a small “Renew” link. After activation, the page refreshes. A failure message appears at the top of the page, where it is easily missed. The system does not explain that books may be ineligible because another student has reserved them or because the renewal limit has been reached.

Analysis

The user goal is to extend the loan period for an eligible book. The important decision is not merely whether the user clicked a link, but whether the system accepted the renewal. The flow therefore needs a visible relationship between the selected item, the action, the eligibility rule, and the result.

Relevant states include:

• eligible for renewal;
• renewal processing;
• renewal successful;
• renewal unavailable because of a reservation;
• renewal unavailable because the limit has been reached;
• technical failure;
• offline or expired session.

Approach and solution

The redesigned flow uses a clear button labelled “Renew loan” for each item. Before activation, the interface displays the current due date and, where known, the renewal limit. After activation, the button enters a processing state and prevents duplicate requests. On success, the due date updates in place and a confirmation message states: “Renewed until 14 October.” A persistent transaction history records the change.

If renewal is unavailable, the interface explains the reason beside the relevant book and provides an appropriate next step, such as “Return by 30 September” or “Contact library support.” A technical failure preserves the page state and offers “Try again.” The system does not blame the student for server or network problems.

Outcome

The revised design makes status visible, reduces duplicate actions, explains constraints, and supports recovery. It also creates a testable flow: students can be asked to renew an eligible book, interpret an ineligible status, and recover from a simulated failure.

Learning points

1. A control label should communicate the action and its object.
2. A successful click is not the same as a successful task.
3. Constraints should be explained at the point of decision.
4. Each important system state requires appropriate feedback.
5. Good interaction design includes failure and recovery paths, not only the ideal path.

13. Evaluating Interaction Designs

Design evaluation can combine inspection, user testing, accessibility review, and product data. At certificate level, a practical evaluation session may ask representative users to complete realistic tasks while the designer observes:

• whether users understand the goal;
• where they hesitate;
• whether labels match expectations;
• whether errors are prevented or recovered from;
• whether feedback is noticed and understood;
• whether users can complete the task without assistance.

Do not treat completion alone as proof of quality. Users may complete a task slowly, with high effort, by guessing, or by memorising an accidental sequence. Record observed behaviour and ask follow-up questions without leading participants toward a preferred answer.

Common limitations include small samples, artificial test settings, unrepresentative participants, and overreliance on quantitative measures. Analytics can reveal where users abandon a flow, but usually cannot explain why. Combining behavioural evidence with interviews or usability observation produces stronger design decisions.

14. Technology, AI, and Governance Considerations

Contemporary interfaces increasingly use conversational agents, recommendation systems, biometric authentication, predictive forms, and adaptive personalisation. These technologies can reduce effort, but they also introduce uncertainty and governance concerns.

An AI-assisted form should make clear when suggestions are generated automatically, allow users to inspect and correct them, and avoid presenting uncertain output as fact. Personalisation should not remove important choices or create discriminatory outcomes. Automated decisions affecting access, finance, education, health, or employment require particular care, transparency, security, and appropriate human review.

Designers should consider data minimisation, purpose limitation, consent, retention, access control, and inclusive performance. The interface should not pressure users to disclose unnecessary personal information. When an automated system fails, the user needs a meaningful route to correction or human support.

Best-Practice Checklist

Before delivering an interaction design, check that:

• the primary user goal is explicit;
• the shortest successful path is understandable;
• every important control has a clear label and suitable pattern;
• required and optional information are distinguished;
• invalid input is prevented where appropriate;
• error messages explain recovery;
• loading, empty, success, failure, disabled, and offline states are designed;
• user data is preserved during errors;
• destructive actions are reversible or clearly confirmed;
• progressive disclosure does not hide important risks or costs;
• onboarding leads to meaningful value;
• keyboard, touch, screen-reader, and low-vision needs are considered;
• privacy, security, and automated decision risks are addressed;
• the flow has been tested with representative users.

Chapter Summary

Interaction design organises the relationship between user goals, actions, system states, and feedback. Task analysis decomposes goals into manageable activities, while task flows show direct routes and user flows include decisions, errors, interruptions, and alternatives. Effective interfaces make system status visible and design empty, loading, success, error, disabled, offline, and partial states deliberately.

Controls should be selected according to the decision they support, not merely their appearance. Forms should request necessary information, validate it appropriately, preserve user work, and provide constructive error recovery. Consistency, constraints, error prevention, reversibility, and progressive disclosure reduce cognitive effort while supporting safe action. Onboarding should help users reach meaningful value, and feedback should explain what happened and what to do next.

Professional interaction design also requires platform awareness, accessibility, privacy, security, and critical evaluation of new technologies. A complete flow is not the ideal path alone; it is a resilient system of states and transitions that supports users when conditions are ordinary, unexpected, or difficult.

Key Terms

Affordance: A perceived indication of how an interface element can be used.

Constraint: A limitation that prevents or reduces inappropriate actions or values.

Control: An interface element through which a user initiates or changes an action.

Error prevention: Designing to reduce the probability of mistakes before they occur.

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

Flow: A sequence of actions, decisions, and system responses leading toward an outcome.

Goal: The result a user wants to achieve.

Interface state: A condition of an interface, such as loading, empty, success, or error.

Interaction design: The design of behaviour and communication between people and digital systems.

Mapping: The understandable relationship between a control and its result.

Onboarding: Guidance that helps a new user understand and begin using a product.

Progressive disclosure: Revealing information or options as they become relevant.

Reversibility: The ability to undo, cancel, or recover from an action.

Semantic validation: Checking whether entered information makes sense in context.

System status: The current condition or progress of a digital system communicated to the user.

Task: An activity performed to achieve a goal.

Task analysis: The systematic examination of goals, actions, decisions, and conditions in a task.

Task flow: The sequence required to complete a particular task.

User flow: The possible paths a user may take through a product to achieve an outcome.

Validation: Checking whether input meets format, meaning, or business requirements.

Review Questions

Short Answer Questions

1. What is the difference between a user goal, a task, and an action?
2. Define progressive disclosure and give one example.
3. Why should a form preserve entered information after a failed submission?
4. Name four common interface states that should be designed deliberately.
5. What is the difference between a button and a link?

Long Answer Questions

1. Explain how visibility, feedback, consistency, and reversibility work together in interaction design.
2. Describe how to design a robust user flow for resetting a password, including alternative and error paths.
3. Compare checkboxes, radio buttons, switches, and select menus, and explain when each is appropriate.
4. Discuss the advantages and limitations of progressive disclosure in a complex application.
5. Explain how accessibility, privacy, and security should influence form and onboarding design.

Analytical / Application Questions

1. A food-delivery checkout asks users to enter their address, choose a delivery time, select a payment method, and confirm an order. Analyse the flow and identify at least six possible states, constraints, or recovery paths that should be designed.
2. A mobile banking application displays “Transaction complete” immediately after a transfer button is tapped, even though the server request is still processing. Evaluate the design and propose a safer interaction pattern.
3. Design a revised interaction for deleting a university assignment submission. Explain how you would use visibility, confirmation, undo, feedback, and error recovery to protect users from accidental loss.

Multiple Choice Questions with Answers

Question 1

Which sequence best represents the basic interaction cycle?

A. Goal → intention → action → system response → interpretation

B. Colour → typography → animation → export → deployment

C. Database → server → browser → printer → archive

D. Research → procurement → hiring → budgeting → reporting

Correct Answer: A. Goal → intention → action → system response → interpretation

Question 2

What is the main difference between a task flow and a user flow?

A. A task flow is visual, while a user flow is always textual.

B. A task flow focuses on one task, while a user flow can include alternatives and error paths.

C. A task flow is for developers, while a user flow is only for marketers.

D. A task flow describes colours, while a user flow describes typography.

Correct Answer: B. A task flow focuses on one task, while a user flow can include alternatives and error paths.

Question 3

Which control is most appropriate for selecting several independent interests from a list?

A. Radio buttons

B. A switch

C. Checkboxes

D. A single-action button

Correct Answer: C. Checkboxes

Question 4

Which message provides the most useful error recovery?

A. Invalid input

B. Error 402

C. Something went wrong

D. Enter a future delivery date, such as 18 October

Correct Answer: D. Enter a future delivery date, such as 18 October

Question 5

What is progressive disclosure intended primarily to do?

A. Hide all advanced features permanently

B. Present essential information first and reveal additional detail when relevant

C. Require users to complete every setting before using a product

D. Replace all labels with icons

Correct Answer: B. Present essential information first and reveal additional detail when relevant

Question 6

Which is an example of semantic validation?

A. Checking that an email contains an appropriate structure

B. Checking that a delivery date is after today

C. Checking whether a field is displayed in blue

D. Checking whether a button has rounded corners

Correct Answer: B. Checking that a delivery date is after today

Question 7

Why should a submit button enter a processing state after activation?

A. To make the page more decorative

B. To prevent or reduce duplicate submissions while the request is processing

C. To hide the result from the user

D. To eliminate the need for server-side validation

Correct Answer: B. To prevent or reduce duplicate submissions while the request is processing

Question 8

Which statement about onboarding is most accurate?

A. It should always require a long feature tour before any task can begin.

B. It should prioritise meaningful first success and request only essential information.

C. It should make marketing consent appear mandatory.

D. It should prevent users from skipping guidance.

Correct Answer: B. It should prioritise meaningful first success and request only essential information.

Question 9

Which principle is demonstrated by a date picker that prevents impossible calendar dates?

A. Constraint

B. Decorative consistency

C. Data visualisation

D. Brand positioning

Correct Answer: A. Constraint

Question 10

Why is server-side validation still necessary when client-side validation exists?

A. Client-side validation cannot be bypassed.

B. Server-side validation improves visual hierarchy only.

C. Client-side controls can be bypassed or become inconsistent with current data.

D. Server-side validation removes the need for error messages.

Correct Answer: C. Client-side controls can be bypassed or become inconsistent with current data.