Mobile Application Development

Chapter 4
User Interface, User Experience and Accessibility

Bachelors Program in IT
Mobile Application Development   •   Bachelor

User Interface, User Experience and Accessibility

Introduction

Mobile applications are experienced through interfaces, but successful applications are not defined by visual appearance alone. They must help people understand available actions, complete tasks efficiently, recover from errors, and use the product in varied physical, sensory, cognitive, and technological conditions. User interface (UI) concerns the visible and interactive elements of an application; user experience (UX) concerns the broader quality of the user’s interaction before, during, and after use; accessibility concerns whether people with diverse abilities can perceive, operate, understand, and contribute to that experience.

For mobile developers, these concerns are engineering responsibilities as well as design responsibilities. A visually attractive screen can still be unusable if controls are too small, feedback is absent, content is unreadable, or navigation changes unpredictably. Conversely, a simple interface can be highly effective when it reflects user goals, platform conventions, and inclusive design principles.

This chapter presents methods for designing responsive and adaptive mobile interfaces, using component systems, typography, gestures, feedback, wireframes, prototypes, and inclusive interaction flows. It also considers evaluation, ethics, platform guidance, and the practical relationship between design and implementation.

Learning Objectives

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

  1. Distinguish UI, UX, usability, and accessibility.
  2. Apply user-centred and human-centred design principles to mobile applications.
  3. Design responsive and adaptive layouts for different devices, orientations, and input conditions.
  4. Use platform guidelines, component systems, typography, colour, gestures, and feedback appropriately.
  5. Produce wireframes, prototypes, and inclusive interaction flows.
  6. Identify accessibility barriers and propose technically feasible remedies.
  7. Evaluate an interface using usability principles and accessibility requirements.
  8. Analyse the professional, ethical, and regulatory implications of interface decisions.

1. Foundational Concepts

1.1 User interface and user experience

A user interface is the set of visual, auditory, and tactile means through which a person interacts with software. It includes screens, navigation, buttons, text fields, icons, menus, transitions, notifications, and system status information.

User experience is broader. It includes the user’s expectations, emotions, perceived effort, confidence, task success, and continuing relationship with the product. UX begins before the application is opened—for example, when a user reads its description—and continues after an interaction, such as receiving confirmation that a payment succeeded.

Usability is a quality dimension of UX. A usable system enables intended users to achieve intended goals effectively, efficiently, and satisfactorily in a specified context. Accessibility extends this concern by requiring that people with disabilities are not excluded from equivalent use.

These concepts overlap but are not interchangeable:

ConceptCentral question
UIWhat interaction elements does the user perceive and operate?
UXWhat is the overall quality and meaning of the interaction?
UsabilityCan users achieve goals accurately and efficiently?
AccessibilityCan users with diverse abilities use the system meaningfully?

1.2 Human-centred design

Human-centred design treats users, their goals, and their contexts as primary sources of design knowledge. A typical cycle is:

  1. Understand users, tasks, environments, and constraints.
  2. Specify user and system requirements.
  3. Generate alternative solutions.
  4. Prototype selected solutions.
  5. Evaluate them with users and evidence.
  6. Iterate based on findings.

This process is iterative rather than strictly linear. Research can reveal that the original problem was incorrectly framed, while usability testing can expose an interaction failure that requires revising requirements.

A useful requirement is expressed in terms of user value. “The app shall include a blue button” is an implementation detail. “A returning customer shall be able to repeat a previous order without re-entering delivery information” expresses a goal that can support several valid designs.

1.3 Mental models and affordances

A mental model is a user’s understanding of how a system works. Designers should align the system image—the visible interface—with familiar concepts where appropriate. A shopping basket, search magnifier, and back navigation are effective partly because users have encountered related conventions elsewhere.

An affordance is a possibility for action; a signifier communicates that possibility. A raised, labelled button signals that it can be pressed. A text field with a cursor indicates that it accepts input. Poorly labelled icons provide weak signifiers and force users to guess.

