User Experience, Interface and Input–Output Design

Introduction

System analysis and design is not complete when requirements have been documented or when software functions correctly. A system must also enable people to understand what it offers, make decisions, enter information accurately, recover from errors, and obtain useful results. User experience (UX), user interface (UI), and input–output design address this human dimension of information systems.

A technically correct application can still fail if users cannot find important functions, misunderstand labels, enter invalid data, or interpret reports incorrectly. Conversely, a well-designed interface can reduce training costs, improve data quality, increase adoption, and support organisational performance. This chapter explains how analysts and designers apply human–computer interaction principles to interfaces, forms, reports, dashboards, navigation, prototypes, and usability evaluation.

The subject is especially important in business applications because the interface is often the principal point of contact between users and organisational data. It therefore connects user needs, business rules, databases, security controls, accessibility requirements, and operational outcomes.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the relationship between UX, UI, usability, accessibility, and user-centred design.
2. Apply recognised HCI principles to screens, forms, navigation, reports, and dashboards.
3. Design effective input controls and validation rules.
4. Design outputs that support comprehension, comparison, and action.
5. Select suitable prototyping techniques and interpret usability evidence.
6. Analyse accessibility, ethical, security, and governance implications.
7. Evaluate an interface and recommend improvements using a structured process.

1. Foundations of User Experience and Interface Design

1.1 User experience and user interface

User experience is the user's overall perception and interaction with a product, service, or system before, during, and after use. It includes usefulness, learnability, efficiency, emotional response, trust, accessibility, and support. UX is broader than screen appearance; it includes workflows, policies, notifications, help, and recovery from failure.

User interface is the set of visible, audible, and interactive elements through which a person communicates with a system. Examples include menus, buttons, fields, icons, tables, voice prompts, gestures, and feedback messages. UI is consequently one important component of UX, not a synonym for it.

Usability concerns whether specified users can achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use. A usable system helps users complete meaningful tasks correctly without unnecessary effort.

Accessibility means that people with diverse abilities can perceive, operate, understand, and interact with the system. Accessibility benefits users with permanent disabilities as well as those affected by temporary or situational limitations, such as a broken arm, poor lighting, or noisy surroundings.

1.2 The human-centred design perspective

Human-centred design begins with users, their goals, their tasks, and their environment rather than with available technology. The process is iterative:

1. Understand users and context.
2. Specify user and organisational requirements.
3. Produce design solutions.
4. Evaluate those solutions.
5. Refine the design and repeat.

This process differs from simply asking users what screens they want. Users may describe current procedures rather than underlying goals. Analysts must observe work, identify constraints, and distinguish essential requirements from habitual but inefficient practices.

A useful conceptual model is:

Figure: Iterative human-centred design cycle.

1.3 Usability dimensions

The following dimensions help analysts evaluate a design:

These dimensions can conflict. A system may maximise security with additional authentication steps, or maximise flexibility at the cost of learnability. Design decisions should therefore be based on task importance, risk, user capabilities, and evidence rather than on visual preference alone.

2. Principles and Models for Interface Design

2.1 Foundational principles

Several principles provide a practical basis for design reviews.

Visibility of system status. The system should communicate what is happening through progress indicators, confirmations, saved-state information, and meaningful status labels. A payment screen should not leave a user uncertain whether a transaction succeeded.

Match between system and real world. Labels, sequence, and terminology should reflect users' language and work practices. A medical system should use clinically recognised terms where appropriate, while explaining specialised terms to non-specialists.

Consistency and standards. Similar controls should look and behave similarly. Platform conventions should be respected unless there is a compelling reason to depart from them.

Recognition rather than recall. Menus, examples, visible options, and recently used items reduce memory demands. Users should not have to remember a code that the system could display.

User control and freedom. Users need cancel, undo, back, and safe exit options. Irreversible actions require clear warnings and, where feasible, recovery mechanisms.

Error prevention and recovery. Prevent errors through appropriate defaults, constraints, input masks, and clear choices. When errors occur, explain what happened, identify the affected field, and state how to correct it.

Flexibility and efficiency. Novices need discoverable workflows; experienced users may benefit from keyboard shortcuts, bulk actions, and customisation. These modes should not create inconsistent results.