Consistency supports learning. It includes consistent placement, terminology, behaviour, visual hierarchy, and response to similar actions. Consistency does not mean that every screen must look identical; it means that differences are meaningful and predictable.

2. Usability Principles for Mobile Applications

Several principles are especially important in mobile contexts.

Visibility of system status

The application should communicate what is happening. Examples include loading indicators, upload progress, connection state, and confirmation of a completed action. A blank screen after tapping “Pay” creates uncertainty and may cause duplicate transactions.

Match between system and real world

Use language and concepts familiar to the target audience. A finance application may use “available balance” and “pending transaction,” while a technical database term may confuse users.

User control and freedom

Users need back navigation, cancellation, undo, and safe exit paths. Destructive actions should be reversible where feasible and should require appropriate confirmation.

Error prevention and recovery

Prevent errors through constraints, sensible defaults, validation, and clear input formats. When an error occurs, explain what happened, identify the affected field, and state how to correct it. “Invalid input” is less useful than “Enter a phone number with 10 digits.”

Recognition rather than recall

Expose relevant choices and information instead of requiring users to remember it from another screen. Autofill, recent items, visible labels, and contextual help reduce memory demands.

Flexibility and efficiency

Novice users may need guidance, while experienced users benefit from shortcuts, saved preferences, and efficient repeated actions. The same task should not be made unnecessarily slow for expert users merely to simplify the first-use experience.

Aesthetic and minimalist design

Every element competes for limited screen space and attention. Minimalism means removing irrelevant complexity, not removing necessary explanations or accessibility information.

Help and documentation

Good interfaces reduce the need for help, but complex tasks still require guidance. Help should be searchable, contextual, concise, and written in the user’s vocabulary.

3. Responsive and Adaptive Interface Design

A responsive interface changes layout fluidly as available space changes. An adaptive interface selects among intentional layouts or behaviours for particular conditions, such as compact and expanded screens, portrait and landscape orientation, keyboard presence, or tablet use.

A robust mobile layout should account for:

  • screen width, height, and aspect ratio;
  • system bars, cut-outs, and safe areas;
  • text scaling and display zoom;
  • orientation changes;
  • touch, keyboard, stylus, switch, and screen-reader input;
  • network quality and performance;
  • one-handed and two-handed use;
  • foldable or multi-window configurations.

Responsive design should avoid absolute positioning for content that must grow. Flexible containers, constraints, scalable dimensions, wrapping text, and content-aware spacing are preferable. Developers should test the smallest supported viewport and unusually large text, not only the device used during development.

Breakpoints and layout modes

A breakpoint is a condition at which the composition changes. For example, a single-column product page may become a two-column layout when enough horizontal space exists. Breakpoints should be based on content requirements rather than device brand names. A layout changes when its hierarchy, readability, or interaction quality would otherwise deteriorate.

Adaptive behaviour must preserve task continuity. If a user rotates the device, entered data should not disappear. If a window becomes narrower, secondary content may move below the primary task rather than being silently removed.

Information hierarchy

Visual hierarchy communicates importance through position, size, contrast, spacing, and grouping. A primary action should be distinguishable from secondary actions, but it should not dominate so strongly that users overlook warnings or required information. Grouping related controls and separating unrelated groups reduces cognitive effort.

4. Component Systems and Platform Guidelines

A component system is a reusable collection of interface elements, design rules, states, and implementation guidance. Typical components include buttons, navigation bars, cards, dialogs, lists, tabs, switches, fields, banners, and progress indicators.

A mature component is more than a visual rectangle. Its specification should define:

  • purpose and appropriate use;
  • content and terminology;
  • dimensions and spacing;
  • default, focused, pressed, disabled, loading, error, and success states;
  • keyboard, screen-reader, and other assistive behaviour;
  • motion and transition behaviour;
  • responsive variations;
  • implementation and testing requirements.

Design systems improve consistency, reduce duplicated work, and make changes scalable. However, blindly assembling components can produce a generic or inappropriate experience. Components must still be selected according to user goals and task context.

Platform guidelines provide conventions for navigation, touch behaviour, system integration, permissions, notifications, typography, and accessibility. They are not absolute laws: a safety-critical or domain-specific application may require a different pattern. Nevertheless, departures should be deliberate, tested, and justified by user needs rather than personal preference.

5. Typography, Colour, and Visual Communication

Typography strongly affects comprehension. Designers should select readable typefaces, establish a clear hierarchy, use adequate line spacing, and avoid long lines or dense blocks on small screens. Text should remain meaningful when enlarged. Fixed-height containers that clip enlarged text are accessibility failures.

Labels should be concise but specific. “Continue” may be acceptable in a linear flow, whereas “Continue to payment” communicates the result more clearly. Placeholder text is not a substitute for a persistent label because it disappears when the user types.

Colour can reinforce hierarchy and status, but it must not be the only carrier of meaning. An error should use text, an icon or pattern, and appropriate semantic labelling in addition to colour. Colour combinations should provide sufficient contrast under expected conditions, while designers should also consider glare, low brightness, colour-vision differences, and dark mode.

Icons should be familiar, visually distinct, and accompanied by labels when their meaning is uncertain. Decorative images should not be announced unnecessarily by assistive technologies; informative images need meaningful alternative descriptions.

6. Touch, Gestures, and Feedback

Touch interaction is direct but imprecise. Controls need sufficient target area and separation to reduce accidental activation. The visible icon may be smaller than the interactive region, provided the surrounding area does not create ambiguity.

Gestures such as swipe, drag, pinch, and long press can be efficient, but essential actions should not depend exclusively on gestures. A user may have motor limitations, may not know the gesture, or may be using an alternative input device. Provide visible alternatives and ensure that gesture actions do not conflict with system navigation or assistive technology.

Feedback should be immediate, relevant, and proportional. Examples include:

  • visual pressed states for buttons;
  • vibration for selected confirmations, where appropriate;
  • inline validation after field completion;
  • progress information for lengthy operations;
  • confirmation banners after successful actions;
  • clear error messages with recovery instructions.

Motion can communicate continuity and spatial relationships, but excessive animation causes distraction, discomfort, or cognitive overload. Respect operating-system preferences for reduced motion and avoid animation that delays essential interaction.

7. Accessibility and Inclusive Design

Accessibility is not a specialised feature added at the end. It is a quality requirement that should influence information architecture, component selection, content, code, and testing from the beginning.

Important accessibility dimensions include:

  • Perceivable: information is available through appropriate visual, auditory, or tactile channels.
  • Operable: controls work with different input methods and do not require impossible precision or timing.
  • Understandable: language, navigation, and error recovery are predictable.
  • Robust: content works with operating systems, browsers, assistive technologies, and future implementations.

These principles are consistent with widely used accessibility guidance, including the Web Content Accessibility Guidelines, although mobile-native platforms also provide their own accessibility APIs and conventions.

Common implementation practices

  1. Use semantic controls rather than drawing controls that lack accessibility behaviour.
  2. Give controls accessible names that describe purpose, not appearance alone.
  3. Preserve logical focus order.
  4. Ensure that focus is visible and not hidden behind overlays.
  5. Expose state, value, role, and relationships to assistive technologies.
  6. Support dynamic text size without clipping or overlap.
  7. Provide alternatives to colour, sound, and complex gestures.
  8. Avoid content that flashes or requires precise timing.
  9. Announce important asynchronous changes appropriately, without excessive interruption.
  10. Test with screen readers, magnification, switch access, voice control, keyboard input, and platform settings.

Accessibility testing should involve disabled users where possible. Automated tools are useful for detecting missing labels, contrast problems, and structural defects, but they cannot determine whether a task is understandable or whether a description is genuinely useful.