Aesthetic and minimalist design. Every displayed element competes for attention. Remove information that does not support the current task, but do not hide information needed for informed decisions.

Help and documentation. Help should be searchable, contextual, task-oriented, and written in user language. Good design reduces dependence on help but does not eliminate it.

2.2 Mental models and conceptual models

A user's mental model is the person's understanding of how a system works. A conceptual model is the explanation embodied by the design. Conflicts between the two cause errors and frustration. For example, a shopping cart metaphor suggests that users can review, change, and remove items before checkout. If a system immediately creates an irreversible order, its conceptual model violates users' expectations.

Analysts should identify users' existing models during interviews and observation. Designers can then use familiar metaphors carefully; metaphors aid learning but may become misleading when the system's capabilities differ from the physical object.

2.3 Feedback, affordance, and mapping

Feedback is information about the result of an action. A button should visibly change when selected, and a successful save should be distinguishable from a failed save. Affordance refers to cues about possible actions; a control that looks clickable should behave as a clickable control. Mapping concerns the relationship between controls and their effects. For instance, the ordering of temperature controls should correspond logically to increasing and decreasing values.

3. User Research and Requirements for UX

Interface requirements originate from more than stakeholder opinions. Useful evidence includes interviews, contextual observation, task analysis, existing forms, support logs, analytics, accessibility reviews, and usability tests.

A persona is a research-informed representation of a significant user group. It should include goals, tasks, expertise, constraints, and environment, not merely demographic decoration. A scenario describes a user, context, goal, and sequence of events. A journey map shows stages of an experience and associated needs, problems, and emotions.

Task analysis decomposes a goal into actions, decisions, inputs, system responses, exceptions, and completion criteria. It reveals where a form asks for information that is unavailable, where users repeat data, and where an apparently simple task contains hidden complexity.

Requirements should be testable. “The interface should be user friendly” is vague. “A first-time employee should submit a leave request without assistance and receive confirmation” is more useful, although it should still specify the task conditions and acceptable success criteria.

4. Input Design

Input design determines how users provide data and how the system validates, stores, and acknowledges it. Poor input design increases correction work and contaminates databases; good input design improves both usability and information quality.

4.1 Input control selection

Use controls according to the data and decision structure:

A field should have a visible label, an adequate input area, an indication of required status, and instructions when the expected format is not obvious. Placeholder text is not a replacement for a label because it disappears during entry and may have insufficient contrast.

4.2 Forms and layout

Forms should follow the user's work sequence, not the database table structure. Group related fields, use meaningful headings, align labels consistently, and place primary actions where users expect them. If a form is long, divide it into logical steps and show progress; avoid unnecessary multi-page sequences for short tasks.

Defaults can reduce effort, but a default must be safe and genuinely likely. A preselected option can cause harm when users accept it without noticing. Clearly distinguish system-generated values from user-entered values.

4.3 Validation and data quality

Validation may occur at several levels:

• Format validation: checks syntax, such as a date structure.
• Range validation: checks whether a value lies within an allowed interval.
• Presence validation: checks required information.
• Consistency validation: compares related fields, such as ensuring an end date is not earlier than a start date.
• Referential or business validation: checks rules against other records or policies.

Validation should occur as early as practical without interrupting users excessively. Inline validation is useful after a user has completed a field, while server-side validation remains essential because client-side checks can be bypassed.

Error messages should be specific, respectful, and actionable. “Invalid input” is weak. “Enter a delivery date from tomorrow through 30 June 2026” explains the problem and remedy. Do not erase valid entries merely because one field is wrong.

4.4 Input security and privacy

Input design must address malicious as well as accidental input. Server-side validation, parameterised database queries, output encoding, appropriate file restrictions, rate limits, and authentication controls are technical safeguards. The interface should not expose sensitive information unnecessarily, and it should not reveal whether an account exists when that disclosure creates security risk.

Data minimisation is also a UX principle. Collect only information required for a stated purpose, explain that purpose, and provide appropriate consent and retention information. Sensitive fields should support privacy-preserving display, such as masking a payment identifier while allowing the user to verify its last digits.

5. Output Design: Reports, Screens, and Dashboards

Output design transforms stored data into information that supports a task or decision. The first question is not “Which chart should be used?” but “What decision must the user make, and what evidence is needed?”

5.1 Characteristics of effective outputs