8. Wireframes, Prototypes, and Interaction Flows

A wireframe is a simplified representation of screen structure. It focuses on content hierarchy, navigation, controls, and states rather than final colour and decoration. Low-fidelity wireframes are inexpensive and encourage discussion of structure before implementation effort is invested.

A prototype is an executable or simulated representation of an interaction. Prototypes range from paper sketches to high-fidelity interactive models. They should answer a question: Can users find the main action? Does the navigation model make sense? Is the checkout flow safe? A prototype that does not address a design uncertainty is merely a presentation.

An interaction flow describes states and transitions. It should include normal, empty, loading, error, permission-denied, offline, and success conditions. For example, a document-upload flow may contain:

  1. Select document.
  2. Validate file type and size.
  3. Show upload progress.
  4. Handle interruption or retry.
  5. Confirm successful upload.
  6. Provide access to the uploaded document.

Designers should map the user’s goal, system response, and recovery option at each step. This prevents “happy path” prototypes from concealing practical failures.

Usability evaluation

A usability study should define participants, tasks, context, and evidence before testing. Useful measures include task completion, errors, time, assistance required, and qualitative confidence. A completion percentage can be calculated as:

Completion rate = (number of participants who complete the task ÷ total participants) × 100%

This measure assumes that completion criteria are defined consistently. It does not by itself explain why users failed, whether the sample represents the target population, or whether the task was ethically appropriate. Qualitative observation and participant feedback remain essential.

Heuristic evaluation is an expert inspection against principles such as visibility, consistency, error prevention, and recovery. It is efficient for finding obvious problems but should complement, not replace, user testing.

9. Applied Case: An Inclusive Campus Travel Application

Background

This illustrative case concerns a mobile application that helps university students plan travel between campus buildings. The initial concept displayed a map, estimated walking time, and a “Start route” button.

Problem

Early testing showed that users in wheelchairs were directed toward stairs, screen-reader users could not understand map markers, and students with limited connectivity saw no route after entering a building. Some users also missed the route-start action because it moved when an advertisement appeared.

Analysis

The team examined user goals, environmental constraints, and failure states. The application had treated the map as the primary interface, although the real goal was to choose a safe and practical route. It also assumed visual perception, continuous connectivity, and precise touch input.

Approach and solution

The redesigned flow began with two clearly labelled fields: origin and destination. Users could select route preferences such as step-free access, lower slope, indoor segments, and lighting. The result screen provided a text-based sequence of landmarks in addition to the map. Each route instruction had an accessible name and could be read aloud.

The team introduced a stable primary action, larger touch targets, visible focus, dynamic text support, and alternative route descriptions. Routes were cached for common campus areas, while unavailable data produced an explicit offline message. Permission requests for location were delayed until the feature was relevant and were explained in plain language.

Testing included sighted users, screen-reader users, wheelchair users, and users with temporary injuries. The team tested both normal and degraded network conditions.

Outcome

The revised design reduced confusion during route selection and enabled users to complete the core task without relying on the map. More importantly, accessibility improvements also benefited many non-disabled users: text instructions were useful in bright sunlight, route preferences reduced cognitive load, and offline support helped in buildings with poor reception.

Learning points

The case demonstrates that accessibility is closely connected to usability. It also shows why designers should identify the underlying task, offer equivalent modes of access, design failure states, and involve affected users before implementation is considered complete.

10. Professional, Ethical, and Contemporary Considerations

Interface design can manipulate behaviour. Dark patterns include hidden costs, confusing cancellation flows, forced continuity, misleading button hierarchy, and consent interfaces that favour the organisation over the user. Professionals should distinguish persuasive design that supports user goals from coercive design that exploits inattention or vulnerability.