An output should be accurate, relevant, timely, understandable, appropriately detailed, and traceable to its source. It should make important exceptions visible without creating alarm through decoration or inappropriate colour.

Reports are often designed for recurring operational or managerial needs. A report specification should identify audience, purpose, data source, frequency, filters, grouping, sorting, calculations, access restrictions, and delivery format. It should distinguish current values from historical comparisons and clearly identify units, dates, and time zones.

5.2 Tables and visualisations

Tables support exact lookup and comparison. Use aligned numeric columns, consistent decimal precision, meaningful totals, and sortable headings where interaction is available. Avoid excessive borders and unexplained abbreviations.

Charts support pattern recognition. Choose a chart according to the analytical task:

Charts must include titles, labels, units, legends where needed, and an explanatory context. Colour should not be the only means of encoding a distinction; use labels, patterns, symbols, or position as alternatives. Three-dimensional effects and decorative backgrounds commonly reduce accuracy.

5.3 Dashboard design

A dashboard is a coordinated view of key measures intended for monitoring, exploration, or action. Dashboards should have a defined audience and decision purpose. A senior manager may need trends, exceptions, and strategic indicators; a service supervisor may need queue status and overdue cases.

A good dashboard establishes hierarchy: headline indicators first, trends and comparisons next, and diagnostic detail available through drill-down. It should identify the time period, data freshness, target or benchmark, and responsible interpretation. A large number of metrics can create attention fragmentation rather than insight.

6. Navigation and Interaction Architecture

Navigation is the structure through which users move among functions and information. It should reflect user goals and task relationships rather than internal organisational departments alone.

Common patterns include global navigation for major areas, local navigation for a section, breadcrumbs for location, tabs for peer views, search for direct access, and progressive disclosure for advanced options. The system should show the user's current location and preserve context when moving between related screens.

Navigation labels should be concrete and familiar. “Manage” may be less informative than “Approve invoices” or “Edit profile.” Avoid deep hierarchies, inconsistent back behaviour, and links that unexpectedly open different environments. On mobile devices, navigation must account for limited space, touch targets, orientation changes, and intermittent connectivity.

7. Accessibility and Inclusive Design

Accessibility should be integrated at requirements, design, development, and testing stages. It is not a final cosmetic check. Important practices include:

• Provide text alternatives for meaningful non-text content.
• Ensure keyboard operation and visible focus indicators.
• Use sufficient contrast and do not rely on colour alone.
• Associate labels, instructions, and error messages with their controls.
• Use semantic structure and meaningful heading order.
• Support resizing, zoom, and reflow where applicable.
• Provide captions and transcripts for multimedia.
• Avoid flashing content and time limits that cannot be extended.
• Write plain, comprehensible language and support translation where required.

Accessibility standards and legal duties vary by jurisdiction and sector. Organisations should identify applicable laws, procurement requirements, and recognised standards, such as the Web Content Accessibility Guidelines, while recognising that conformance does not guarantee excellent usability for every person.

Inclusive design also considers language, literacy, culture, age, device ownership, bandwidth, and assistive technology. A system that works only with a fast connection or a modern large screen may exclude legitimate users even if it passes a narrow technical accessibility test.

8. Prototyping and Design Communication

A prototype is a representation of a proposed system used to explore requirements, communicate design, and obtain feedback. Prototypes may be:

• Paper sketches: fast and inexpensive, useful for early structure.
• Wireframes: focus on layout, hierarchy, and interaction without visual polish.
• High-fidelity prototypes: resemble the final interface and support realistic testing.
• Coded prototypes: test technical behaviour, performance, or integration risks.

The appropriate fidelity depends on the question. A high-fidelity prototype can distract stakeholders with colours and branding when the real issue is workflow. A paper prototype may be inadequate for testing animation, responsive behaviour, or accessibility semantics.

Prototype annotations should identify states, transitions, validation, data assumptions, and unresolved decisions. Designers should record feedback systematically rather than allowing the loudest stakeholder to determine the result. A design decision log can document alternatives, evidence, trade-offs, and approval.

9. Usability Evaluation

Evaluation should occur repeatedly, beginning before implementation. Two major approaches are complementary.