Privacy is also an interface issue. Permission prompts should explain purpose, timing, and consequences. Users should be able to review and withdraw permissions where technically possible. Sensitive information should not be exposed in notifications, screenshots, logs, or accessibility announcements without appropriate safeguards.

Regulatory obligations vary by jurisdiction and sector. Public services, education, finance, health, and employment applications may have specific accessibility, privacy, consumer-protection, or record-keeping requirements. Compliance is a baseline, not a substitute for responsible design.

Artificial intelligence is increasingly used for interface generation, personalisation, speech interaction, image description, and predictive assistance. These applications require critical oversight. Generated content may be inaccurate, biased, inaccessible, or privacy-invasive. AI-based interfaces should communicate uncertainty where relevant, provide human-readable explanations for consequential actions, and preserve user control. Personalisation should not silently remove essential choices or create discriminatory outcomes.

Best-Practice Design Checklist

Before release, a development team should be able to answer “yes” to most of the following:

  • Are the principal user goals and contexts documented?
  • Does the layout adapt to supported sizes, orientations, and text settings?
  • Are navigation and terminology consistent?
  • Are loading, empty, error, offline, and success states designed?
  • Can every essential action be performed without a complex gesture?
  • Are labels, focus order, roles, values, and state exposed to assistive technology?
  • Can text enlarge without clipping or loss of function?
  • Is colour supplemented by text, shape, or iconography?
  • Have real users, including disabled users, tested representative tasks?
  • Are permissions, data collection, and notifications understandable and proportionate?
  • Are design-system components documented and tested in all relevant states?
  • Are unresolved accessibility and usability risks recorded and prioritised?

Chapter Summary

Effective mobile application design integrates UI, UX, usability, and accessibility rather than treating them as separate stages. Human-centred design begins with user goals and context, proceeds through requirements and alternatives, and depends on iterative prototyping and evaluation. Responsive and adaptive layouts must handle device variation, orientation, text scaling, safe areas, and alternative input methods. Component systems and platform guidelines improve consistency when applied thoughtfully.

Typography, colour, hierarchy, gestures, and feedback determine whether users can perceive and operate an interface. Accessibility requires semantic controls, meaningful names, logical focus, scalable content, alternatives to colour and gesture, and testing with assistive technologies and disabled users. Wireframes and prototypes should represent not only the successful path but also loading, empty, error, offline, permission, and recovery states. Ethical practice requires respect for autonomy, privacy, inclusion, and transparent use of emerging AI capabilities.

Key Terms

UI: The visible and interactive means through which users operate software.

UX: The overall quality and meaning of a user’s interaction with a product.

Usability: The extent to which users achieve goals effectively, efficiently, and satisfactorily.

Accessibility: The design and implementation of products usable by people with diverse abilities.

Human-centred design: An iterative approach grounded in users, goals, and context.

Mental model: A user’s understanding of how a system operates.

Affordance: A possible action offered by an object or interface.

Signifier: A perceptible cue communicating an available action.

Responsive design: Layout behaviour that changes fluidly with available space.

Adaptive design: Intentional layout or behaviour variations for specified conditions.

Component system: Reusable interface elements with defined appearance, behaviour, and states.

Information hierarchy: The organisation of content according to importance and relationships.

Wireframe: A simplified representation of interface structure and content.

Prototype: A model used to explore or test an interaction.

Interaction flow: A sequence of user actions and system states.

Focus order: The sequence in which interactive elements receive input focus.

Screen reader: Assistive software that presents interface content through speech or braille.

Dark pattern: A design practice that manipulates or misleads users against their interests.

Dynamic text: User-controlled adjustment of text size or presentation.

Inclusive design: Design that considers a broad range of abilities, contexts, and needs.

Review Questions

Short Answer Questions

  1. Distinguish UI, UX, usability, and accessibility.
  2. What is the difference between responsive and adaptive design?
  3. Why should colour not be the only means of communicating status?
  4. State four important accessibility practices for mobile applications.
  5. What purposes can a prototype serve during development?