Inspection methods involve experts examining an interface against principles or standards. Heuristic evaluation is relatively fast and can identify consistency, feedback, navigation, and error problems. It may miss domain-specific issues and does not substitute for observing real users.

User-based methods involve representative participants performing realistic tasks. Moderated testing allows probing and observation; unmoderated testing can reach more participants efficiently. Interviews and questionnaires capture perceptions, while analytics reveal behaviour at scale. A/B testing can compare alternatives under controlled conditions, but it requires adequate traffic, a well-defined outcome, and ethical treatment of participants.

A usability test plan should specify:

1. Evaluation questions.
2. Target users and recruitment criteria.
3. Tasks and realistic scenarios.
4. Measures and observation procedure.
5. Consent, privacy, and data handling.
6. Success criteria and reporting method.

Useful measures include task completion, critical errors, assistance requests, time on task, abandonment, and satisfaction. A basic task-completion proportion can be calculated as:

This measure assumes that tasks have been defined consistently and that “successful” has an explicit criterion. It does not by itself measure efficiency, satisfaction, or the severity of partial failures.

For example, if 18 of 24 participants complete a task successfully, the completion rate is (18 ÷ 24) × 100% = 75%. The analyst should still investigate why six participants failed and whether the failures affected safety or business outcomes.

Findings should be prioritised by severity, frequency, user impact, and remediation cost. A minor wording issue may affect many users; a rare payment error may have high severity. Recommendations should identify the evidence, proposed change, owner, and verification method.

10. Detailed Applied Case: University Course Registration

The following is an illustrative case, not a report of a real institution.

Background

A university introduces an online course-registration system. Students must select courses, check prerequisites, resolve timetable conflicts, and submit registration. The initial system mirrors the underlying database and presents a long form containing course codes, departmental abbreviations, and separate screens for conflicts.

Problem

Students report that they cannot tell whether a course has been added, frequently miss prerequisite warnings, and submit duplicate requests. Advisers receive many support calls. Students using mobile devices experience horizontal scrolling, and keyboard-only users cannot reach some controls.

Analysis

Observation and support-log analysis identify four central tasks: finding a suitable course, evaluating eligibility, comparing schedules, and confirming enrolment. The existing design is organised around database entities rather than these tasks. Warnings appear at the top of the page rather than beside the relevant course. The success message disappears after navigation, and the system uses colour alone to indicate conflicts.

Approach and solution

The design team creates personas for first-year students, returning students, advisers, and accessibility users. A task model leads to a three-stage workflow:

1. Explore: search by course title, subject, level, time, and delivery mode.
2. Review: display prerequisites, available seats, timetable conflicts, and workload together.
3. Confirm: show a final summary, registration consequences, and a clear submission action.

The revised interface uses plain-language labels, visible selected-course status, text and icon indicators for conflicts, keyboard-accessible controls, responsive tables, and contextual messages adjacent to affected courses. It prevents duplicate selection and asks for confirmation only when the action creates a formal registration.

A low-fidelity prototype is tested first to validate task order. A high-fidelity prototype then tests responsive behaviour and keyboard navigation. Participants complete realistic scenarios, such as finding a laboratory course available on Tuesday afternoon. Findings lead to improved search filters and a more prominent explanation of prerequisite exceptions.

Outcome

In a pilot evaluation, the redesigned workflow produces fewer duplicate selections and fewer requests for adviser assistance. The result is not attributed merely to visual redesign; it follows from aligning the interface with user goals, improving feedback, and exposing relevant constraints at the point of decision. The institution also establishes an accessibility review and a process for monitoring post-release errors.

Learning points

The case demonstrates that input, output, navigation, accessibility, and business rules must be designed together. It also shows why testing a realistic task is more informative than asking users whether they “like” a screen.

11. Professional, Ethical, and Contemporary Considerations

Interface decisions can influence behaviour and power. Dark patterns are designs that manipulate users into actions they may not intend, such as making consent easy but withdrawal difficult, disguising advertising as content, or adding unwanted items. Ethical design requires transparency, meaningful choice, and respect for autonomy.

Privacy notices should be understandable and presented at relevant moments. Consent should not be bundled deceptively with unrelated actions. Systems handling health, financial, educational, or employment data require strong access control, auditability, retention management, and careful disclosure.

Artificial intelligence can support adaptive help, natural-language search, summarisation, and personalised recommendations. However, AI interfaces can produce incorrect or biased outputs, obscure responsibility, expose confidential prompts, or encourage overreliance. AI-generated recommendations should show relevant explanations or evidence where decisions are consequential, allow human review, and provide a clear correction or appeal path. Personalisation should not remove user control or make essential functions unpredictable.

Contemporary design increasingly addresses multimodal interaction, voice interfaces, conversational agents, wearable devices, responsive layouts, and offline-capable applications. Each modality introduces new concerns: voice systems may expose private information; conversational systems may create ambiguity; wearable displays may overload attention; and offline systems must communicate synchronisation status. The underlying principles remain stable: clarity, feedback, control, accessibility, security, and evaluation in context.

12. Best-Practice Design Process

A practical process for system analysts is:

1. Identify user groups, goals, environments, constraints, and risks.
2. Observe real work and document tasks, exceptions, and terminology.
3. Define testable UX and accessibility requirements.
4. Establish information architecture, navigation, and content hierarchy.
5. Design input and output around decisions and workflows.
6. Prototype early at the lowest fidelity that answers the current question.
7. Evaluate with experts and representative users.
8. Resolve critical usability, accessibility, privacy, and security issues.
9. Test realistic data, devices, assistive technologies, and failure conditions.
10. Monitor post-release evidence and iterate.

Design systems, reusable components, naming conventions, and accessibility patterns improve consistency across applications. Nevertheless, reuse must not become an excuse to force every task into an unsuitable template. Standards provide a foundation; evidence and context determine the final design.

Challenges and Limitations

UX design is constrained by time, budget, legacy technology, regulation, organisational politics, and conflicting stakeholder goals. Representative recruitment can be difficult, and laboratory tests may not reproduce workplace interruptions or stress. Metrics can also be misleading: faster completion is not desirable if users make more serious errors, and satisfaction may reflect familiarity rather than quality.

Accessibility cannot be guaranteed by automated tools alone. Automated checks can detect some structural problems, but human review and testing with disabled users remain important. Similarly, a prototype may hide performance, integration, and data-quality problems. Analysts should state the limits of evidence and avoid treating any single test as proof of universal usability.

Chapter Summary

UX concerns the complete experience of using a system, while UI concerns the interactive means through which that experience is delivered. Usability evaluates effectiveness, efficiency, learnability, error tolerance, and satisfaction; accessibility ensures that people with diverse abilities can perceive, operate, and understand the system.

Human-centred design is iterative: analysts understand context, specify needs, design solutions, evaluate them, and refine the result. Core principles include visibility of status, consistency, recognition over recall, user control, error prevention, useful feedback, and correspondence with users' real-world models.

Input design should organise forms around user tasks, select suitable controls, validate data at appropriate levels, and provide actionable errors. Output design should support decisions through accurate reports, understandable tables, meaningful visualisations, and focused dashboards. Navigation should expose location and preserve context. Prototyping makes design assumptions visible, while inspection and user-based evaluation provide complementary evidence.

Professional practice also requires accessibility, privacy, security, ethical choice architecture, and responsible use of AI. Successful interface design is therefore not decoration; it is a disciplined activity connecting human goals, organisational rules, information quality, and system performance.

Key Terms

User experience (UX): The overall experience and perception of using a product, service, or system.

User interface (UI): The interactive visual, auditory, or tactile means through which users communicate with a system.

Usability: The effectiveness, efficiency, and satisfaction with which specified users achieve specified goals.

Accessibility: The ability of people with diverse abilities to perceive, operate, understand, and interact with a system.

Human-centred design: An iterative design approach based on users, context, requirements, solutions, and evaluation.

Persona: A research-informed representation of a significant user group.

Scenario: A description of a user, context, goal, and sequence of activity.

Task analysis: Decomposition of a goal into actions, decisions, inputs, outputs, and exceptions.

Affordance: A cue indicating how an interface element may be used.

Feedback: Information provided by a system about the result or status of an action.

Wireframe: A low-detail representation of interface structure and layout.

Prototype: A representation used to explore, communicate, or evaluate a proposed design.

Validation: Checking whether entered data satisfies format, range, presence, consistency, or business rules.

Dashboard: A coordinated display of measures supporting monitoring, analysis, or action.

Information architecture: The organisation and labelling of content and functions.