Long Answer Questions

  1. Explain how human-centred design can be applied from requirements analysis through usability evaluation.
  2. Discuss the role of component systems and platform guidelines in maintaining quality and consistency.
  3. Explain how typography, hierarchy, touch targets, gestures, and feedback affect mobile usability.
  4. Describe how a mobile application should support users during loading, error, offline, and recovery states.
  5. Analyse the relationship between accessibility and ethical software development.

Analytical / Application Questions

  1. A banking application uses colour alone to distinguish successful and failed payments, has no undo for transfers, and provides no progress feedback. Identify the usability and accessibility problems and propose a redesigned interaction.
  2. Design an inclusive interaction flow for booking an appointment on a mobile device. Include normal, validation-error, permission, offline, cancellation, and confirmation states.
  3. Evaluate a map-based campus application using the case in this chapter. Explain when a text-based route alternative, user testing, and adaptive layout would be necessary.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes usability from accessibility?

A. Usability concerns visual style, while accessibility concerns branding.

B. Usability concerns effective task completion, while accessibility concerns equivalent use by people with diverse abilities.

C. Usability applies only to websites, while accessibility applies only to mobile applications.

D. Usability concerns hardware, while accessibility concerns software licensing.

Correct Answer: B. Usability concerns effective task completion, while accessibility concerns equivalent use by people with diverse abilities.

Question 2

What is the primary purpose of a wireframe?

A. To define final colour gradients and animations

B. To test production server performance

C. To represent structure, hierarchy, navigation, and controls before detailed implementation

D. To replace accessibility testing

Correct Answer: C. To represent structure, hierarchy, navigation, and controls before detailed implementation

Question 3

Which practice best supports accessible error recovery?

A. Displaying only the message “Invalid input”

B. Clearing all fields after any error

C. Using colour alone to identify the failed field

D. Explaining the problem and stating how the user can correct it

Correct Answer: D. Explaining the problem and stating how the user can correct it

Question 4

A layout changes from one column to two columns when sufficient space is available. This is primarily an example of what?

A. Responsive or adaptive layout behaviour

B. Destructive navigation

C. Gesture-only interaction

D. Decorative animation

Correct Answer: A. Responsive or adaptive layout behaviour

Question 5

Why should essential actions not depend exclusively on complex gestures?

A. Gestures always require an internet connection

B. Some users may not know, perform, or be able to perform the gesture

C. Gestures cannot be implemented on touchscreens

D. Platform guidelines prohibit all gestures

Correct Answer: B. Some users may not know, perform, or be able to perform the gesture

Question 6

Which is the most appropriate label for a button that advances a payment flow?

A. Next

B. Continue to payment

C. Blue button

D. Tap here

Correct Answer: B. Continue to payment

Question 7

What does a component system normally define in addition to visual appearance?

A. Only the application’s marketing slogan

B. Only the database schema

C. States, behaviour, accessibility requirements, and appropriate use

D. The user’s personal preferences

Correct Answer: C. States, behaviour, accessibility requirements, and appropriate use

Question 8

A task is completed by 18 of 20 participants. What is the completion rate?

A. 18%

B. 20%

C. 80%

D. 90%

Correct Answer: D. 90%

Question 9

Which statement about automated accessibility tools is most accurate?

A. They detect every accessibility problem without user testing

B. They are useful for some structural defects but cannot replace testing with users

C. They are relevant only after an application is published

D. They remove the need for semantic controls

Correct Answer: B. They are useful for some structural defects but cannot replace testing with users

Question 10

Which practice best reflects ethical permission design?

A. Requesting every permission immediately at first launch

B. Hiding the purpose of data collection to reduce refusal

C. Explaining purpose and timing when the permission is relevant

D. Making refusal impossible for essential application use

Correct Answer: C. Explaining purpose and timing when the permission is relevant

Mobile Application Development
Chapter 4 of 15