Heuristic evaluation: Expert inspection of an interface against recognised usability principles.

Dark pattern: A manipulative interface design that steers users toward unintended or disadvantageous actions.

Progressive disclosure: Revealing advanced or secondary information only when it is needed.

Design system: A maintained collection of reusable interface components, rules, and guidance.

Review Questions

Short Answer Questions

1. Distinguish between user experience, user interface, usability, and accessibility.
2. State four principles that help prevent input errors.
3. Why should a dashboard have a defined audience and decision purpose?
4. What is the difference between a wireframe and a high-fidelity prototype?
5. Explain why automated accessibility testing is insufficient by itself.

Long Answer Questions

1. Explain the human-centred design cycle and show how it can be applied to a business information system.
2. Discuss the principles of effective form and input design, including control selection, validation, feedback, and privacy.
3. Compare tables, charts, reports, and dashboards as forms of system output.
4. Explain how usability testing should be planned, conducted, measured, and reported.
5. Discuss the ethical, accessibility, security, and governance responsibilities of an interface designer.

Analytical / Application Questions

1. A hospital appointment form asks patients to enter a department code, appointment type, and date in separate screens. Analyse likely usability and accessibility problems and propose a redesigned workflow.
2. A sales dashboard shows twelve brightly coloured indicators but does not state data freshness, targets, or responsible actions. Evaluate the design and recommend specific improvements.
3. In a usability test, 18 of 24 participants complete a task successfully, but two of the six failures involve submitting incorrect financial information. Interpret the result and recommend the next evaluation and design actions.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes UX from UI?

A. UX concerns only visual appearance, while UI concerns database structure.

B. UX is the overall experience, while UI is the interactive means through which users communicate with a system.

C. UX applies only to mobile systems, while UI applies only to desktop systems.

D. UX is a testing method, while UI is a programming language.

Correct Answer: B. UX is the overall experience, while UI is the interactive means through which users communicate with a system.

Question 2

Which design principle reduces the need for users to remember information?

A. Recognition rather than recall

B. Aesthetic minimalism

C. Irreversible actions

D. Hidden navigation

Correct Answer: A. Recognition rather than recall

Question 3

Which control is generally most suitable for selecting several options from a list?

A. Radio buttons

B. A single-select dropdown

C. Checkboxes

D. A progress bar

Correct Answer: C. Checkboxes

Question 4

Which validation checks that an end date is not earlier than a start date?

A. Format validation

B. Presence validation

C. Consistency validation

D. Colour validation

Correct Answer: C. Consistency validation

Question 5

What is the primary purpose of a dashboard?

A. To reproduce every database field

B. To support monitoring, analysis, or action through coordinated measures

C. To replace all transaction forms

D. To hide detailed information from authorised users

Correct Answer: B. To support monitoring, analysis, or action through coordinated measures

Question 6

Which display is generally most suitable for showing a trend over time?

A. Line chart

B. Unlabelled icon grid

C. Pie chart with dozens of slices

D. Randomly ordered word list

Correct Answer: A. Line chart

Question 7

What is a major limitation of heuristic evaluation?

A. It cannot be performed before implementation.

B. It always requires thousands of users.

C. It may miss domain-specific problems that appear when real users perform tasks.

D. It measures database storage rather than interface quality.

Correct Answer: C. It may miss domain-specific problems that appear when real users perform tasks.

Question 8

If 18 of 24 participants complete a task successfully, what is the completion rate?

A. 60%

B. 70%

C. 75%

D. 80%

Correct Answer: C. 75%

Question 9

Which practice best supports accessibility?

A. Using colour as the only indicator of status

B. Removing visible keyboard focus to simplify the layout

C. Providing labels, keyboard operation, and non-colour alternatives

D. Replacing all text with icons

Correct Answer: C. Providing labels, keyboard operation, and non-colour alternatives

Question 10

Which statement about AI-supported interfaces is most responsible?

A. AI outputs never need human review if the interface looks clear.

B. AI should be used without explaining recommendations in consequential decisions.

C. AI can assist interaction but requires attention to error, bias, privacy, responsibility, and user control.

D. AI eliminates the need for usability evaluation.

Correct Answer: C. AI can assist interaction but requires attention to error, bias, privacy, responsibility, and user control.