↑ 2 - Project Scoping and App Platform Selection

2 - Project Scoping and App Platform Selection

Defining Project Scope in HCI Design

1

Defining Project Scope in HCI Design

▶

Every interface project begins long before the first wireframe is sketched or the first line of code is written. It begins with a decision about what the project is — and, just as importantly, what it is not. In Human-Computer Interaction (HCI), where the object of design is the relationship between a person and a system, that decision carries extra weight: a vague scope does not merely produce a late project, it produces an interface that serves nobody in particular. Defining project scope is the discipline of converting an enthusiastic, fuzzy idea ("let's build an app that helps people eat better") into a bounded, testable, buildable commitment ("a mobile application that lets users with diagnosed food allergies scan packaged-food barcodes and receive a safe/unsafe verdict in under three seconds").

This topic examines scope from five angles: what scope actually is and why it protects a team; how to articulate goals that are evaluable rather than aspirational; how to document the constraints of time, technology, and team capability; how to describe the target audience with enough precision that it drives design decisions; and finally how to consolidate all of this into a formal project description that functions as the team's shared contract and reference point.

What Is Project Scope?

Project scope is the agreed boundary around a project: the set of goals it will pursue, the deliverables it will produce, and the work that will be performed to produce them. In practice scope answers four questions simultaneously — what problem are we solving, for whom, what artefacts will exist when we are finished, and what are we deliberately not doing. The fourth question is the one teams most often skip, and it is the one that does the most work.

It is useful to distinguish two related concepts. Product scope describes the features and characteristics of the thing being built — the screens, the interactions, the capabilities. Project scope describes the work required to deliver that product — the research, the prototyping, the usability testing, the documentation, the handover. A team that defines only product scope frequently forgets to allocate time for evaluation, and so ships an untested interface. In an HCI project, usability testing, persona development and iteration cycles are themselves scope items and must be named as such.

A central reason to define scope is to defend against scope creep — the gradual, often well-intentioned accumulation of features that were never budgeted for. Scope creep rarely arrives as a single dramatic demand; it arrives as a succession of small, reasonable-sounding additions. "While we're in the settings screen, could we add dark mode?" "It would only take a day to let people share results to social media." Each addition consumes design time, adds interface complexity, introduces new states to test, and quietly pushes the original goals further away. The following table distinguishes creep from legitimate change:

Characteristic Scope Creep Managed Scope Change
Origin Informal conversation, chat message, hallway request Formal request raised against the project description
Assessment None — assumed to be "small" Impact on schedule, effort and other features is estimated
Trade-off Nothing is removed; the team simply absorbs it Something is removed, deferred, or the deadline moves
Record Undocumented; team members disagree later on what was agreed Project description updated and re-circulated with a version date
Typical outcome Late delivery, unpolished interface, untested edge cases Deliberate re-prioritisation with eyes open

Scope also serves a communication function. Stakeholders — a client, a course tutor, a product owner, an external partner, the end users themselves — each arrive with a private mental model of the project. If those models are never surfaced and reconciled, they collide at the worst possible moment: the demonstration. A written scope statement forces the reconciliation to happen early, when disagreement is cheap. Consider a student team building a campus wayfinding app: the tutor expects a usability-tested prototype, one team member expects a polished production release on the app store, and the facilities manager expects integration with the live room-booking database. Those three expectations cannot all be satisfied in eight weeks; naming them in week one lets the team negotiate rather than fail.

Finally, scope must be realistic against the team's actual capacity. Realism is not pessimism — it is arithmetic. A four-person student team working ten hours each per week for ten weeks has roughly 400 person-hours, of which a substantial fraction will disappear into meetings, coordination, learning new tools, and rework. Scoping to 390 hours of "productive" design and build work guarantees failure. Experienced teams scope to around 60–70% of nominal capacity and treat the remainder as buffer. Ambition belongs in the goals; realism belongs in the deliverables list.

Identifying Project Goals

A goal is not a feature. "Add a barcode scanner" is a feature; "allow an allergy sufferer to determine in a supermarket aisle, within seconds and without reading dense ingredient text, whether a product is safe for them" is a goal. The distinction matters because goals describe the problem and the value, while features describe one possible solution. Teams that write their scope as a feature list lock themselves into the first solution they thought of; teams that write goals leave room for the design process to discover a better one.

A well-formed HCI goal has three components: the user it serves, the problem or task it addresses, and the value or outcome it delivers. A simple sentence frame makes this explicit:

Enable [specific user group]
to [accomplish a concrete task]
so that [measurable value or outcome],
verified by [evaluation method].

Applied: "Enable part-time mature students to locate and book a free study room on campus in under 60 seconds from a mobile device, so that they stop wasting time walking between buildings, verified by a timed task in moderated usability testing with six participants." Note what this version gives the team that "make a room booking app" does not: a user group to recruit for testing, a task to script, a numeric threshold to pass or fail against, and an evaluation method that itself must be scheduled into the plan.

Goals must be specific enough to evaluate. The classic SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound) apply, but HCI projects benefit from attaching explicit usability metrics to goals. Common measures include task completion rate, time on task, error rate, number of assists required, and post-task satisfaction scores (for example, a System Usability Scale score). The table below contrasts weak and strong goal statements:

Weak goal Why it fails Stronger restatement
Make the app user-friendly No user, no task, no threshold — can never be shown to be achieved or missed Achieve a mean SUS score of at least 72 among eight first-time users after a 10-minute unaided session
Use modern technology Technology-centred, not user-centred; delivers no stated value to anyone Reduce sign-in friction by supporting device biometric authentication, cutting mean sign-in time from 22s to under 5s
Include a dashboard A solution stated as a goal; forecloses alternatives Allow a ward nurse to see at a glance which patients are overdue for observations, with zero navigation steps from app launch
Support everyone Unbounded audience; impossible to design or test against Support screen-reader users on iOS VoiceOver for all primary task flows, meeting WCAG 2.2 AA for contrast and focus order

Goals also function as a decision-making instrument. Design is a continuous sequence of trade-offs — speed versus discoverability, density versus clarity, automation versus user control — and in the absence of ranked goals those trade-offs are resolved by whoever argues most forcefully. With ranked goals, the argument becomes evidence-based. If the primary goal of the supermarket scanner is "a verdict within three seconds in a noisy, one-handed, time-pressured context," then an onboarding tutorial that must be dismissed on every launch is objectively wrong, and a large single-colour verdict panel objectively beats an elegant nutritional breakdown. Teams often formalise this with a MoSCoW ranking (Must have, Should have, Could have, Won't have this time) applied to features, each traced back to the goal it serves. A feature that traces to no goal is a candidate for removal.

Finally, goals should be user-centred rather than technology-centred. A recurring failure pattern in student and hobby projects is that the technology is chosen first — "we want to use augmented reality" or "we want to try a large language model" — and a user problem is reverse-engineered to justify it. The result is almost always an interface that performs a trick rather than solving a need. Grounding goals in observed human behaviour (interviews, contextual inquiry, surveys, analysis of how the task is performed today) protects against this. A useful test: for each goal, ask "whose day gets better, and how would they describe the improvement in their own words?" If the answer can only be phrased in technical terms, the goal is not yet user-centred.

Defining Constraints

Constraints are the fixed walls of the design space. Far from being obstacles to creativity, documented constraints are what make design tractable: an unconstrained problem has infinite solutions and therefore no basis for choosing among them. Constraints should be written down at the start, dated, and revisited, because an undocumented constraint invariably resurfaces later as an unpleasant surprise.

Time constraints define the overall delivery window and the milestones inside it. A single end date is insufficient; it provides no early warning. Instead the timeline should be decomposed into checkpoints with associated artefacts, so that slippage is visible weeks before the deadline. In HCI projects the schedule must explicitly reserve time for evaluation and iteration, because these are the first activities sacrificed under pressure and the ones whose loss most damages the final product. A workable ten-week structure might look like this:

Weeks Milestone Artefact produced Risk if compressed
1–2 Scoping and user research Project description, personas, task scenarios Team builds for an imagined user; rework later
3 Information architecture and low-fidelity design Sitemap, paper or wireframe sketches Navigation problems discovered only after coding
4–5 Interactive prototype Clickable prototype of primary task flows No testable artefact; evaluation delayed
6 Formative usability testing Findings log, prioritised fix list Known defects ship to users
7–8 Build / high-fidelity implementation Working application of Must-have features Features half-finished across the board
9 Summative evaluation and accessibility check Test report, metrics against goals No evidence that goals were met
10 Polish, documentation, handover Final build, README, presentation Chaotic demonstration; undocumented system

Technical constraints arise from the chosen platform, the available APIs, the devices in users' hands, and the environment in which the system runs. These are deeply intertwined with HCI because platform capability determines what interactions are even possible. A mobile application can access the camera, GPS, accelerometer, haptics and push notifications, and can function offline — but it must work on a small screen, under one-handed use, with touch targets of at least roughly 44×44 points, and subject to app-store review. A web application reaches any device with a browser and updates instantly without user action, but historically has weaker access to device sensors, depends on connectivity, and must be responsive across an enormous range of viewport sizes. A desktop application offers generous screen area, precise pointer input, rich keyboard shortcuts and heavy local processing, but requires installation, platform-specific builds, and update distribution. Other technical constraints include browser or OS version floors, data-protection obligations that forbid storing certain information on device, bandwidth limits in the user's context, and integration with legacy systems whose APIs cannot be changed.

Team constraints concern the skills, availability and composition of the people doing the work. A team with strong front-end web skills and no native mobile experience faces a real cost if it commits to a Swift application: the learning curve consumes weeks that were budgeted for design. Bandwidth matters as much as skill — a team member with a part-time job and two other modules may realistically contribute six hours a week, not twenty. Other team constraints include the distribution of the team across time zones, access to licensed software or test devices, the presence (or absence) of someone able to moderate a usability session, and the "bus factor" risk when only one person understands a critical component. Honest documentation of these constraints is not an admission of weakness; it is the basis of a plan that will actually survive contact with reality.

A compact constraints register keeps all of this visible:

Type Constraint Consequence for design Mitigation
Time Hard demonstration date in week 10; no extension Only three primary task flows can be built to high fidelity Rank flows; cut "Could have" items at the week-6 review
Technical Target users are on older Android devices with intermittent data Interface must degrade gracefully and cache content offline Design offline states explicitly; test on a low-end device
Technical University timetable API is read-only and rate-limited No in-app booking; viewing only Reframe goal as "find", not "book"; state in out-of-scope list
Team No team member has native iOS experience Native Swift build would consume ~3 weeks of learning Choose responsive web or cross-platform framework; justify in description
Team Only one member available for in-person testing sessions Limited number of moderated sessions possible Schedule six sessions early; supplement with unmoderated tasks
Legal/ethical Health-related data is collected Consent flow and data-minimisation required in the interface Design consent screen in week 3; obtain ethics sign-off

Documenting constraints early also performs an expectation-management function with stakeholders. A client who is told in week one that the booking API is read-only will accept a "find a room" product; the same client told in week nine will perceive a failure. The constraint did not change — only the moment of disclosure did.

Scoping the Target User Audience

"Everyone" is not an audience. An interface designed for everyone optimises for no one, because the needs of a 19-year-old computer science student and an 82-year-old first-time tablet user genuinely conflict in matters of information density, text size, terminology, error tolerance and pacing. Scoping the audience means choosing, explicitly and defensibly, whose needs will be prioritised — and, by implication, whose will not be the primary driver of design decisions this time around.

A usable audience definition covers at least three dimensions:

  • Demographics and situation: age range, occupation or role, language, location, relevant physical or sensory characteristics, and any accessibility requirements. These shape typography, colour contrast, language register and localisation needs.
  • Technical proficiency: familiarity with the platform's conventions, frequency of use (one-off visitor versus daily expert), tolerance for abstraction, and existing mental models drawn from tools they already use. Novices need visible affordances, generous labelling, forgiving defaults and undo; frequent experts need speed, keyboard shortcuts, batch actions and the ability to suppress hand-holding. Many real systems must serve both, which is why progressive disclosure and accelerators exist.
  • Context of use: the physical and social environment in which the task is performed. Is the user seated at a desk for an hour, or standing on a cold warehouse floor wearing gloves for fifteen seconds? Is the screen viewed in bright sunlight? Are hands free? Is the user interrupted constantly? Is the task performed under emotional stress, as with a patient portal or a bereavement service? Context of use frequently constrains design more sharply than demographics do.

These dimensions are usually captured in personas — evidence-based composite characters — paired with scenarios that place the persona in a situation with a goal. For example: "Marcus, 34, a delivery driver, uses a cracked mid-range Android phone with 2GB of data a month. He checks the app one-handed while the engine runs, in bright daylight, and needs to confirm the next drop in under ten seconds." Nearly every consequential design decision for that product — contrast ratio, touch target size, payload weight, offline caching, the decision not to put critical actions at the top of the screen — follows directly from that paragraph. A persona that produces no design consequences is decoration; a persona that constrains choices is doing its job.

Audience definition also determines which features belong in scope. If research shows that the primary users of a community-garden app are volunteers who visit twice a month, then a sophisticated analytics dashboard serves nobody, while a simple "what needs doing today" list serves everyone. Features should be traceable to a documented user need; those that cannot be traced are candidates for the out-of-scope list. It is worth distinguishing primary users (whose goals drive the design), secondary users (who use the system occasionally and must not be blocked), and stakeholders who are affected but never touch the interface — a parent paying for a child's learning app, for instance, has interests that shape requirements without making them the primary user.

Crucially, the audience's device access and platform habits directly determine platform selection. This is where audience scoping and technical scoping meet. The table below illustrates how audience facts translate into platform consequences:

Audience characteristic Platform implication Example
Users are mobile during the task and need sensors (camera, GPS) Favours a mobile app or a capable progressive web app Field surveyors photographing and geotagging site damage
Users are occasional, arrive via a shared link, and will not install anything Favours web; an install requirement would destroy adoption One-off event feedback form or public information service
Users work long sessions with large data sets and precise manipulation Favours desktop or a desktop-class web application Video editing, CAD, financial modelling, code authoring
Users are on locked-down managed corporate machines Web avoids installation permissions and deployment friction Internal HR or expense-claim tool
Users have limited or expensive data and older hardware Constrains payload size, animation, and framework choice Services for low-income or rural populations
Users rely on assistive technology Platform must have mature accessibility APIs and be tested with them Screen-reader users on a public-sector service subject to accessibility regulation

Defining the audience early also has an organisational benefit: it gives the team a shared referent. When a designer and a developer disagree about whether a confirmation dialogue is necessary, "would Marcus, one-handed with the engine running, thank us for this?" resolves the argument faster than opinion exchange. Over a project, this shared vision reduces the number of decisions that must be escalated and keeps the interface internally coherent rather than a patchwork of individual preferences.

Writing a Formal Project Description

The formal project description — variously called a project brief, scope statement, or design brief — is the artefact in which everything above is consolidated. Its purpose is not bureaucratic. It exists because human memory of verbal agreements is unreliable and self-serving: three weeks after a meeting, four team members will sincerely recall four different versions of what was decided. A written, dated, circulated document converts a cloud of individual assumptions into a single shared reference that can be pointed at.

A good project description is short enough to be read in one sitting — typically two to four pages for a student or small-team project — and structured so that any section can be located quickly. A dependable structure is:

  • Title, version and date: version control matters, because the document will change. "v1.3, 14 March" prevents arguments conducted against different copies.
  • Problem statement: two or three sentences describing the human problem that exists today, with evidence. What do people currently do, and why is it unsatisfactory?
  • Project goals: the ranked, evaluable goal statements, each with its success criterion and evaluation method.
  • Target audience: primary and secondary users, with a summary of demographics, proficiency and context of use, and a pointer to the personas.
  • Platform decision and rationale: the chosen platform, the alternatives considered, and the reasons — tied to audience and constraints — for the choice.
  • In scope: the deliverables and features the team commits to, ideally ranked (Must / Should).
  • Out of scope: explicitly named exclusions, with a one-line reason for each.
  • Constraints and assumptions: the constraints register, plus any assumptions being made that, if false, would change the plan.
  • Success criteria: how the team and stakeholders will jointly judge the finished work.
  • Milestones and responsibilities: who is doing what, by when.
  • Change process: one short paragraph stating how scope changes will be requested, assessed and recorded.

The out-of-scope list is the highest-value section of the document and the one most often omitted. Stating what will not be built removes ambiguity that silence leaves open. "User accounts and login" is either in or out; if the document says nothing, the developer assumes out and the client assumes in. Exclusions should be specific and reasoned, for example:

OUT OF SCOPE (v1.0)
- Native iOS build .............. no team iOS experience; web reaches all target users
- Payment / checkout ............ no merchant account available within the timeline
- Admin content-management UI ... content edited directly in the data file for v1
- Multi-language support ........ target audience surveyed are English-speaking; defer to v2
- Real-time chat support ........ no capacity to staff it; FAQ page instead
- Offline editing ............... read-only offline cache only; sync conflicts out of scope

Equally important is recording the rationale behind key decisions, particularly platform choice. A decision recorded without its reasoning cannot be revisited intelligently: six weeks later nobody remembers whether "we chose a responsive web app" was a considered judgement or a coin toss, so the question gets reopened and re-argued. A short decision record solves this:

Field Entry
Decision Build as a responsive progressive web application
Alternatives considered Native Android app; cross-platform framework; desktop application
Audience evidence Survey of 42 target users: 86% access campus services on mobile; 61% report reluctance to install another app for occasional use
Constraints applied Ten-week timeline; no native mobile skills in team; read-only timetable API; no app-store account
Trade-off accepted No push notifications and no background location; offline support limited to cached timetable data
Revisit if Push notification becomes a Must-have, or the API gains write access
Decided by / date Full team, week 2, v1.0

The description should also be used, not filed. In practice this means three habits. First, every new feature proposal is tested against the document: which goal does it serve, which constraint does it strain, and what comes out to make room for it? Second, the document is reviewed at each milestone and updated with a new version number when scope legitimately changes, so that the latest copy is always authoritative. Third, the success criteria in the document become the script for the final evaluation — if a goal said "task completion in under 60 seconds for six of eight participants," then that is precisely the test that gets run, and the result is reported honestly whether it passes or fails.

A brief worked illustration ties the whole chain together. A team identifies a problem: mature part-time students waste time hunting for free study space. The goal becomes "enable a part-time student to identify a free, bookable study room within 60 seconds on a phone." Audience research shows these students are between classes, on mobile, often with poor indoor signal, and strongly resistant to installing single-purpose apps. Constraints are a ten-week timeline, a read-only timetable API, and no native mobile skills. The platform decision therefore falls to a responsive progressive web app with offline caching. In scope: room search, availability display, filtering by building and facilities, cached last-known data. Out of scope: booking (API is read-only), accounts, notifications, multi-campus support. Success criterion: six of eight test participants complete the find-a-room task unaided in under 60 seconds, with a mean SUS score of at least 72. Every element of that chain is traceable to the one before it — which is precisely what a well-scoped project looks like.

Alignment with Learning Outcomes

  • MO1: The treatment of technical constraints and of audience device access sets out the differing capabilities of mobile, web and desktop platforms — sensors, screen real estate, input precision, installation and connectivity — and shows how each is weighed against the needs and context of a defined user group, supporting direct comparison on HCI design grounds.
  • MO2: The platform-decision record, the audience-to-platform mapping table and the constraints register provide the evidence base and documentation format needed to select a platform and justify that selection against stated project requirements, constraints and user research.
  • MO3: The topic as a whole is the direct preparation for this outcome: it defines evaluable goals, documents time, technical and team constraints, scopes the audience, and specifies the structure, in-scope/out-of-scope content and success criteria of a formal project description.
NotesSuggested activities: (1) have teams rewrite three weak goal statements into evaluable form using the "Enable / to / so that / verified by" frame; (2) issue a short constraints-register template for completion in week 1 and review it at the week-6 milestone; (3) run a peer review in which each team critiques another's out-of-scope list for missing exclusions. The ten-week milestone table and the SUS threshold of 72 (roughly the boundary of "good" on common SUS interpretation scales) can be adjusted to match the actual assessment calendar and local standards.
2

Videos on This Topic

▶

Every interface project begins with a question that is easy to skip and expensive to ignore: what exactly are we building, for whom, and within what limits? Project scope is the agreed boundary around your work. It states the goals the interface must achieve, the constraints you must design within (time, budget, team skills, device capabilities, accessibility and platform requirements), the users you are designing for, and the criteria that will tell you whether you succeeded. Without that boundary, teams drift, features multiply, and the final product satisfies no one in particular.

In this course, scoping is the step that makes the rest of Module 2 possible. You cannot sensibly compare mobile, web, and desktop platforms until you know what your users need to do, where they will do it, and what your project can realistically support. The formal project description you write is both a planning tool and a communication tool: it aligns your team, and later it gives you something concrete to evaluate your design against.

The three videos below approach scoping from different angles. As you watch, pay attention to how each one frames decisions: What questions get asked before design work starts? Who is in the room? How are goals separated from solutions? Where do constraints enter the conversation? Try to collect a short list of questions you could ask about your own project, and note any vocabulary (goals, requirements, deliverables, users, affordances) you can reuse when you write your scope document.

3

Video 1: 7 Fundamental Activities for UX Workshops

▶

NNgroup · 5:11 · 34,513 views · 5y ago · captions — Watch on YouTube

About this video

Nielsen Norman Group breaks the wide variety of UX workshop exercises down into seven foundational activities that underlie most of them. The video is likely to cover activities such as generating ideas, clarifying and organizing information, converging on decisions, and prioritizing — the kinds of structured group work teams use to agree on goals and boundaries early in a project. It is a short, practical overview rather than a deep dive into any single exercise.

Why this video

Scoping is rarely a solo act, and this video from a widely respected UX research organization gives you a vocabulary for the collaborative activities that produce agreed goals, priorities, and constraints — directly supporting the "Identifying Project Goals" and "Defining Constraints" subtopics.

4

Video 2: Complete Web Design Process: What Took Me 10 Years to Learn in 12 Minutes [Free Trello Template]

▶

Self-Made Web Designer · 12:13 · 152,312 views · 1y ago · captions — Watch on YouTube

About this video

A practicing designer walks through an end-to-end web design process, from initial client contact and discovery through planning, design, and delivery, with a shared project template. Expect discussion of how requirements are gathered, how work is organized into phases, and how expectations are set with a client before design begins. The perspective is professional practice rather than academic theory.

Why this video

It shows scoping in a real workflow — how goals, audience, deliverables, and limits get written down and communicated before any interface is built — which is a useful model for the "Writing a Formal Project Description" subtopic.

5

Video 3: What are Affordances in UX Design. Affordances Explained on Example

▶

IxDF - Interaction Design Foundation · 4:06 · 16,031 views · 3y ago · captions — Watch on YouTube

About this video

The Interaction Design Foundation explains affordances: the properties of an object or interface that signal what actions are possible, illustrated with concrete examples. The video is likely to connect affordances to user expectations and to how design choices communicate function without explicit instructions.

Why this video

Affordances differ across platforms and user groups, so this concept helps you reason about target audience assumptions and platform constraints — the kind of thinking that turns a vague goal into a scoped, defensible design requirement.

6

How These Videos Support the Learning Outcomes

▶

Together these videos move from understanding users and their expectations to structuring team decisions to documenting a plan. The affordances video builds the user-centered reasoning behind MO1, since what an interface can plausibly afford depends on whether it runs on a phone, a browser, or a desktop. The workshop activities video supplies methods for surfacing goals, weighing options, and converging on a justified choice, which is the core skill behind MO2. The full design process video models how discovery, requirements, and deliverables get captured in writing, giving you a concrete reference as you draft the objectives, constraints, and success criteria required by MO3.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Overview of Target Application Platforms

1

Overview of Target Application Platforms

▶

Every interactive product lives somewhere. Before a designer draws a single screen or a developer writes a line of code, a decision has already been made — explicitly or by default — about where the software will run and what kind of machine and context the user will bring to it. That decision is the single most consequential constraint in interface design, because it determines the physical input devices available, the screen real estate, the attention the user can spare, the interaction conventions the user already knows, and even the distribution mechanism by which the product reaches them. A brilliant interface designed for a 27-inch desktop monitor with a precision mouse becomes unusable when squeezed onto a 1.7-inch smartwatch face; a conversational flow that feels natural when spoken aloud becomes maddening when transcribed into a form.

This topic surveys the landscape of target application platforms. It begins with the four primary platforms that form the backbone of most professional practice and of this course — Android, iOS, Windows desktop, and the Web — examining the audience, device characteristics, and design culture of each. It then looks beyond those four to emerging and specialised platforms: wearables, voice interfaces, and augmented and virtual reality. Finally, it steps back to group these platforms into three broad categories — mobile, desktop, and web — and identifies the human factors considerations that distinguish each category. Throughout, the emphasis is not on implementation detail but on the design consequences of platform choice: what each platform makes easy, what it makes hard, and what it makes impossible.

The Four Primary Platforms

The four primary platforms are not an arbitrary list. Between them they cover the overwhelming majority of consumer and enterprise software delivery today, and they represent four genuinely different philosophies about hardware diversity, distribution control, and user expectation. Understanding the character of each is the foundation of informed platform selection.

Android: breadth, diversity, and global reach. Android is an open-source operating system licensed to a very large number of hardware manufacturers — Samsung, Xiaomi, Oppo, Google, Motorola, Tecno, Infinix and dozens more. The consequence is extraordinary diversity. An Android application may be installed on a flagship device with a 6.8-inch high-resolution display, 12 GB of RAM, and the latest OS release, and also on an entry-level handset with a 5-inch 720p screen, 2 GB of RAM, and an operating system version three or four years old. This spread is usually described as fragmentation, and it is the defining design constraint of the platform.

Fragmentation operates along several axes at once:

  • Screen size and density. Android devices range from compact phones through phablets, foldables, tablets, Chromebooks running Android apps, and television interfaces. Layouts must be genuinely responsive rather than pixel-positioned, which is why Android expresses dimensions in density-independent pixels (dp) and text in scalable pixels (sp) rather than raw hardware pixels.
  • OS version. Because updates are mediated by manufacturers and carriers, a significant share of active devices run older releases. A designer who relies on a visual component or permission model introduced in the newest version must plan a graceful fallback.
  • Performance envelope. Animations, image processing, and background work that are smooth on a flagship may stutter badly on a budget device. Testing on low-end hardware is not optional.
  • Manufacturer skins. Samsung's One UI, Xiaomi's HyperOS and others alter system fonts, default colours, gesture navigation, and even battery-management behaviour, so an app's visual appearance and background reliability vary by brand.

Android's audience is correspondingly broad and global. It holds dominant market share across South and Southeast Asia, Africa, and Latin America, and substantial share in Europe. For a product aiming at mass-market or emerging-market reach, Android is frequently the only rational first choice. That audience profile brings its own human factors considerations: intermittent or metered connectivity, prepaid data plans, lower-end hardware, and a wide spread of digital literacy. Good Android design therefore tends to emphasise offline tolerance, small download sizes (Android App Bundles and the lightweight Instant Apps mechanism exist for exactly this reason), and clear, forgiving interaction.

Android's design language is Material Design, which codifies elevation and shadow, a responsive layout grid, a defined type scale, and motion principles. Material 3 (Material You) added dynamic colour, where the palette is derived algorithmically from the user's wallpaper — a deliberate commitment to personalisation that is almost the opposite of Apple's approach. Distribution is primarily through Google Play, but Android also permits sideloading and alternative stores (Samsung Galaxy Store, Amazon Appstore, F-Droid, Huawei AppGallery), which matters enormously for enterprise deployment and for markets where Google services are unavailable.

Illustrative example. A field-data-collection app for agricultural extension officers in rural regions would target Android almost by default: the officers' devices are inexpensive Android handsets, connectivity is unreliable so the app must queue submissions locally, and distribution may be by direct APK install rather than through a store. The interface must use large touch targets usable with work gloves in bright sunlight, high-contrast colour, and minimal reliance on animation.

iOS: control, consistency, and a premium context. iOS runs only on hardware Apple designs and manufactures. The device matrix is small and well documented, OS adoption of new versions is rapid (typically a large majority of active devices within a year), and the hardware floor is comparatively high. For designers, this means a far more predictable canvas: a known set of screen sizes and aspect ratios, consistent performance characteristics, reliable availability of sensors and capabilities, and dependable support for advanced features such as high-refresh-rate displays, wide-colour (Display P3) imagery, and on-device machine learning.

The flip side of that predictability is constraint of a different kind. Apple exercises tight control over the ecosystem:

  • Distribution is through the App Store, subject to a human and automated review process against the App Store Review Guidelines. Rejections for interface reasons — misleading UI, poor onboarding, duplicating system functionality badly, inadequate account-deletion flows — are common and must be budgeted for in the project schedule.
  • The Human Interface Guidelines (HIG) are treated as near-normative. Deviating from platform conventions (for example, inventing a custom navigation bar that fights the standard back-swipe gesture) produces apps that feel alien to users and risk reviewer objection.
  • Privacy requirements are strict and visible to users: App Tracking Transparency prompts, privacy "nutrition labels" on the store listing, and granular permission dialogues all become part of the user's experience of the product and must be designed for, not bolted on.

The iOS audience skews towards higher-income markets — North America, Western Europe, Japan, Australia — and iOS users are consistently observed to spend more per capita on apps and in-app purchases. For a subscription product, a premium consumer brand, or an app whose monetisation depends on willingness to pay, iOS often delivers better revenue per user even with a smaller installed base. The platform's aesthetic culture reinforces this: deference to content, restrained chrome, fluid and physically plausible animation, careful typography using the San Francisco type family, and generous use of blur and translucency to convey layering.

Illustrative example. A meditation and sleep app monetised by annual subscription, aimed at affluent urban professionals, is a natural iOS-first product. The audience is concentrated on the platform, the payment infrastructure is frictionless, the hardware supports the smooth animation and high-fidelity audio the experience depends on, and integration with HealthKit and the Apple Watch extends the product meaningfully.

Windows desktop: productivity, complexity, and the enterprise. Windows retains roughly three-quarters of the desktop operating system market and is overwhelmingly the dominant platform in corporate, governmental, industrial, and educational institutions. Desktop applications on Windows are built with technologies including Win32, Windows Presentation Foundation (WPF), WinUI 3 / the Windows App SDK, Windows Forms, and increasingly cross-platform frameworks such as Electron, .NET MAUI, Qt, and Avalonia.

What distinguishes Windows desktop as a design target is not the operating system so much as the work done on it. Desktop applications are where people sit for hours, manipulate large and structured data sets, keep many documents open simultaneously, and build genuine expertise in a tool. This permits — and demands — an interaction model that mobile cannot support:

  • Dense information display. A spreadsheet, an IDE, a CAD workspace, a trading terminal, or a hospital administration system may present thousands of data points and dozens of simultaneous controls. Density that would be unusable on a phone is a productivity feature on a 27-inch monitor viewed at 60 cm.
  • Precise pointing and hover. A mouse cursor can target a 4-pixel window edge. Hover states enable tooltips, previews, and progressive disclosure that have no touch equivalent.
  • Keyboard-first expert interaction. Shortcuts, mnemonics, type-ahead, modifier-click, and command palettes allow experienced users to work far faster than any pointing device permits. Designing a professional Windows application without a coherent keyboard model is a serious failure.
  • Multi-window and multi-monitor workflows. Users compare documents side by side, drag content between windows, and snap panes across two or three displays. Applications must tolerate being resized to extremes and must remember window state.
  • Deep OS and file-system integration. File associations, drag-and-drop from Explorer, printing, the clipboard, shell context menus, scheduled background services, and access to local hardware (scanners, instruments, label printers, barcode readers) are routinely expected.

Enterprise context brings further constraints that are easy to overlook: deployment via MSI/MSIX packages and management tools such as Microsoft Intune or SCCM rather than a consumer store; operation on locked-down machines without administrator rights; compatibility with group policy, single sign-on, and corporate antivirus; and often a requirement to work entirely offline within a secured network. Long support lifetimes are normal — enterprises may run the same version of an application for a decade — which raises the cost of interface churn and makes backward compatibility a design obligation. Microsoft's current design language is Fluent Design, characterised by layering, acrylic and mica materials, subtle depth, and rounded geometry, though a great deal of deployed enterprise software still uses much older visual conventions.

Illustrative example. A laboratory information management system used by technicians to log specimens, attach instrument output, and generate accredited reports belongs on Windows desktop. It needs to talk directly to USB-connected analysers and barcode scanners, display large sortable grids, support rapid keyboard entry by trained operators, run inside a hospital network with no public internet access, and integrate with local printers for labels.

Web: reach without installation. A web application runs inside a browser and is therefore, in principle, available on any device with a modern browser — Windows, macOS, Linux, Android, iOS, Chrome OS, and even televisions and games consoles. This platform-agnosticism is the web's defining advantage and the source of its characteristic trade-offs.

The advantages are substantial:

  • No installation friction. A URL is the entire onboarding path. For products that rely on sharing, link-based invitation, or trial before commitment, this is decisive.
  • Instant, universal updates. Deploying a fix updates every user at once. There is no version fragmentation to support, no store review delay, and no risk of users stranded on an ancient release.
  • Single codebase, broad reach. One well-built responsive application can serve desktop and mobile users, which dramatically reduces cost compared with maintaining separate native clients.
  • Linkability and discoverability. Any state can be addressed by a URL, shared, bookmarked, and indexed by search engines — a capability native apps only approximate through deep links.
  • Mature accessibility infrastructure. HTML's semantic elements, ARIA, and the long-established Web Content Accessibility Guidelines give the web the most developed accessibility tooling of any platform, and public-sector procurement frequently mandates compliance.

The costs are equally real. Web applications have constrained access to device capabilities: although modern browser APIs expose geolocation, camera, microphone, notifications, Bluetooth, and storage, support is uneven and some capabilities (deep background execution, system-level integration, certain sensors) remain unavailable or heavily restricted, especially on iOS Safari. Performance ceilings are lower than native for graphics-intensive or computation-heavy work, even with WebAssembly and WebGL/WebGPU. Offline operation requires deliberate engineering via service workers. And cross-browser inconsistency, while vastly better than a decade ago, still demands testing across engines (Blink, Gecko, WebKit) and across the enormous range of screen sizes the web must serve.

Progressive Web Apps (PWAs) partially close the gap: a PWA can be installed to the home screen or taskbar, run in its own window without browser chrome, cache assets for offline use, and receive push notifications. They are a genuinely useful middle path, though platform support — particularly Apple's — has historically been inconsistent.

Illustrative example. A collaborative document editor used by distributed teams is a web-first product. Documents are shared by link, collaborators must be able to open them on whatever machine they happen to be using without installing anything, and changes to the editor must reach everyone simultaneously so that collaborators are never on incompatible versions.

The following table summarises the comparative character of the four primary platforms.

Dimension Android iOS Windows Desktop Web
Primary audience Broad, global, all price points; strong in emerging markets Apple device owners; higher-income markets Professional, enterprise, institutional users Anyone with a browser; the widest possible reach
Device diversity Very high (fragmented hardware, OS versions, skins) Low and well documented Moderate (varied screens, but predictable input) Extreme (every screen size and browser engine)
Primary input Touch, gestures, voice Touch, gestures, voice Keyboard and mouse; sometimes touch/pen Depends on host device — must support both
Design language Material Design 3 Human Interface Guidelines Fluent Design (plus much legacy convention) No single standard; house design systems, WCAG
Distribution Google Play, alternative stores, sideloading App Store only (with review) Installers, MSIX, enterprise management tools, Microsoft Store A URL; optionally installable as a PWA
Update control Partly user-controlled; multiple versions live Fast adoption; review delay on release Often IT-controlled; very long support tails Immediate and total — server-side
Hardware/OS access Extensive Extensive but tightly governed Deepest of all (file system, peripherals, services) Limited and inconsistent across browsers
Typical session Short, frequent, interrupted, mobile Short, frequent, interrupted, mobile Long, focused, seated, expert Highly variable
Monetisation profile Volume-driven; ads and freemium common Higher spend per user; subscriptions strong Licences, seats, enterprise contracts Subscription/SaaS, advertising

Beyond the Four: Additional Platforms

The four primary platforms account for most of the work a graduate will do, but they are not the boundary of the field. Interaction is steadily escaping the rectangular screen, and several adjacent platforms now have real commercial presence. Each demands a design paradigm that cannot be derived by simply shrinking or stretching a phone interface.

Wearables: design under severe constraint. Smartwatches and fitness bands (watchOS, Wear OS, and proprietary platforms from Garmin, Fitbit, Huawei and others) impose the tightest constraints in mainstream computing. A typical watch display is between 1.2 and 2.0 inches diagonal, viewed at arm's length, often while the user is walking, running, cooking, or driving. The following constraints follow directly:

  • Glanceability is the governing principle. Research and platform guidance converge on an interaction budget of a few seconds — the time a user will hold their wrist up. The design question is therefore not "what can we show?" but "what single thing matters most right now?" Apple's HIG speaks of designing for interactions measured in seconds, not minutes.
  • Severely limited screen real estate. There is room for perhaps one primary piece of information, a short label, and one or two actions. Multi-step forms, dense tables, and long text are effectively impossible. Information must be filtered and pre-digested on the phone or server.
  • Imprecise, small-target touch. The "fat finger" problem is at its worst here; a fingertip may occlude a third of the display. Platforms compensate with alternative inputs — the Apple Watch Digital Crown for scrolling, rotating bezels on Samsung devices, wrist gestures, hardware buttons, and heavy reliance on voice dictation and pre-written quick replies.
  • Notification-centred interaction model. Most wearable usage is reactive: the device taps the wrist, the user glances, and either dismisses or takes a single action. This makes notification design — relevance, frequency, and the quality of the haptic signal — the core design activity. Over-notification is the characteristic failure mode of the platform, because the cost of an irrelevant interruption is physical.
  • Power and sensor context. Tiny batteries constrain always-on displays, background processing, and animation. Conversely, continuous body contact gives access to heart rate, blood oxygen, skin temperature, motion, and sleep data that no other platform can obtain, which is why health, fitness, and payment are the dominant wearable use cases.

Illustrative example. A delivery-logistics company adds a Wear OS companion to its driver app. The phone app shows the full route, manifest, and customer details. The watch app shows only the next stop's street address, a single large "Arrived" button, and a haptic nudge when the vehicle approaches. Attempting to mirror the phone's screens on the wrist would be unusable and unsafe.

Voice interfaces: designing without a screen. Voice user interfaces (VUIs) — Amazon Alexa, Google Assistant, Siri, in-car assistants, and interactive voice response systems — replace the visual, spatial interaction model with a temporal, linguistic one. Almost every habit of graphical design has to be set aside.

  • There is no visible affordance. A GUI shows the user what is possible; a VUI does not. Users cannot scan a menu, so the system must teach capability through onboarding, contextual prompts, and well-chosen examples ("You can say things like add milk to my shopping list"). Discoverability is the hardest problem in voice design.
  • Speech is linear and transient. Spoken output cannot be skimmed or re-read; it must be heard in sequence and held in working memory. This imposes a hard limit — long lists are intolerable, so a voice system offers two or three options, not twelve, and paginates conversationally ("Those are the first three. Want to hear more?").
  • Conversational flow design replaces screen flow design. The design artefacts are dialogue scripts, intents, utterance variations, slots, prompts, re-prompts, confirmations, and error-recovery paths — not wireframes. Designers must enumerate the many ways a person might phrase the same request, and plan for the no-input, no-match, and partial-information cases.
  • Error handling is central, not peripheral. Automatic speech recognition is imperfect, especially with accents, background noise, children's voices, or domain-specific vocabulary. Good VUIs use implicit confirmation for low-risk actions ("Adding milk — anything else?") and explicit confirmation for consequential ones ("You want to transfer two hundred euro to Maria. Should I go ahead?"), and escalate help progressively after repeated failures.
  • Persona, tone, and prosodyare part of the interface. The system's wording, pace, and personality carry the same weight that typography and colour carry in a GUI. Contractions, short sentences, and varied acknowledgements ("Got it", "Sure", "Done") make a system feel responsive; stilted or repetitive phrasing makes it feel broken even when it is functioning correctly.
  • Context of use is usually hands-busy and eyes-busy. People talk to assistants while cooking, driving, or carrying a child. The interaction must tolerate interruption, background noise, and partial attention, and it must never require the user to look at anything.

Many voice platforms are in practice multimodal: a smart display or a car dashboard pairs speech with a screen. The design rule there is that the screen supplements but never replaces the spoken answer — the interaction must still succeed with the eyes closed.

Illustrative example. A pharmacy chain builds an Alexa skill for prescription refills. The flow cannot read out a list of fourteen medications; instead it offers "You have three refills ready. The first is your blood pressure tablets — shall I refill that one?" It uses explicit confirmation before submitting the order, never speaks sensitive diagnostic detail aloud by default, and falls back to "I'll send the details to your phone" when the information exceeds what speech can carry.

Augmented and virtual reality: spatial design. AR and VR platforms — Meta Quest, Apple Vision Pro, SteamVR headsets, Microsoft HoloLens in industry, and phone-based AR through ARKit and ARCore — move the interface off the plane and into three-dimensional space around the user. The shift is more fundamental than any other on this list.

  • The interface has depth, scale, and placement. Content exists at a distance, at a size, and in a location relative to the user's body. Designers work with comfortable viewing zones (typically around 0.5 to 2 metres for interactive content), field-of-view limits, and the distinction between world-locked content that stays fixed in the room, body-locked content that follows the user, and head-locked content that is generally avoided because it induces discomfort.
  • Input is gaze, gesture, voice, and controller. Apple's Vision Pro uses eye gaze to target and a finger pinch to select; Quest uses hand tracking or six-degree-of-freedom controllers; HoloLens uses air-tap gestures. Targets must be far larger than on a screen, generously spaced, and accompanied by clear hover and selection feedback, because pointing accuracy is low and there is no tactile confirmation.
  • Comfort and safety are design requirements, not refinements. Mismatch between visual motion and vestibular sensation causes simulator sickness, so artificial locomotion, forced camera movement, and low or unstable frame rates must be handled with great care (teleport locomotion, vignetting during movement, maintaining a stable frame rate of 90 Hz or more). Ergonomic fatigue — "gorilla arm" from sustained raised-hand input — limits session design, as does headset weight and heat.
  • Augmented reality must respect the real world. AR content has to be anchored to detected planes and surfaces, occluded correctly by real objects, and lit plausibly, or the illusion collapses. It must also not obscure genuine hazards — a critical concern for industrial and automotive head-up applications.
  • New conventions, few habits. There is no universally learned grammar equivalent to the desktop's menu bar or mobile's back gesture. Onboarding must teach the interaction model explicitly, and designers rely heavily on affordance, spatial audio cues, and physical metaphor to make controls legible.

Illustrative example. A turbine manufacturer deploys a HoloLens maintenance application. A technician looking at a real turbine sees step-by-step instructions anchored beside the relevant component, with an arrow pointing at the bolt to be removed and a remote expert's annotations drawn directly onto the machine. A flat checklist on a tablet would force the technician to look away and mentally map each instruction onto the hardware; the spatial interface removes that translation step entirely.

Why awareness of these platforms matters. It would be easy to treat wearables, voice, and spatial computing as curiosities outside a core HCI module, but there are three strong reasons not to.

  • They are already part of multi-platform products. Banking, fitness, retail, and transport products routinely ship a phone app, a web portal, a watch companion, and a voice skill that must all behave coherently. A designer who understands only screens cannot design that ecosystem.
  • They sharpen understanding of the primary platforms. Thinking about a two-second glance on a watch clarifies what "primary action" really means on a phone. Designing a dialogue without visuals exposes how much a GUI leans on recognition rather than recall. Spatial design makes explicit the assumptions about depth, scale, and proximity that flat design hides.
  • Professional practice evolves. The dominant platform of a graduate's mid-career may not yet exist. What transfers is not knowledge of a particular SDK but the analytical habit of asking: what are the input channels, what are the output channels, what is the attention budget, what is the physical context, and what does the user already know?

Platform Categories: Mobile, Desktop, and Web

Beneath the individual platforms lie three broad categories, each with a coherent interaction model. Grouping platforms this way is analytically useful because most human factors reasoning operates at the category level: the differences between Android and iOS are real but comparatively small next to the gulf between any phone and any desktop workstation.

Mobile: touch, portability, and the interrupted context. Mobile platforms (Android and iOS, plus tablets) are defined by three intertwined characteristics.

Touch as the primary input. The finger is a blunt instrument. Human fingertip contact areas lead both Apple and Google to recommend minimum touch targets of roughly 44×44 points and 48×48 dp respectively, with adequate spacing between them — a constraint that immediately limits how many controls can share a screen. Touch also removes the hover state entirely, so tooltips and preview-on-hover must be replaced with explicit affordances, long-press menus, or progressive disclosure. The finger occludes what it touches, so feedback (a selected state, a ripple, a toast) must appear where it remains visible. In compensation, touch enables direct manipulation that no mouse matches: pinch-to-zoom, swipe-to-delete, drag-to-reorder, and pull-to-refresh feel physical because the user's hand is literally on the object. Reachability matters too — the one-handed thumb arc covers only part of a modern large display, which is why primary navigation migrated from top tab bars to bottom bars and why destructive actions are placed away from the thumb's resting zone.

Portability and sensor richness. A phone travels with the user, which gives it GPS, accelerometer, gyroscope, compass, camera, microphone, NFC, biometric sensors, and a persistent network connection. This makes genuinely context-aware experiences possible — a transport app that defaults to the nearest stop, a payment app that authenticates with a fingerprint, a camera-based document scanner. It also means the device is used in bright sunlight, in the dark, in motion, in cold weather with gloves, and in public where privacy is limited. Contrast ratios, text sizing, dark mode, and the handling of sensitive on-screen content all follow from this.

Fragmented attention and short sessions. Mobile sessions are frequently measured in seconds to a few minutes and are routinely interrupted by calls, notifications, and the world. Interfaces must therefore preserve state aggressively, allow a task to be resumed exactly where it was abandoned, minimise the number of steps to the core action, reduce typing (through autofill, sensible keyboard types, scanning, and platform sign-in), and tolerate sudden connectivity loss. Battery and data consumption are user-visible costs. The design consequence is a strong bias towards one primary task per screen, shallow hierarchies, and ruthless prioritisation of content.

Desktop: precision, density, and sustained expert work. Desktop platforms invert almost every mobile assumption. Input is precise — a mouse or trackpad can target a few pixels, and hover provides a whole extra interaction state used for tooltips, previews, drag handles, and contextual affordances. The keyboard is a first-class input device, enabling shortcuts, mnemonics, tab-order navigation, and command palettes that let practised users operate an application far faster than any pointing device allows; this is why Fitts's Law reasoning on the desktop concerns itself with screen edges and corners (infinitely wide targets) in a way it cannot on touch.

Screen area is large and often multiplied across monitors, which supports simultaneous display of many panels, toolbars, inspectors, and documents. Multi-window workflows — comparing two files, dragging data from one application into another, keeping reference material visible while writing — are the normal mode of work, so applications must handle arbitrary resizing, remember layout, and participate in the system clipboard and drag-and-drop. Sessions are long and seated: a user may spend six hours in the same tool, which justifies a steeper learning curve, richer feature sets, customisable workspaces, and interface density that would be hostile on a phone. Deep operating-system integration — the file system, peripherals, background services, printing, local networking — is expected and is often the whole reason a desktop application exists.

The human factors profile differs accordingly: the designer worries less about thumb reach and more about visual search in dense layouts, consistency of command structure across hundreds of functions, discoverability of advanced features, repetitive strain and posture over long sessions, and supporting the transition from novice to expert through layered interfaces (menus for discovery, shortcuts for speed).

Web: reach, accessibility, and the unknown client. The web is a category rather than a device because the same application may be met on a 32-inch monitor with a mouse and on a 5-inch phone with a thumb. Its defining human factors concern is therefore uncertainty about the client: unknown screen size, unknown input modality, unknown browser, unknown connection speed, unknown assistive technology. Responsive design, fluid layouts, breakpoint strategy, and input-agnostic controls (large enough for a finger, keyboard-operable for a screen-reader user, hover-enhanced but not hover-dependent) are the direct answer to that uncertainty.

Accessibility is more mature and more often legally mandated on the web than anywhere else. Semantic HTML, correct heading structure, labelled form controls, visible focus indicators, sufficient colour contrast, and ARIA where native semantics fall short are the baseline, measured against WCAG success criteria. Performance is a usability issue in a way it is not for installed software, because the application must be downloaded before it can be used: perceived latency, page weight, and loading feedback directly determine abandonment. Navigation must respect web conventions that users have internalised for decades — the back button must work, URLs must reflect state, links must look like links, and the browser's own chrome (zoom, find-in-page, reader mode, translation) must not be broken by the application. Finally, the browser sandbox limits hardware access and background work, so capability-sensitive features need progressive enhancement and graceful degradation.

The table below contrasts the three categories on the human factors dimensions that most shape design decisions.

Human factors dimension Mobile Desktop Web
Primary input and precision Finger touch; low precision; no hover Mouse and keyboard; pixel precision; hover available Unknown — must support both touch and pointer
Minimum target size ~44 pt (iOS) / ~48 dp (Android) Can be very small; edges and corners exploitable Must assume touch sizing unless input is detected
Screen real estate Small, portrait-dominant, one task per view Large, often multi-monitor, many panes Anything from 320 px to ultra-wide
Information density Low — prioritise ruthlessly High — density aids expert productivity Adaptive — must reflow across breakpoints
Typical session length and attention Seconds to minutes; interrupted; mobile context Minutes to hours; focused; seated Highly variable; often task-driven and brief
Text entry Slow and error-prone; minimise typing Fast; full keyboard; shortcuts expected Depends on client; design for the slower case
Environmental factors Glare, motion, noise, gloves, public settings Stable lighting, posture, RSI over long use All of the above, plus variable network quality
Navigation model Bottom tabs, stack-based back, gestures Menus, toolbars, panes, keyboard commands URLs, links, browser back, breadcrumbs
Capability access Rich sensors; permission-gated Deepest OS and peripheral access Sandboxed and inconsistent across browsers
Dominant accessibility concern Dynamic type, contrast, screen reader gestures Keyboard operability, focus order, magnification WCAG conformance, semantics, assistive tech support

These categories are converging at the edges, and a mature designer holds that nuance. Tablets and 2-in-1 convertibles sit between mobile and desktop and may receive touch, pen, keyboard, and mouse input in the same session, so both target sizing and hover behaviour must be handled adaptively. Cross-platform frameworks such as Flutter, React Native, .NET MAUI, and Electron let one codebase address several categories — but a shared codebase is not a shared design; a toolbar that works on Windows will not work on a phone, and failing to adapt produces the familiar "lowest common denominator" application that feels native nowhere. Progressive Web Apps blur the web/native boundary from the other direction. The practical conclusion is that platform categories are a reasoning tool for identifying constraints, not boxes to be obeyed: the designer's job is to identify, for the specific product and audience, which input channels, attention budgets, environmental conditions, and user expectations actually apply, and to let those drive the interface.

A worked comparison. Consider a single product idea — an expense-reporting system for a consulting firm — expressed on each category. On mobile, the consultant photographs a receipt in a taxi: one screen, camera-first, automatic OCR, a single confirm button, works offline and syncs later. On desktop, the finance officer reconciles 400 claims: a dense sortable grid, bulk selection with shift-click, keyboard-driven approval, side-by-side receipt preview, export to the accounting package, multi-monitor friendly. On the web, a project manager approves their team's claims from a client's loaner laptop: no installation, link straight from the notification email, responsive layout that works at any window size, fully keyboard and screen-reader operable. Same data, same business process, three fundamentally different interfaces — which is precisely why platform analysis precedes interface design.

Alignment with Learning Outcomes

  • MO1: Directly supported. The topic sets out the HCI design constraints of Android, iOS, Windows desktop, and the web — input precision, target sizing, screen real estate, attention budget, environmental context, capability access, and accessibility expectations — and the comparison tables provide an explicit framework for contrasting mobile, web, and desktop platforms against target user needs such as global reach, enterprise workflow, or premium consumer experience.
  • MO2: Strongly supported as groundwork. The platform profiles, trade-off tables, and worked examples supply the evidence base (audience, device diversity, distribution, update control, hardware access, monetisation) that a student needs in order to choose a platform and defend that choice against stated project requirements; the actual selection and justification exercise is carried out in later work.
  • MO3: Supported indirectly. The topic surfaces the platform-derived constraints — review processes, fragmentation, offline requirements, accessibility mandates, enterprise deployment limits — that must be recorded in a project scope document, but it does not itself teach the structure of scope documents, objectives, or success criteria.
NotesFigures such as market share, OS adoption rates, and desktop share are given as approximate orders of magnitude rather than precise current statistics, since they shift year to year; students should verify current figures from StatCounter, Apple's developer support page, or Google's distribution dashboard when citing them in assessed work. Touch target recommendations are quoted from the Apple Human Interface Guidelines (44×44 pt) and Material Design (48×48 dp) and are stable long-standing guidance. The VR frame-rate figure (90 Hz) reflects common comfort guidance; specific headsets vary (72–120 Hz). Suggested teaching activity: give students the expense-reporting scenario at the end and have them sketch the three category-specific interfaces before revealing the worked comparison.
2

Videos on This Topic

▶

Before you design an interface, you have to decide where it will live. This topic surveys the four primary platforms used in this course — Android, iOS, Windows, and Web — and then widens the view to additional platforms you may encounter in practice, such as macOS, Linux, wearables, smart TVs, automotive displays, and embedded or kiosk systems. Each platform brings its own screen sizes, input methods, interaction conventions, distribution channels, and user expectations, and those differences drive real design decisions.

It also helps to think in categories rather than product names. Mobile platforms assume touch, small screens, interruptions, and on-the-go use. Desktop platforms assume keyboard and mouse, larger screens, and longer focused sessions. Web platforms assume a browser, variable screen sizes, and near-universal reach at the cost of some device integration. Recognizing which category your project falls into is the first step toward justifying a platform choice in your scope document.

The videos below are practical tours of widely used platform ecosystems. As you watch, pay less attention to the specific button clicks and more to the platform-level questions: What device and input method is this software designed for? Does it run in a browser, as an installed desktop application, as a mobile app, or as all three? How does the interface change across those versions, and what does that suggest about the constraints a designer must respect on each platform?

3

Video 1: All the Microsoft 365 Apps Explained

▶

Kevin Stratvert · 16:07 · 641,532 views · 4y ago · captions — Watch on YouTube

About this video

Kevin Stratvert walks through the applications included in Microsoft 365, covering what each one is for and how they relate to each other, from Teams and Outlook to collaboration tools like Yammer. Based on the title and description, the video is an orientation to a large ecosystem rather than a deep tutorial on any single app. Expect to see tools that exist simultaneously as desktop programs, web apps, and mobile apps.

Why this video

It is a clear, well-produced tour of a major vendor ecosystem that spans desktop, web, and mobile, which makes it a useful concrete example when comparing platform categories and the Windows platform in particular.

4

Video 2: How to use Microsoft Power Apps - Beginner Tutorial

▶

Kevin Stratvert · 17:18 · 1,620,384 views · 5y ago · captions — Watch on YouTube

About this video

This beginner tutorial introduces Microsoft Power Apps, a low-code environment for building business applications. It is likely to show how an app is assembled, configured, and then made available to users across devices without writing traditional platform-specific code. Watch for how the same app is intended to be consumed on a phone and in a browser.

Why this video

Stratvert is a widely followed, accurate tutorial producer, and the video illustrates the cross-platform build-once/run-anywhere idea that is central to discussing platform selection trade-offs.

5

Video 3: How to use Google Drive - Tutorial for Beginners

▶

Kevin Stratvert · 16:49 · 2,106,426 views · 5y ago · captions — Watch on YouTube

About this video

A step-by-step beginner tutorial on Google Drive, covering file storage and backup, accessing files from different devices, and sharing and collaborating with others. The focus is on a service delivered primarily through the browser with companion apps on other devices. It demonstrates how web-first products handle access, sync, and sharing.

Why this video

It gives you a concrete, familiar example of the Web platform category and shows why browser-based delivery is often chosen for reach and collaboration, directly supporting the mobile/desktop/web comparison.

6

How These Videos Support the Learning Outcomes

▶

Together these videos give you observable examples of software delivered on desktop, web, and mobile, which is the raw material for comparing platforms against HCI constraints and user needs (MO1). Seeing the same vendor ship a browser-based service, an installed suite, and a low-code cross-platform builder makes the trade-offs of each delivery model concrete, so you can argue for a platform choice against your own project requirements rather than by habit (MO2). As you watch, note the constraints and capabilities each platform imposes — those notes feed directly into the objectives, constraints, and success criteria sections of your project scope document (MO3).

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Android Platform: Characteristics and Constraints

1

Android Platform: Characteristics and Constraints

▶

Android is not a single device, a single screen size, or a single version of an operating system — it is an entire ecosystem of hardware, software layers, manufacturer customisations and user expectations that a designer inherits the moment they commit to the platform. Understanding Android as a design target therefore means understanding three interlocking things: what the platform is and who uses it, what visual and interaction conventions users have been trained to expect, and what technical and human constraints will shape, limit, or occasionally rescue a design decision. This topic works through each of those in turn, with concrete examples of how the abstract characteristics translate into real interface choices.

A useful framing is that Android trades consistency for reach. Where a closed ecosystem can guarantee that every device runs a recent OS on one of a handful of screen sizes, Android guarantees almost nothing except the presence of the core framework and, usually, Google's services. In exchange, it offers access to the largest installed base of computing devices on the planet. Every characteristic discussed below is, in some way, a consequence of that trade.

The platform in outline: scale, reach, and audience

Android consistently holds the largest share of the global mobile operating system market — broadly in the region of 70% of smartphones worldwide, with the balance held mainly by iOS. That headline figure hides a far more interesting story for designers, because the share is distributed very unevenly by geography and by income. Android's dominance is overwhelming in India, Brazil, Indonesia, Nigeria, and most of Africa, Latin America and South-East Asia, strong across most of Europe, and comparatively weaker in markets such as the United States, Japan and Australia where iOS holds roughly half or more of the user base.

The practical implications of this distribution are substantial:

  • If your product needs broad or global reach, Android is effectively compulsory. A health service, government portal, or financial-inclusion product aimed at an emerging market that ships iOS-only has excluded the majority of its intended users before the first screen is drawn.
  • If your product targets high-ARPU users in a Western market, the picture is more balanced. Historically, iOS users have spent more per head in app stores, which is why some commercial products still launch iOS-first even though Android has more users.
  • Device tier correlates with user context. A large portion of Android's user base is on entry-level and mid-range hardware, often on metered or intermittent mobile data, frequently with limited storage. Design decisions such as image weight, offline tolerance, and APK/bundle size are not engineering trivia on Android — they are usability decisions.

Android also runs far beyond the phone. The same core platform, with different UI layers and interaction models, appears across a wide family of form factors:

Form factor Typical input Design implications Example use
Smartphone (4.7"–6.9") Touch, one-handed Thumb-reach zones, bottom-anchored primary actions, vertical scrolling Consumer apps, messaging, banking
Tablet / foldable (7"–13") Touch, sometimes stylus or keyboard Two-pane list-detail layouts, drag and drop, multi-window support, fold/unfold continuity Productivity, reading, point-of-sale
Wear OS (smartwatch) Touch, rotary bezel/crown, voice Glanceable content, very short task sessions, large tap targets, high-contrast dark UI Fitness tracking, notifications, payments
Android TV / Google TV D-pad remote, voice Focus-based navigation (no cursor), 10-foot UI with oversized type, strict focus order Streaming, media browsing
Android Automotive / Auto Touch, voice, steering controls Driver-distraction rules, limited task depth, large targets, restricted text Navigation, media, EV charging
Embedded / kiosk (AOSP) Touch, barcode scanner, hardware buttons Single-app lock task mode, no system navigation, durable high-contrast UI Self-service kiosks, logistics handhelds, medical devices

Because Android's source is open (AOSP), manufacturers and system integrators can strip it down and rebuild it for these embedded contexts without Google's involvement at all. This is why Android appears inside airline seat-back entertainment systems, supermarket self-checkouts, warehouse scanners and in-car dashboards. For a designer, the lesson is that "designing for Android" requires a prior question: which Android, on what hardware, held how, by whom?

Material Design as the platform's design language

Google's Material Design is the official design system for Android. It began in 2014 as a metaphor-driven system built around "digital paper" — surfaces that occupy space, cast shadows, and move in physically plausible ways. Material 2 (2018) added heavy theming capability, and Material 3 (also called Material You, from Android 12 onward) added dynamic colour extracted from the user's wallpaper, larger corner radii, revised typography, and a stronger emphasis on personalisation and accessibility.

Material is not a legal requirement — an app can ship any visual language it likes — but it functions as a shared vocabulary. Deviating from it costs users learning effort, so deviation should be a deliberate, justified decision (strong brand identity, a game, a cross-platform product with a unified design system) rather than an accident.

Elevation, shadow and surface hierarchy. The central metaphor is that components sit on a z-axis above the background. Elevation is expressed in density-independent pixels and is communicated through shadow (and, in Material 3, through tonal colour shifts where higher surfaces take on more of the primary colour tint). Elevation is a semantic tool, not decoration: it tells the user what is in front, what is temporary, and what can be dismissed.

Elevation Typical components What it signals to the user
0 dp Background, flat cards on a surface, text buttons Base content plane; part of the page
1–3 dp Cards, raised buttons, search bars, bottom navigation Discrete, tappable objects grouped above the page
6–8 dp Floating action button (FAB), snackbar, bottom sheet Persistent but floating; primary or transient action layer
16–24 dp Navigation drawer, modal dialog, menus Temporary layer that blocks or overlays everything beneath; dismissible

A worked example: in a food-delivery app, the restaurant list items are cards at 1 dp — they feel like objects you can pick up. The "Reorder last meal" FAB sits at 6 dp and casts a visible shadow, so it reads as hovering above the scrolling list and never scrolls away. When the user taps "Filters", a bottom sheet rises to 8 dp with a scrim darkening the content behind, signalling "this is a side task; dismiss it to return". When the app needs confirmation to delete a saved address, a dialog appears at 24 dp with a stronger scrim — the highest layer, demanding resolution before anything else can happen. A designer who puts the delete confirmation in a 1 dp inline card has broken the hierarchy: the user is not told that the decision is blocking.

Navigation patterns. Android has a distinctive navigation model, and the single biggest cause of "this app feels wrong on Android" is importing another platform's model wholesale.

  • Bottom navigation bar — for three to five top-level, equally important destinations that users switch between frequently. It sits within thumb reach, is always visible, and each destination maintains its own back stack. Use it when the destinations are peers (Home, Search, Orders, Account). Do not use it for actions — a bottom bar item is a place, not a verb.
  • Navigation drawer — a panel sliding in from the leading edge, for five or more destinations, or for secondary destinations that don't deserve permanent screen space (Settings, Help, Archived items). Its weakness is discoverability: content hidden behind a "hamburger" is demonstrably used less than content on a visible tab bar. Modern Android practice is to pair a bottom bar for the top three to five destinations with a drawer or an overflow for the long tail.
  • Navigation rail — the tablet/foldable/desktop-sized equivalent of a bottom bar, running vertically down the leading edge. Material 3's adaptive guidance expects an app to switch from bottom bar to rail to permanent drawer as the window width increases.
  • Top app bar — holds the screen title, an up arrow for hierarchical ascent, and contextual actions plus an overflow menu. Note the crucial distinction between Up (the arrow in the app bar: moves one level up the app's information hierarchy) and Back (the system gesture/button: moves one step backwards through the user's actual history, which may include other apps).
  • Back navigation — the defining Android convention. Originally a hardware key, then an on-screen button in the system navigation bar, and since Android 10 a gesture: an inward swipe from the left or right screen edge. Android 13+ adds predictive back, which animates a preview of the destination as the user drags, so they can see where back will take them and cancel if it is wrong. Apps must declare support for this and handle back correctly. The cardinal rule is: back must always work, and it must never be surprising. Back should dismiss a dialog or bottom sheet, collapse an expanded search field, close the drawer, step back through the navigation history, and ultimately exit the app. An app that swallows the back gesture, or that uses it to delete data, violates the most deeply learned habit Android users have.

The edge-swipe back gesture also imposes a layout constraint: horizontally draggable content placed hard against the screen edge (a carousel, a swipeable map, a slider) will compete with the system gesture. The remedy is either inset the component from the edge or explicitly declare a gesture exclusion zone.

Design tokens: typography, colour, spacing. Material 3 is token-based. Rather than specifying "18 sp bold, #1A73E8, 16 px padding" on each component, the designer assigns a semantic role, and the theme resolves that role to a value. This is what makes dark mode, dynamic colour, and brand re-theming tractable rather than a per-screen rewrite.

The colour system is built from a small number of source colours expanded into tonal palettes of 13 steps (0 = black, 100 = white), from which role pairs are derived:

Token role Purpose Paired "on" token
primary Highest-emphasis actions: filled buttons, active states, FAB onPrimary — guaranteed-contrast content colour
secondary / tertiary Less prominent components; accent and contrast balance onSecondary / onTertiary
surface, surfaceVariant Backgrounds for cards, sheets, menus, app bars onSurface, onSurfaceVariant
error Validation failures, destructive confirmation onError
outline Borders, dividers, text-field strokes —

The "on" pairing is an accessibility device: because each pair is generated from tonal steps a fixed distance apart, text placed on its paired surface meets contrast requirements automatically in both light and dark themes. A designer who hand-picks a hex value for body text instead of using onSurface has quietly opted out of that guarantee, and will usually discover the failure only when a user with low vision enables dark mode.

Typography works the same way, with a role scale rather than ad-hoc sizes:

Type role Typical size (Material 3 defaults) Used for
Display large / medium / small57 / 45 / 36 spShort, high-impact hero text; rarely used in dense apps
Headline large / medium / small32 / 28 / 24 spScreen or section titles
Title large / medium / small22 / 16 / 14 spApp bar titles, card headers, list item primary text
Body large / medium / small16 / 14 / 12 spRunning text, descriptions, supporting copy
Label large / medium / small14 / 12 / 11 spButtons, tabs, chips, captions

Note the unit: sp (scale-independent pixels) for text, dp (density-independent pixels) for everything else. The difference matters enormously. 1 dp equals one physical pixel on a 160 dpi baseline screen and is scaled by the device's density bucket, so a 48 dp button is roughly 9 mm physically on any device. An sp value does the same and is multiplied by the user's font-size preference, which can reach 200% on modern Android. Hard-coding text in dp is a common and serious accessibility bug: it silently ignores a user's explicit request for bigger type.

Spacing uses a 4 dp base grid, with 8 dp as the common working increment: 4, 8, 12, 16, 24, 32, 48. Screen margins are typically 16 dp on compact phones and 24 dp on larger windows. Two other spacing rules carry direct usability weight: minimum touch target size is 48 × 48 dp (about 9 mm, derived from average fingertip contact area), and adjacent targets should be separated by at least 8 dp to reduce mis-taps.

Expressed as tokens, a card in a theme file might look like this — the point being that nothing in the component itself names a colour or a font:

// Material 3 theme tokens (conceptual)
md.sys.color.surface-container  = palette.neutral-94    // light theme
md.sys.color.on-surface         = palette.neutral-10
md.sys.color.primary            = palette.primary-40
md.sys.shape.corner.medium      = 12dp
md.sys.typescale.title-medium   = Roboto Medium 16sp / 24sp line-height
md.sys.spacing.card-padding     = 16dp

<Card
    surface   = md.sys.color.surface-container
    corner    = md.sys.shape.corner.medium
    elevation = 1dp
    padding   = md.sys.spacing.card-padding >
  <Text style = md.sys.typescale.title-medium
        color = md.sys.color.on-surface />
</Card>

Switching to dark theme, or letting Material You extract primary from the user's wallpaper, re-resolves every token at once. This is why token discipline is a design responsibility and not just an engineering convenience.

Adaptive layout. Because Android window sizes range from a 1" watch face to a 13" tablet in split-screen with a keyboard attached, Material defines window size classes based on available window width (not physical screen width — a phone app in multi-window mode may be "compact" on a tablet):

Window size class Width (dp) Typical device state Recommended layout & navigation
Compact < 600 Phone portrait; folded foldable Single pane, vertical scroll, bottom navigation bar
Medium 600–839 Phone landscape, small tablet portrait, unfolded inner screen Single or two-pane, navigation rail, wider margins
Expanded ≥ 840 Tablet landscape, ChromeOS/desktop window, large foldable Two- or three-pane list-detail, permanent navigation drawer, supporting pane

The canonical adaptive example is the list-detail pattern. An email client in compact width shows the inbox list; tapping a message navigates to a full-screen reading view, and back returns to the list. The same app in expanded width shows list and message side by side, so tapping an item swaps the detail pane and back now exits the screen rather than returning to the list. Both behaviours are correct for their context, and a design that fails to adapt produces either a cramped tablet experience (a single column of list items stretched to 1000 dp wide, with 20-word line lengths that are painful to read) or an unusable phone experience.

Foldables add continuity requirements: when a user unfolds a device mid-task, the app is destroyed and recreated at a new size by default, so state must be preserved and the layout must reflow without losing scroll position, typed text, or video playback point. Table-top postures (half-folded, hinge horizontal) suggest splitting content above the fold and controls below — a video player putting the picture on the upper half and transport controls on the lower half is the standard illustration.

Constraints the designer must plan around

1. Screen size, density and aspect ratio fragmentation. Android devices span roughly 320 dp to 1280 dp of width, densities from ldpi through to xxxhdpi (roughly 120–640 dpi), and aspect ratios from 4:3 tablets to 21:9 "cinema" phones. On top of that sit cut-outs (notches, punch-holes), curved edges, rounded corners, and system bars that may be gesture pills or three-button bars of different heights.

  • Design in dp, never in pixels. Supply vector drawables where possible so icons scale cleanly; provide raster assets in density buckets (mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi) when raster is unavoidable.
  • Use constraint- or flex-based layouts rather than fixed positions. A design that pins a button "240 dp from the top" will float oddly on a tall device and overlap content on a short one.
  • Respect insets. Modern Android apps draw edge-to-edge behind translucent system bars, then apply window insets as padding so nothing important sits under a notch, the status bar, the navigation pill, or the on-screen keyboard. Forgetting keyboard (IME) insets is the classic bug where the "Submit" button is hidden behind the keyboard the moment the user types.
  • Test the extremes, not the average. A sensible test matrix is one small low-density phone (around 320–360 dp wide), one mainstream phone, one tall 20:9 device, one tablet in landscape, and one device at 200% font scale with display size enlarged.

2. OS version fragmentation and API availability. Unlike a closed ecosystem where a new OS reaches most devices within months, Android updates depend on the chipset vendor, the manufacturer, and sometimes the carrier. Although Project Treble, Mainline modules and longer vendor support commitments have improved matters significantly, a large installed base typically sits several versions behind the latest release, and budget devices may never receive a major upgrade.

Two numbers govern this in practice: minSdk (the oldest OS the app will install on, which defines your reachable audience) and targetSdk (the version whose behaviours the app opts into, which Google Play forces upward over time). Lowering minSdk widens reach but increases the cost of testing, back-porting and conditional code.

The design consequences are concrete, because many of the features designers reach for are version-gated:

Feature Introduced in Design consequence on older devices
Runtime (in-context) permission prompts Android 6 (API 23) Earlier devices granted everything at install; onboarding copy must not assume a prompt appears
System-wide dark theme Android 10 (API 29) App must ship its own in-app dark toggle if dark mode is a selling point
Gesture navigation Android 10 (API 29) Older devices still show a three-button bar; layouts must tolerate both bar heights
Dynamic colour (Material You) Android 12 (API 31) Needs a designed static fallback palette, so the brand still reads correctly
Per-app language preference Android 13 (API 33) An in-app language picker is required for earlier versions
Granular media permissions (photos/video/audio) Android 13 (API 33) Older devices ask for broad storage access; the request rationale wording must differ
Notification runtime permission Android 13 (API 33) On older versions notifications are on by default; on newer ones the user may simply never see them
Predictive back animations Android 13–14 (API 33+) Back must still be correct and instantaneous without the preview animation
Partial photo access ("Select photos") Android 14 (API 34) Flows must cope with a user granting access to three images rather than the whole library

The disciplined response is progressive enhancement with graceful degradation: design a baseline experience that works on your minSdk, then layer enhancements that are capability-checked at runtime. Jetpack libraries (AppCompat, Material Components, Compose) back-port much of the visual language, so a Material 3 button looks correct on Android 7; but genuine OS capabilities — biometric classes, exact alarms, background location behaviour, photo picker — cannot be conjured and must have designed fallbacks. A worked example: a banking app wants face unlock. On a device with Class 3 biometrics it shows "Sign in with face". On a device with only a fingerprint sensor it shows "Sign in with fingerprint". On a device with neither, it shows a PIN pad — and crucially, the designer has specified all three states rather than leaving the engineer to improvise an error message.

Manufacturer customisation is a second-order version problem. Samsung One UI, Xiaomi HyperOS/MIUI, Oppo ColorOS and others re-skin system components, alter default fonts, change notification behaviour, and — most disruptively — apply aggressive battery optimisation that can kill background work, delay notifications, or cancel scheduled jobs. A design that depends on a reliable daily reminder at 08:00 must therefore include a path that tells the user how to exempt the app, and should degrade to a visible in-app cue rather than silently failing.

3. Hardware capability spread. Android spans a device price range of roughly US$60 to US$2,000, and the gap is not cosmetic. Entry-level devices may have 2–4 GB RAM, slow eMMC storage, a low-end GPU, a 60 Hz LCD, and a modest camera; flagships have 12–16 GB RAM, 120 Hz OLED displays, hardware ML accelerators and multi-lens camera arrays. The same APK must behave acceptably on both.

Capability Entry tier Flagship tier Design response
Memory & CPU 2–4 GB, low-core-count 12 GB+, high-performance cores Avoid heavy blur/parallax; cap animation complexity; paginate long lists; expect the app to be killed in the background and restore state
Display 720p LCD, 60 Hz, poor outdoor contrast 1440p OLED, 120 Hz, HDR Don't rely on subtle shadow or low-contrast greys; honour contrast tokens; keep motion comfortable at 60 Hz
Camera Fixed focus, noisy in low light OIS, multi-lens, computational photography If the app scans documents or QR codes, provide guidance overlays, torch control, manual capture and a file-upload fallback
Sensors May lack gyroscope, NFC, barometer, Class 3 biometrics Full sensor suite, UWB, LiDAR-like depth Feature-detect; never make a sensor-dependent feature the only route to a goal
Storage & network 32–64 GB, metered or 3G data 256 GB+, 5G/Wi-Fi 6 Keep download size small, compress images (WebP/AVIF), cache aggressively, design explicit offline and "data saver" states

Two design habits follow. First, design the slow path, not just the happy path: specify skeleton/loading states, empty states, offline states, failed-image placeholders and retry affordances, because on a mid-tier device on a congested network those states are what the user actually sees most often. Second, treat performance as part of the interface. Research on responsiveness is consistent: under about 100 ms feels instantaneous, up to about 1 second keeps the user's flow of thought, and beyond about 10 seconds attention is lost. A visually immaculate screen that takes four seconds to appear on a budget phone is a worse design than a plainer screen that appears in 400 ms.

4. The permission model and access-request flows. Since Android 6, dangerous permissions are requested at runtime, and the model has tightened steadily: one-time grants ("Only this time"), auto-revocation of permissions for unused apps, "while using the app" versus "all the time" location, approximate versus precise location, granular media permissions, a notification permission, and a system photo picker that lets a user share specific images without granting any storage permission at all.

This is fundamentally a design problem, not an engineering one, because the system dialog is terse, non-negotiable, and easily dismissed. The established pattern has four stages:

  • Ask in context, not at launch. A permission wall on first open is the single most common Android onboarding mistake. Request camera access at the moment the user taps "Scan receipt", when the benefit is self-evident.
  • Provide a pre-permission rationale screen when the reason is not obvious. This is a screen you control, so it can explain the value in plain language and offer a "Not now" exit that costs the user nothing. Crucially, it preserves the system prompt for a moment when the user is likely to accept — once they deny twice, Android treats it as a permanent denial and the system dialog will not appear again.
  • Design the denied state as a first-class screen. If location is denied, a delivery app should still allow manual address entry; a weather app should offer city search. "This app requires location to continue" with a dead end is a design failure.
  • Offer a recovery route. For permanently denied permissions the only path is system Settings, so provide an inline explanation plus a button that deep-links to the app's settings page, and re-check the state on resume.

A concrete flow for a photo-sharing feature illustrates the difference. The naive version launches, immediately requests storage, and is denied by a cautious user who now cannot upload anything. The considered version shows an "Add photo" button; on tap, it offers "Choose from library" (which uses the system photo picker and needs no permission at all) and "Take a photo" (which requests camera in context, with a one-line rationale if the user previously declined). If the user grants access to only three photos under Android 14's partial access, the UI displays those three plus a visible "Manage selected photos" affordance rather than pretending the library is empty. Each branch has been designed, so no branch produces a dead end.

Permissions also interact with trust. Android surfaces privacy indicators (the camera/microphone dot), a Privacy Dashboard, and Play Store Data Safety declarations, so over-requesting is now visible to users and penalised in reviews. The design rule is to request the minimum permission that achieves the goal: approximate rather than precise location for a store locator; the photo picker rather than full media access; a foreground-only location grant unless background tracking is genuinely the product.

Pulling the constraints together

None of these constraints is independently fatal, but together they define a design posture. A well-designed Android product is adaptive (window size classes rather than fixed screens), tolerant (feature detection with designed fallbacks rather than assumed capabilities), economical (modest assets, fast first paint, offline-aware), conventional where convention is cheap (back behaviour, navigation patterns, touch targets, type scale) and distinctive where distinction earns its keep (brand colour, illustration, signature interactions). A useful pre-build checklist is: what is our minSdk and what percentage of the target market does it exclude; which three device profiles define our test matrix; which permissions do we request, in what order, and what does each denied state look like; how does every screen behave at 600 dp and 840 dp; and what does this look like at 200% font scale in dark mode on a 720p LCD in sunlight?

Alignment with Learning Outcomes

  • MO1 — The topic supplies the Android half of a platform comparison, detailing the HCI design constraints that distinguish it (device and OS fragmentation, dp/sp density independence, runtime permissions, back-gesture conventions, hardware-tier spread) and the audience characteristics (global reach, emerging-market dominance, mid- and entry-tier hardware) that must be weighed against web and desktop alternatives.
  • MO2 — By setting out concrete, evidence-based criteria such as market reach by region, minSdk versus audience coverage, capability availability by API level, and performance expectations on budget hardware, the topic gives students the factual basis needed to argue for or against Android as the platform for a given set of project requirements.
  • MO3 — The constraints discussed translate directly into scope-document content: Android-specific constraints (supported OS versions, window size classes, permission handling, offline tolerance) and measurable success criteria (touch-target compliance, contrast and font-scaling support, time-to-first-paint on a defined reference device) that can be stated as objectives and acceptance thresholds.
NotesMarket-share, API-level and device-tier figures are indicative and shift over time; verify against current Google Play distribution data, StatCounter, and the Material 3 guidelines before teaching. Material 3 "Expressive" guidance and newer Android releases may update token names, type scale defaults and adaptive-layout recommendations, so treat specific dp/sp values as representative defaults rather than fixed standards. Suggested classroom activities: audit a popular app against the back/Up distinction and the 48 dp touch-target rule; redesign a permission-wall onboarding flow into a contextual request with designed denied states; and reflow a single phone screen into medium and expanded window size classes.
2

Videos on This Topic

▶

Android is the most widely deployed mobile platform in the world, and that reach comes with a particular set of design realities. Unlike a single tightly controlled device family, Android spans thousands of hardware models, screen sizes and densities, OS versions, and manufacturer skins, and it reaches users across a very broad range of regions, budgets and network conditions. Designing for Android therefore means designing for variability rather than for one idealized device.

This topic looks at three things: what the Android platform offers (its component model, system UI patterns, and the Material Design language that sets user expectations), the conventions Android users have learned to rely on (navigation structures, standard components, back behavior, theming and typography), and the constraints you must plan around (fragmentation, performance and memory limits, permissions and privacy, accessibility, and store quality expectations). These constraints are not technical trivia — they shape what your interface can reasonably promise.

The videos below come from the official Android Developers channel. As you watch, listen for the distinction between what the platform gives you for free and what you must decide deliberately. Note how often the answer to a design question on Android is "use the standard component unless you have a strong reason not to," and ask yourself what that implies for the scope and effort estimates in your own project.

3

Video 1: Why use Material Design Components? - MAD Skills

▶

Android Developers · 5:48 · 39,553 views · 5y ago · captions — Watch on YouTube

About this video

A short episode from the MAD Skills series explaining why Google recommends building Android apps with the Material Design Components library rather than hand-rolling UI elements. It is likely to cover what the library provides — themed, consistent, accessible components that follow platform conventions — and the practical benefits of adopting it over custom widgets. Expect discussion of theming, consistency with user expectations, and reduced implementation effort.

Why this video

This maps directly to the Android Design Conventions subtopic: Material Design is the convention Android users expect, and this video explains it from the platform owner's own developer channel.

4

Video 2: Introduction to Android app quality

▶

Android Developers · 4:36 · 16,291 views · 5y ago · captions — Watch on YouTube

About this video

An overview of what Google means by Android app quality as user expectations on the platform have risen, spanning areas such as privacy, user experience, performance and compatibility. It likely introduces the quality framework that apps are measured against on the Play Store and why meeting it matters for adoption and ratings. Treat it as a checklist of the non-negotiables a designer should account for early.

Why this video

It frames the Android Constraints and Considerations subtopic well, showing that constraints come not only from hardware but from platform-level quality and privacy expectations that must be scoped from the start.

5

Video 3: Android app quality: Visual experience

▶

Android Developers · 3:28 · 9,918 views · 5y ago · captions — Watch on YouTube

About this video

A focused look at the visual side of Android app quality — how layout, visual polish and adherence to platform visual norms shape users' first impression of an app. Expect attention to issues like rendering across different screen sizes and densities, respecting system UI such as status and navigation bars, and avoiding visual defects. It is a brief, concrete companion to the broader quality overview.

Why this video

It connects the Android Platform Overview and design conventions subtopics by showing how device variability translates into specific visual design obligations, in a concise and authoritative format.

6

How These Videos Support the Learning Outcomes

▶

Together these videos give you the Android half of the platform comparison required by MO1: they make explicit the design constraints — device fragmentation, visual and quality expectations, privacy requirements, and a prescribed design language — that distinguish Android from web and desktop targets. For MO2, the quality overview and Material Design rationale supply concrete, citable reasons you can use to justify choosing or rejecting Android against your project requirements. For MO3, the quality and visual-experience videos function as a source of realistic constraints and success criteria to write into your scope document, rather than discovering them late in development.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

iOS Platform: Characteristics and Constraints

1

iOS Platform: Characteristics and Constraints

▶

iOS is Apple's mobile operating system, running on iPhone, iPad (as iPadOS, a close derivative), and — through shared frameworks and design language — influencing watchOS, tvOS, and visionOS. For an interface designer, iOS is best understood not simply as a technical runtime but as a tightly coupled system of hardware, software, design doctrine, distribution rules, and user expectations. Each of those layers imposes characteristics you can exploit and constraints you must design around. A design that ignores the Human Interface Guidelines (HIG), the App Store review process, or the spread of screen geometries will either feel alien to users, fail review, or break on devices you did not anticipate. This topic examines the platform in three movements: who the users are and what the ecosystem looks like, what the design conventions actually prescribe, and where the hard constraints lie.

The platform as an ecosystem. Unlike Android, where hardware comes from dozens of manufacturers at every price point, iOS runs only on Apple-manufactured hardware. Apple designs the silicon (the A-series and M-series chips), the display, the operating system, the developer frameworks (UIKit and SwiftUI), the IDE (Xcode), and the only sanctioned distribution channel on most of the world's devices (the App Store). This vertical integration is the single fact from which most other iOS characteristics follow.

A premium device segment and an engaged user base. iPhones sit at the higher end of the smartphone price range, and the demographic consequences are measurable and consistent across markets. iOS users, on average, skew toward higher household income, higher urban concentration, and markets such as the United States, the United Kingdom, Japan, Australia, and Western Europe. The behavioural consequence matters more to designers than the demographic one: iOS users historically spend substantially more per capita on apps and in-app purchases than Android users, despite Android's much larger global install base. For a product team, this shapes monetisation strategy (paid apps and subscription tiers are more viable on iOS), content strategy (users are more tolerant of premium pricing but less tolerant of intrusive advertising), and feature strategy (users update their OS quickly, so new APIs become usable sooner).

Consider a hypothetical fitness-tracking startup with a limited budget that can only build for one platform at launch. If the business model is a £9.99/month subscription aimed at affluent urban professionals in London and New York, iOS-first is the defensible choice: the audience concentration, the payment willingness, and the Apple Watch and HealthKit integrations all align. If instead the product is an ad-supported utility targeting emerging markets in South and Southeast Asia, the same reasoning points firmly to Android. The platform choice is a user-research decision, not a technical preference.

The Human Interface Guidelines as design law. The HIG is Apple's published specification of how iOS interfaces should look and behave. It is documentation, not a compiler — nothing stops you from building a non-conforming interface — but it functions as a quasi-legal standard for three reasons. First, Apple's own system apps (Mail, Settings, Messages, Photos) implement it, so users have been trained on it continuously for over a decade. Second, the standard UIKit and SwiftUI components implement it by default, so conformance is the path of least engineering resistance. Third, App Store reviewers cite it when rejecting apps whose interfaces are confusing, misleading, or sufficiently unconventional to harm users.

The HIG is organised around a small set of design themes that recur throughout Apple's platforms:

PrincipleWhat it prescribesConcrete design implication
ClarityText is legible at every size, icons are precise, ornamentation is subtle, and functional elements are unambiguous.Favour a clear label over a clever icon; use negative space and typographic weight rather than borders and boxes to create hierarchy.
DeferenceThe UI helps users understand and interact with content, but never competes with it.Translucent, lightweight chrome; content extends edge-to-edge; avoid heavy skeuomorphic decoration.
DepthVisual layers and realistic motion convey hierarchy and give users a sense of place.Push transitions slide horizontally to signal "deeper"; modal sheets slide up from the bottom to signal "temporary and separate".

Clarity in practice. Clarity means a user looking at a control should know, without experimentation, what it does and what will happen if they touch it. Several concrete rules follow. Touch targets should be at least 44×44 points so they can be hit reliably with a thumb. Destructive actions are rendered in red and, where consequences are irreversible, confirmed with an action sheet. Labels use sentence-style or title-style capitalisation consistently. Icons that have accrued conventional meaning — the square-with-upward-arrow Share icon, the trash can, the magnifying glass — should be used for those meanings and nothing else. A frequent clarity failure in novice work is the "mystery meat" toolbar: a row of five custom glyphs with no labels, where the designer understands each one and no user does. The remedy is either a standard SF Symbol with an established meaning, or an icon paired with a short text label.

Tab bars as the primary top-level navigation. iOS resolves the problem of top-level navigation with the tab bar: a persistent horizontal bar pinned to the bottom of the screen containing three to five items, each with an icon and a short label, where the selected item is tinted with the app's accent colour. The pattern is load-bearing in iOS design because it makes the app's entire top-level structure visible at all times and places it within thumb reach at the bottom of the display. Compare Apple Music (Home, New, Radio, Library, Search), the App Store (Today, Games, Apps, Arcade, Search), or Clock (World Clock, Alarms, Stopwatch, Timers).

The design rules that accompany the pattern are strict. Tabs represent peer sections of equal importance, not steps in a sequence; a tab bar must never be used as a wizard. Each tab maintains its own independent navigation stack, so a user who drills three levels deep into Library, switches to Search, and returns to Library expects to find it exactly as they left it. Tabs should not be used for actions — a "Compose" tab that opens a modal violates the mental model that tabs switch between destinations. Five items is the practical maximum on iPhone; a sixth or beyond collapses into an automatic "More" tab containing a list, which is a usability compromise you should design your way out of rather than accept. If your app genuinely has eight top-level sections, that is usually a signal that your information architecture needs consolidation, not that you need a More tab.

Where a tab bar does not fit, iOS offers alternatives with their own conventions: a hierarchical drill-down using a navigation stack (Settings is the archetype), a sidebar on iPad and in wider layouts, or a page-based flat structure with a page control. Notably, the hamburger/drawer menu that dominates Android's Material Design is not an iOS convention and is widely regarded as a poor fit — it hides structure, is difficult to reach on large devices, and conflicts with the edge-swipe gesture.

Gesture-based navigation. Gestures are not decorative extras on iOS; several of them are load-bearing navigation mechanisms that users rely on unconsciously. The most important is the interactive pop gesture: swiping right from the left edge of the screen pops the current view off the navigation stack and returns to the previous screen, mirroring the back button in the navigation bar. It is interactive and reversible — the outgoing screen tracks the finger, and releasing it midway cancels the transition. Since the removal of the physical Home button, the system itself also claims gestures: swiping up from the bottom edge goes Home, swiping up and pausing opens the App Switcher, and swiping along the bottom Home indicator switches between recent apps.

The design consequence is that the screen edges are system territory, and any custom gesture you place there will fight the operating system and lose. A common failure is placing a horizontally scrolling carousel flush against the left edge: users attempting a back-swipe scroll the carousel instead, or vice versa, and the interaction feels broken. Mitigations include insetting such content from the edge, or deliberately disabling the pop gesture only for screens where it would cause data loss (for example, a multi-step form) — in which case you must provide an equally obvious alternative such as an explicit "Cancel" button. Other conventional gestures that users expect to work include pull-to-refresh on scrollable lists, swipe-left-on-a-row to reveal Delete and other contextual actions, long-press to open a context menu or preview, and pinch-to-zoom on images and maps. Honouring these costs little and failing to honour them makes an app feel subtly foreign.

Typography: San Francisco and Dynamic Type. The iOS system font is San Francisco (SF), a neutral humanist sans-serif that Apple designed specifically for screen legibility across sizes. SF Pro Text and SF Pro Display are optically distinct cuts — the Text variant has looser spacing and larger apertures for small sizes, the Display variant tighter spacing for headlines — and iOS switches between them automatically. SF also ships with companion families: SF Mono for code, SF Rounded for a softer tone, and SF Symbols, a library of several thousand icons that are metrically and visually matched to the font, so a symbol placed inline with text aligns to the same baseline and scales with the same weight.

The more consequential typographic system is Dynamic Type. Rather than specifying fixed point sizes, iOS designers specify semantic text styles — Large Title, Title 1/2/3, Headline, Body, Callout, Subhead, Footnote, Caption 1/2 — and the system resolves each to a concrete size based on the user's preferred reading size, which they set in Settings and can push far beyond the default into the Accessibility Larger Text range. A user with low vision may be reading your interface at roughly twice the default body size.

Text styleDefault size (points)Typical use
Large Title34Top of a scroll view in a navigation stack
Title 128Primary screen heading
Headline17 (semibold)Row titles, emphasised labels
Body17Running text, list content
Footnote13Secondary explanatory text
Caption 112Image captions, metadata

Designing for Dynamic Type means designing layouts that grow. Fixed-height rows break; labels that are allowed to wrap to multiple lines do not. Horizontal pairings — icon, title, and trailing value on one line — often need to reflow into a vertical stack at accessibility sizes. A practical discipline is to mock up every key screen three times: at the smallest size, at the default, and at the largest accessibility size, on the smallest supported device. In SwiftUI this is close to free, because text styles and stack layouts adapt by default:

Text("Monthly summary")
    .font(.headline)          // semantic style, not a fixed 17pt
Text(summaryBody)
    .font(.body)
    .fixedSize(horizontal: false, vertical: true)  // allow wrapping, never truncate

Hard-coding .font(.system(size: 17)) opts the text out of Dynamic Type entirely and is one of the most common accessibility defects in shipping iOS apps.

The controlled hardware ecosystem and its testing dividend. Because Apple makes every device, the test matrix for an iOS app is finite and knowable. A team supporting the current and two previous iOS major versions might realistically cover the field with six to ten physical devices plus the Simulator — for example a small iPhone (SE), a standard iPhone, a Pro Max, an iPad, an iPad Pro, and one older device representing the minimum supported hardware. Contrast this with Android, where the same coverage ambition confronts thousands of device models, dozens of manufacturer UI skins, wildly varying GPU and camera capabilities, and aggressive vendor-specific background-process killing. The practical effect is that iOS QA budgets are smaller, device-specific bug classes are rarer, and designers can reason with confidence about colour reproduction (most modern iPhones use OLED with the P3 wide colour gamut), refresh rate (ProMotion up to 120 Hz on Pro models), and haptic capability (the Taptic Engine is present on all current iPhones). You can design a haptic feedback moment into a confirmation interaction and be confident it will actually be felt.

This dividend is real but should not be overstated. The ecosystem is more fragmented than it once was: foldable-free but spanning Dynamic Island and notch cutouts, Face ID and Touch ID, OLED and LCD, ProMotion and 60 Hz, and the growing divergence of iPadOS with Stage Manager, external display support, Apple Pencil, and hardware keyboards.

User expectations of polish and performance. Apple's brand is built on refinement, and users transfer that expectation to every app on the device. In practice this means the quality bar for an iOS app is set by Apple's own apps and by the best third-party apps in the category, not by what a competitor shipped on another platform. Concretely, users notice and penalise: animation that drops frames or is not interruptible; a launch that shows a spinner instead of a skeleton of the eventual UI; a keyboard that covers the field being typed into; a layout that does not respect the safe area and tucks content under the Dynamic Island or the Home indicator; a Dark Mode that is clearly an afterthought with muddy contrast; and an app that does not restore state after being backgrounded. The reviews on the App Store make this feedback loop visible and commercially consequential. Budgeting time for polish on iOS is not gold-plating, it is table stakes.

Constraint: App Store review. On iOS, distribution is a gatekept process. Every app and every update is submitted to App Store Connect and reviewed against the App Store Review Guidelines, organised into five sections — Safety, Performance, Business, Design, and Legal. Review is partly automated and partly human, usually takes 24–48 hours, and can reject a build outright. Because approval is not guaranteed, review risk must be assessed at the design stage, not discovered at launch. Commonly encountered rules include:

  • Minimum functionality (4.2): apps that are little more than a repackaged website, a single marketing page, or a thin wrapper around existing content are rejected. This directly constrains "just ship our site in a WebView" strategies.
  • In-app purchase (3.1.1): digital goods and subscriptions consumed within the app must be sold through Apple's IAP system, subject to commission. Linking users out to an external payment page has historically been restricted, though regulatory action in the EU, the US, and elsewhere has been forcing change. For a product team, this has a direct effect on pricing, margin, and even whether a subscription business is viable.
  • Sign in with Apple (4.8): if you offer third-party social login, you have generally been required to offer Sign in with Apple as an equivalent option — a concrete, mandatory element on your authentication screen.
  • Account deletion (5.1.1(v)): if your app lets users create an account, it must let them delete it from within the app. That is a whole flow that must appear in your designs and your scope.
  • Design conformance (4.0): copying the appearance of Apple's own apps, using system iconography to mean something other than its standard meaning, or using non-standard interfaces that confuse users can all draw rejection.
  • User-generated content (1.2): apps with UGC must ship with a content filter, a report mechanism, a block mechanism, and a published contact. Again: real screens, real scope.

A worked example: a team designs a language-learning app with a web checkout to avoid Apple's commission, social login via Google only, and a Facebook-style feed with no reporting tools. All three decisions are review failures. Catching them in a design review costs an afternoon; catching them in a rejection two weeks before a marketing launch costs the launch.

Constraint: privacy permissions. iOS treats sensitive capabilities as permissions the user grants at runtime, not at install time. Location, camera, microphone, photo library, contacts, calendars, health data, Bluetooth, local network, notifications, and cross-app tracking all require explicit consent, and the user can revoke any of them at any time in Settings. Two obligations follow.

First, a purpose string is mandatory. Each permission requires a usage-description key in the app's Info.plist, and the text you write there is shown verbatim in the system alert. A missing purpose string causes the app to crash on request and will fail review; a vague one ("This app needs your location") invites denial. Good purpose strings are specific and user-benefit-framed:

<key>NSLocationWhenInUseUsageDescription</key>
<string>We use your location to show cycle routes starting near you.
Your location is never stored on our servers.</string>

Second, because the system alert can only be shown once per permission — a denial sends the user to Settings thereafter — the timing of the request is a design decision of real consequence. The established pattern is priming: never request a permission on first launch or on a cold splash screen. Instead, request it in context, immediately after the user has taken an action that makes the need obvious, optionally preceded by a custom pre-permission screen explaining the benefit and offering a "Not now" that does not burn the system prompt. A photo app should ask for camera access when the user taps the shutter, not during onboarding. You must also design the denied state: what does the screen look like for a user who said no? A blank map with no explanation is a failure; a map centred on a default city with a "Enable location for nearby routes" button that deep-links into Settings is not.

Related constraints include App Tracking Transparency (tracking across other companies' apps and sites requires the ATT prompt, and opt-in rates are low, which undercuts ad-attribution-dependent business models), the limited photo library picker (users can grant access to selected photos only), and Privacy Nutrition Labels plus the privacy manifest, which require you to declare on your App Store page exactly what data you collect and whether it is linked to identity. Those declarations are public, so data-hungry designs carry a reputational cost on the store page itself.

Constraint: multiple device sizes. Although the hardware set is finite, it spans a wide range. An iOS layout must be built with Auto Layout or SwiftUI's adaptive stacks against size classes (compact and regular, in horizontal and vertical dimensions) rather than hard-coded pixel positions, and it must respect the safe area — the inset region that excludes the status bar, the notch or Dynamic Island, and the Home indicator. Representative points in the range:

DeviceLogical size (points, portrait)Design implication
iPhone SE (3rd gen)375 × 667The tightest realistic target; Touch ID, no Dynamic Island, short screen. Long forms and tall cards break here first.
iPhone 15 / 16393 × 852The mainstream case; Dynamic Island cutout at the top, Home indicator at the bottom.
iPhone 15 / 16 Pro Max430 × 932Generous width, but the top of the screen is out of thumb reach — keep primary actions low.
iPad mini744 × 1133Regular width in landscape; a phone layout stretched to this width looks broken.
iPad Pro 12.9"1024 × 1366Sidebar or split-view layouts expected; also Stage Manager, external displays, keyboard and trackpad.

Beyond raw dimensions, iPad adds multitasking: an app can be resized to Split View or Slide Over at essentially arbitrary widths, so a layout must respond to continuous width change, not just to a handful of device presets. A useful heuristic is that an iPhone layout is generally a single column with a tab bar, while an iPad layout at regular width should use the extra space meaningfully — a sidebar for navigation, a master–detail split, a multi-column grid — rather than stretching line lengths to 1000 points, which destroys readability. Orientation is a further axis: unless you have a strong reason to lock it (a game, a camera viewfinder), supporting both orientations is expected, and the keyboard-visible landscape case on a small phone is a notoriously under-tested layout.

Constraint: supporting older iOS versions. Apple's adoption curves are enviable — a new major iOS version typically reaches 70–80% of active devices within a year — but "most" is not "all", and the choice of deployment target (the minimum iOS version your app supports) is an explicit scoping decision with design consequences. Supporting one version back is conservative and cheap; supporting three versions back can cost significant engineering effort and foreclose modern APIs.

The trade-off is concrete. Suppose a design calls for a bottom sheet that can be dragged between a half-height and full-height detent. The system UISheetPresentationController provides this natively from iOS 15, and SwiftUI's presentationDetents from iOS 16. If the projectsets a deployment target of iOS 14, neither is available and the team must either build and maintain a custom sheet component — with its own gesture handling, accessibility, and rotation behaviour — or redesign the interaction as a full-screen modal for everyone. Either way, the version decision has just rewritten the design.

Several techniques make the constraint manageable. Graceful degradation uses availability checks so that newer devices get the richer treatment while older ones fall back to something acceptable rather than broken:

if #available(iOS 16.0, *) {
    sheet.presentationDetents([.medium, .large])   // native drag-to-resize
} else {
    presentModalFullScreen()                        // acceptable fallback
}

Alternatively, a team may choose feature parity at the lowest level — designing only what the oldest supported version can do — which is simpler to test but wastes the platform's newer capabilities. The decision should be driven by data, not instinct: App Store Connect reports the iOS version distribution of your actual installed base, and if 1.5% of your users are on a version that would cost four engineering weeks to support, that is a scope conversation with a defensible answer. Note too that OS version and hardware are coupled on iOS: dropping iOS 15 also drops certain older iPhone and iPad models entirely, which may matter if your audience includes schools, charities, or regions where hand-me-down devices are common. Finally, Apple periodically raises the minimum Xcode and SDK version required for App Store submission, which forces a build-level floor independent of your own deployment target — so "we will support iOS 12 forever" is not a stable position.

Pulling the constraints together. The recurring theme across all three areas — audience, conventions, constraints — is that on iOS, a great deal of design is decided for you, and the skill lies in recognising which decisions are fixed, which are conventional-but-negotiable, and which are genuinely yours. The safe area, the pop gesture, the review guidelines, and the permission model are fixed: design within them. Tab bars, Dynamic Type styles, SF Symbols, and standard transitions are conventional: deviate only with a clear user-centred justification, because conformance buys you learnability for free. Your information architecture, your content, your tone of voice, your accent colour, and your signature interactions are genuinely yours — and because the platform handles so much of the baseline, that is where your effort should concentrate.

A short worked scenario. Imagine scoping an iOS app for a university library: search the catalogue, reserve items, view loans, scan a barcode to renew. Platform reasoning produces a concrete specification almost immediately. The audience includes students on hand-me-down iPhone SEs, so the deployment target reaches back two versions and the smallest layout is tested first. The top level has four peer sections — Search, My Loans, Scan, Account — but Scan is an action, not a destination, so it becomes a prominent button on the Search screen rather than a tab, leaving a clean three-tab bar. Camera access is requested at the moment the user taps "Scan", with the purpose string "Used to scan the barcode on a book so you can renew it instantly", and a manual barcode-entry fallback is designed for users who decline. All typography uses semantic styles, and the loans list is mocked at the largest accessibility size, where each row reflows from a horizontal title-plus-due-date into a two-line vertical stack. Account creation implies an in-app account deletion flow, which is added to the backlog before it becomes a rejection. On iPad, the search results and item detail become a split view rather than a stretched single column. None of these are arbitrary choices; each is traceable to a documented platform characteristic or constraint.

Alignment with Learning Outcomes

  • MO1: This topic supplies the iOS half of a platform comparison by making its HCI design constraints explicit — gesture-reserved screen edges, the safe area and size-class system, Dynamic Type, runtime permissions, and review-imposed design rules — and by characterising the target user base (premium segment, high polish expectations, fast OS adoption, strong paid-app willingness). The repeated contrasts drawn with Android, and with web and desktop conventions such as the hamburger drawer and fixed type sizes, give students concrete axes on which to compare platforms rather than impressions.
  • MO2: The topic equips students to justify selecting or rejecting iOS against defined requirements. Monetisation model, target market and device affordability, need for hardware integrations, QA budget and device-matrix size, tolerance for gatekept distribution, and dependence on cross-app tracking are each presented as decision criteria with worked reasoning (for example, the subscription fitness app versus the ad-supported emerging-market utility), so a platform choice can be argued from evidence rather than preference.
  • MO3: Several sections translate directly into scope-document content. Deployment-target selection, the supported device and orientation matrix, mandatory review-driven features such as account deletion, Sign in with Apple, IAP and UGC moderation tooling, permission-denied states, and Dynamic Type testing at accessibility sizes are all shown as items that must be named as objectives, constraints, or acceptance criteria up front. The library-app scenario models how platform analysis converts into an explicit, testable scope.
NotesFigures such as iOS adoption percentages, review turnaround times, and device point dimensions are representative of recent iOS/iPhone generations and should be refreshed against Apple's current documentation (Human Interface Guidelines, App Store Review Guidelines, and the App Store support dashboard) before delivery, as Apple revises these each cycle. The in-app purchase and external-link rules in particular are in active flux because of EU Digital Markets Act and US litigation outcomes; present them as "currently" rather than fixed. Suggested teaching activities: (1) a heuristic audit in which students evaluate a chosen App Store app against the HIG themes of clarity, deference, and depth; (2) a Dynamic Type stress test, mocking one screen at default and at the largest accessibility size on an iPhone SE frame; (3) a review-risk workshop where students read a short product brief and list the App Store Review Guidelines clauses it would likely trip, then revise the brief. Assessment tie-in: the library-app scenario at the end can be reused as a seed for an MO3 scope-document exercise.
2

Videos on This Topic

▶

Choosing iOS as a target platform means accepting a particular design philosophy along with a particular set of rules. Apple publishes the Human Interface Guidelines (HIG), maintains a consistent system of controls, typography, materials, and navigation patterns, and reviews every app before it reaches the App Store. For an HCI designer, that combination is both a gift and a constraint: much of the interaction vocabulary is already decided for you, users arrive with strong expectations about how things should behave, and deviating from convention tends to cost you more than it gains.

In this topic we look at three things: what the iOS platform actually is (devices, system design language, and the audience that uses it), the design conventions that make an app feel "native" on iOS, and the constraints that come with Apple's more controlled ecosystem — review policies, hardware and device-size assumptions, accessibility expectations, and limited freedom to invent your own UI patterns. These factors feed directly into whether iOS is the right platform for your team's project.

The videos below come from Apple Developer's WWDC sessions, which is as close to a primary source as you can get for iOS design. While watching, note the recurring vocabulary — hierarchy, consistency, materials, controls, navigation — and ask yourself two questions: what does this guidance require of a designer, and what would it prevent you from doing? Those answers become constraints you can cite in your scoping document.

3

Video 1: WWDC25: Design foundations from idea to interface | Apple

▶

Apple Developer · 19:06 · 145,171 views · 1y ago · captions — Watch on YouTube

About this video

An Apple WWDC25 session that walks through how an app idea becomes an actual interface, covering the design foundations Apple expects developers to apply. Based on its description, it focuses on how thoughtful design elevates functionality and makes apps feel clear, intuitive, and effortless. Expect discussion of structuring content, establishing hierarchy, and choosing appropriate system components.

Why this video

It is an official Apple source and maps directly to the iOS Design Conventions subtopic, showing the reasoning behind the conventions rather than just listing them — useful when you need to justify design decisions.

4

Video 2: WWDC26: Principles of great design | Apple

▶

Apple Developer · 17:17 · 78,033 views · 3mo ago · captions — Watch on YouTube

About this video

A WWDC26 session on the principles of great design, linked directly to Apple's Human Interface Guidelines design principles documentation. It is likely to present the high-level values Apple wants apps on its platforms to embody, such as clarity, consistency, and deference to content. The session serves as an entry point into the HIG itself.

Why this video

It gives you the conceptual frame behind the HIG, which is the single most important reference for anyone designing for iOS, and supports both the platform overview and design conventions subtopics.

5

Video 3: WWDC25: Get to know the new design system | Apple

▶

Apple Developer · 18:15 · 208,234 views · 1y ago · captions — Watch on YouTube

About this video

A WWDC25 session introducing Apple's updated design system, with references to the Human Interface Guidelines sections on materials and related documentation. It is likely to cover the system's visual language — layers, materials, controls, and how they behave across Apple devices. This is the kind of material that shows how much of your interface iOS already defines for you.

Why this video

Seeing the breadth of a prescribed system makes the ecosystem's constraints concrete, which is exactly the point of the iOS Constraints and Considerations subtopic; it also comes straight from the platform owner, so the details are accurate and current.

6

How These Videos Support the Learning Outcomes

▶

These sessions give you an authoritative picture of what designing for iOS actually demands, which is the raw material for MO1: you cannot meaningfully compare mobile, web, and desktop constraints until you know how tightly a platform like iOS specifies its interaction and visual conventions. The emphasis on system components, materials, and design principles gives you concrete, citable reasons for or against choosing iOS for your project, supporting the platform justification in MO2. Finally, the constraints surfaced here — prescribed patterns, device and ecosystem assumptions, and expectations your users bring with them — translate directly into the constraints and success criteria sections of the project scope document required by MO3.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Windows Platform: Characteristics and Constraints

1

Windows Platform: Characteristics and Constraints

▶

The Windows desktop remains the single most widely deployed general-purpose computing environment in the world, and for interface designers it represents a distinctive design problem: an enormous, heterogeneous installed base running on hardware that ranges from a £200 netbook with a 1366×768 screen to a multi-monitor workstation driving three 4K displays, operated by users who may be touching the screen, drawing with a pen, or driving the entire interface from the keyboard without ever lifting a hand to the mouse. Unlike mobile platforms, where the vendor controls hardware, screen size, input, and distribution, Windows gives the designer very little that can be safely assumed. Understanding the platform therefore means understanding three interrelated things: what Windows is technologically and demographically, what its users have been conditioned to expect through decades of convention, and what the platform physically and organisationally prevents you from doing.

The installed base and why it matters for design. Windows accounts for the large majority of desktop and laptop operating system usage worldwide — typically cited in the region of 70% of desktop sessions, with macOS, ChromeOS and desktop Linux dividing the remainder. The raw share figure is less interesting than its composition. That base is not a single population; it is many overlapping populations with very different needs:

  • Enterprise and public sector. Line-of-business applications, finance systems, healthcare records, logistics dashboards, and the vast ecosystem of internal tools built on Microsoft Office, Active Directory, and SharePoint. Hardware is procured in bulk, often conservative, and refreshed on three- to five-year cycles.
  • Education. Shared lab machines, locked-down student accounts, managed deployments, and a mix of elderly and modern hardware in the same building. Low-cost devices with limited RAM and modest integrated graphics are common.
  • Professional and creative. CAD, 3D, video editing, audio production, data science, and software development. These users have powerful GPUs, large or multiple monitors, graphics tablets, and an expectation of deep customisation, scripting, and plug-in ecosystems.
  • Consumer and gaming. Home PCs where Windows dominates gaming through DirectX and Steam, alongside casual browsing and media use.

The practical design consequence is that your target user segment matters more on Windows than the platform label itself. A product aimed at NHS administrative staff on managed Windows 10 desktops and a product aimed at indie game developers on self-built Windows 11 machines are, from an HCI standpoint, almost different platforms sharing a kernel.

Application models: Win32, UWP, and WinUI. Windows is unusual among modern platforms in supporting multiple generations of application technology simultaneously, and in supporting them more or less indefinitely. Microsoft's long-standing commitment to backward compatibility means that a well-behaved Win32 application compiled in the late 1990s will frequently still run on Windows 11. This is a genuine strength for enterprise customers and a genuine source of inconsistency for designers, because the visual and behavioural conventions of each generation leak into the same desktop.

Model Era and status Typical UI frameworks Design implications
Win32 1993 onwards; still the dominant model for desktop software Raw Win32/GDI, MFC, Windows Forms, WPF, Qt, Electron Full system access, arbitrary window management, unrestricted file system use; but no sandboxing, inconsistent DPI behaviour in older code, and manual effort required to look modern
UWP Introduced with Windows 10 (2015); now in maintenance, no longer the recommended path XAML + WinRT Sandboxed, Store-distributed, adaptive layout and touch support built in; but restricted APIs frustrated power-user and enterprise scenarios
WinUI 3 / Windows App SDK Current recommended path for new native Windows apps WinUI 3 XAML, decoupled from the OS release cycle Modern Fluent controls with desktop (Win32) capability; combines UWP's visual language with Win32's reach
Web-wrapped / cross-platform Widespread in practice (Teams, Slack, VS Code, Discord) Electron, Tauri, .NET MAUI, Flutter, Qt Consistency across OSes at the cost of platform fit: non-native menus, non-native scrollbars, heavier memory use, sometimes poor screen-reader support unless deliberately engineered

A designer choosing between these is making an HCI decision, not only an engineering one. Picking Electron buys you a single codebase and a familiar web toolchain, but you inherit the obligation to re-implement keyboard navigation, high-contrast themes, and accessibility tree exposure that WinUI would have given you by default. Picking WinUI gives you platform fidelity but ties you to Windows and to a reasonably recent OS version.

Fluent Design System. Fluent is Microsoft's current design language, introduced in 2017 and substantially revised for Windows 11. It is organised around the idea of adding depth, materiality and motion to an otherwise flat visual language so that users can perceive hierarchy and spatial relationships. Its characteristic elements include:

  • Acrylic and Mica materials. Acrylic is a translucent, blurred material that samples what is behind it, used for transient surfaces such as flyouts, command bars and navigation panes; it signals "this layer floats above the content". Mica is a more opaque, performance-friendly material introduced in Windows 11 that tints an app's base layer with the desktop wallpaper colour, giving each window a subtle sense of place on the desktop without the cost of continuous blur. Mica is deliberately cheaper to render because acrylic's live blur is expensive on battery-powered and integrated-graphics devices.
  • Reveal highlight. A light effect that follows the pointer and illuminates the borders of nearby interactive elements. Its HCI purpose is affordance disclosure: in a dense command surface where buttons have no visible chrome at rest, reveal tells the user which regions are clickable as the cursor approaches, without permanently cluttering the display with borders.
  • Connected animations and motion. When an item in a list expands into a detail page, a connected animation carries the thumbnail from its list position to its detail position. This preserves object constancy — the user perceives one object moving rather than one screen being replaced by another — which reduces re-orientation cost. Fluent motion is also directional and short (typically 150–300 ms) so that it informs without delaying.
  • Rounded geometry, layering and elevation. Windows 11 rounded window corners, controls and flyouts, and introduced a layering model (base layer, content layer, card layer) that uses subtle shadows and surface tints rather than heavy borders to express grouping.
  • Type and iconography. Segoe UI Variable as the system typeface, with optical sizing so small text remains legible and large text remains well-proportioned; the Segoe Fluent Icons set provides a consistent, weight-matched glyph vocabulary.

Critically, Fluent is not purely decorative. Each effect carries a usability argument, and each has a cost. Acrylic behind text reduces contrast, so Fluent guidance requires acrylic surfaces to use in-built tint and luminosity layers to keep text legible, and the system automatically disables acrylic when the device is in battery-saver mode, when the window is inactive, or when the user has enabled transparency reduction. A designer who assumes the blur will always be there — for example, by relying on it to separate a pane from content — will produce a broken-looking interface for a significant minority of users.

Command and navigation conventions. Windows users carry a deep, learned model of how desktop software is organised. Violating it is possible but expensive in learnability terms.

  • Menu bars. The classic File / Edit / View / … bar remains the most discoverable way to expose a large, stable command set, because it is exhaustive and hierarchical: every command lives somewhere, and the user can browse. Conventional ordering matters — users expect Save As under File and Preferences/Options under Tools or Edit.
  • Ribbon. Introduced in Office 2007 to solve the problem of menus and toolbars that had grown to hundreds of commands with low discoverability. The ribbon groups commands into task-oriented tabs, uses variable-size controls to express frequency and importance, shows galleries with live preview, and surfaces contextual tabs only when relevant (for example, a Table Design tab appearing when a table is selected). It trades vertical screen space for discoverability, which is why it offers collapse-to-tabs behaviour on small displays. The ribbon suits document-authoring and other command-rich applications; it is overkill for a tool with twenty commands.
  • Command bars and nav views. Modern WinUI apps typically use a NavigationView (a left rail or hamburger-expandable pane) for top-level destinations plus a CommandBar for page-level actions, with overflow into a "…" menu as width decreases.
  • Context menus. Right-click is a first-class interaction on Windows, not a hidden extra. Users expect a context menu on virtually every object, offering the commands relevant to that object plus standard items (Cut/Copy/Paste, Rename, Delete, Properties). Windows 11 pairs an icon row of common verbs with a textual list. Context menus reduce travel distance and keep commands close to the object of interest, following the direct-manipulation principle.
  • Standard dialogs and system integration. Using the common file dialog, the standard print dialog, the system colour picker, taskbar jump lists, notifications via the Action Center, and drag-and-drop to and from File Explorer all buy you user familiarity for very little cost.

Keyboard interaction as a first-class concern. This is perhaps the sharpest contrast between Windows and mobile design. On Windows, the keyboard is not an accessibility accommodation bolted on at the end; it is the primary input channel for a large population of expert users, and it is the mechanism through which screen readers, switch devices and voice control drive the interface. Several distinct mechanisms coexist:

  • Accelerators (shortcuts). Ctrl+S, Ctrl+Z, Ctrl+Y, Ctrl+F, F2 to rename, F5 to refresh, Alt+F4 to close. These are muscle memory; reassigning them is a usability defect. Note the platform divergence here — a cross-platform product must map Ctrl on Windows to Cmd on macOS rather than shipping one hard-coded set.
  • Access keys / mnemonics. The underlined letters revealed by pressing Alt, allowing Alt+F, S to save. In ribbon applications these became KeyTips, with multi-character sequences shown as overlay badges.
  • Focus navigation. Tab and Shift+Tab move between control groups; arrow keys move within a group (a radio set, a list, a toolbar); Space activates; Enter triggers the default button; Esc cancels. A correct, logical tab order that matches visual reading order is non-negotiable, and a visible focus indicator must be present — Windows 11 draws a high-visibility two-tone focus rectangle precisely so it survives against any background.
  • Command palettes and type-ahead. Modern power-user applications (Visual Studio Code, Visual Studio, Windows Terminal) supplement menus with a searchable command palette, typically Ctrl+Shift+P. This scales better than menus for very large command sets and supports recall-based expert use while menus support recognition-based novice use.

Windowing, resizing and multi-tasking. A Windows application does not own the screen. It lives in a resizable, movable window that the user may snap to half or a quarter of the display, maximise across an ultrawide monitor, or shrink to a narrow column. Windows 11's Snap Layouts, invoked by hovering the maximise button or pressing Win+Z, actively encourage users to tile applications, so narrow and unusual aspect ratios are common rather than exceptional. Design implications:

  • Define a sensible minimum window size and ensure the layout remains usable at it — content should reflow, panes should collapse into flyouts, and command bars should overflow rather than clipping.
  • Use adaptive breakpoints. WinUI guidance suggests reference widths around 640px and 1008px at which a navigation pane moves from overlay, to compact rail, to expanded.
  • Support multiple windows where the task demands it. Comparing two documents, dragging a tab out into its own window, or opening a second project instance are deeply embedded desktop behaviours. Single-window-only designs imported from mobile thinking frustrate desktop users.
  • Persist window state — size, position, monitor, and maximised/snapped state — across sessions, and handle the case where the monitor the app was last on no longer exists.
  • Respect the title bar contract. If you draw a custom title bar (common in modern apps), you must still provide a draggable region, correctly placed and sized caption buttons, right-click system menu behaviour, and the Snap Layouts hover zone over the maximise button.

Hardware variation: resolution, DPI and input. Windows runs on an effectively unbounded hardware matrix, and the most persistent source of visual defects is DPI scaling. A 13-inch laptop at 3000×2000 may be set to 200% scaling; an external 1080p monitor beside it sits at 100%. Windows expresses this through effective pixels: a control authored at 40 epx renders as 40 physical pixels at 100% and 80 at 200%. Applications must declare their DPI awareness level, and the differences are visible to users:

DPI awareness mode Behaviour User-visible result
Unaware App renders at 96 DPI; the system bitmap-stretches the result Blurry text and icons on high-DPI displays — the classic "fuzzy legacy app"
System DPI aware App renders crisply at the primary monitor's scale only Sharp on one monitor, blurry after dragging to a differently scaled monitor
Per-Monitor v2 aware App is notified of DPI changes and re-lays-out, including non-client areas Crisp on every monitor and after scale changes; the required target for new work

Related consequences: always ship vector or multi-resolution icon assets rather than single-size bitmaps; never specify layout in raw pixels tied to one assumed density; and test on at least 100%, 150% and 200% with text scaling (Settings → Accessibility → Text size) pushed up to 200%, which scales text independently of layout and will expose any fixed-height container that clips its label.

Input variation is equally wide. The same application may be driven by precision mouse, trackpad with gestures, touchscreen on a 2-in-1, active pen on a Surface, game controller on a handheld PC, or keyboard alone. Microsoft's guidance is to design for the least precise input you expect to support: mouse targets can be small (a 16px close button is acceptable), but touch targets should be around 40×40 epx with adequate spacing, since a fingertip contact patch is roughly 9–10 mm. Hover-dependent designs are a particular trap — reveal highlights, tooltips and hover-only toolbars simply do not exist for touch or keyboard users, so any information conveyed only on hover must have a non-hover equivalent.

Organisational constraints: OS version lock and managed environments. Enterprise and education deployments are governed by IT policy, not by user preference. A hospital trust may still run Windows 10 on clinical workstations because a critical imaging application is certified only against that version; a school may freeze updates to avoid breaking exam software. This creates concrete design constraints:

  • API floor. If your audience includes Windows 10 users, Windows 11-only visual features (Mica, rounded corners, Snap Layouts hover, the new context menu style) must be treated as progressive enhancement — present when available, gracefully absent otherwise — rather than as load-bearing design elements.
  • Deployment channel. Managed estates frequently block the Microsoft Store and install software via MSI/MSIX packages pushed through Intune, SCCM or Group Policy. A design that assumes Store-based auto-update, or that nags the user to update, will be wrong for these customers.
  • Permissions and lockdown. Standard users may not be administrators, may have no write access outside their roaming profile, may be behind a filtering proxy, and may have roaming profiles that need your settings to be portable. Features requiring elevation should be rare, clearly marked with the UAC shield, and never required for core tasks.
  • Hardware floor. Fleet machines may have integrated graphics and 8GB of RAM shared with a heavyweight security agent. Expensive continuous effects (live acrylic, large blurs, constant animation) must degrade; honour prefers-reduced-motion-equivalent system settings and battery-saver state.

Productivity expectations: density, control and multi-tasking. Mobile design culture rewards generous whitespace, one primary action per screen, and progressive disclosure. Desktop productivity culture frequently rewards the opposite. A trading desk, an ERP data-entry screen, a DAW mixer, or a log analysis tool must present a great deal of information at once because the user's task is comparison and rapid scanning across many values, and because the cost of navigation between screens — in time and in working-memory load — is higher than the cost of visual density. Concretely, productivity users expect:

  • Grids and tables with sortable, resizable, reorderable, freezable columns, multi-select with Shift and Ctrl, and keyboard-driven cell navigation.
  • Compact density modes. WinUI ships Compact resource dictionaries that reduce control heights (for example, list item heights from roughly 40 epx to 32 epx); offering a density toggle respects both the scanning expert and the touch user.
  • Bulk operations, multi-select, repeat-last-action, templates, macros, and scripting or command-line hooks.
  • Robust undo — ideally multi-level and across the whole session — because exploratory, high-speed work only feels safe when mistakes are cheap to reverse. This is Nielsen's "user control and freedom" heuristic made concrete.
  • Non-blocking background work. Long operations should run with progress shown in a status bar or task list while the user continues working, rather than behind a modal dialog that freezes the application.
  • Genuine multi-tasking support: copy/paste and drag-and-drop interoperability with Office and Explorer, deep links, multiple document interfaces, and tear-off tabs.

A useful illustration is the contrast between Microsoft Excel and a mobile spreadsheet app. Excel exposes thousands of commands through a ribbon, a formula bar, context menus, a status bar with live aggregates, keyboard shortcuts for almost everything, and a Name Box for navigation — because its users are experts performing long, repetitive, precision tasks. The mobile version hides nearly all of it, because its users are checking a figure on a train. Same brand, same data model, opposite density decisions, both correct for their context.

Accessibility as a design input, not a retrofit. Windows has one of the richest accessibility stacks of any platform, and legal exposure is real: the EU Accessibility Act, Section 508 in the United States, and the UK Equality Act and public sector accessibility regulations all bite on software procurement. Microsoft publishes accessibility guidance aligned with WCAG 2.1/2.2 at level AA and requires a Voluntary Product Accessibility Template (VPAT/Accessibility Conformance Report) from suppliers. The key platform affordances are:

  • UI Automation (UIA). The accessibility API through which Narrator, NVDA, JAWS, Voice Access and automated test tools read your interface. Every meaningful element must expose a correct control type, name, value and state. A custom-drawn control that is just a painted rectangle is invisible to UIA and therefore invisible to a blind user.
  • Narrator and third-party screen readers. Test with Narrator (Ctrl+Win+Enter) and ideally NVDA. Check that reading order matches visual order, that landmark regions are exposed, and that dynamic changes raise live-region or property-changed events so that the user is told when a status message appears.
  • High Contrast / Contrast Themes. Windows ships system contrast themes that override application colours with a restricted system palette. Applications must use system colour resources rather than hard-coded hex values so that they adapt, must not convey meaning by colour alone, and must ensure that images of text and custom-drawn graphics remain legible. A common failure is an icon drawn as a white glyph on a transparent background, which vanishes entirely on a white contrast theme.
  • Text scaling and zoom. Windows allows text to be scaled to 225% independently of display scaling, and Magnifier allows arbitrary zoom. WCAG 1.4.4 requires content to remain functional at 200%. Layouts must therefore be built from flexible containers that grow with their content rather than fixed-height boxes.
  • Contrast ratios. WCAG AA requires 4.5:1 for normal text, 3:1 for large text, and 3:1 for the visual boundary of user interface components and meaningful graphics (WCAG 1.4.11). This directly constrains Fluent's translucency: text over acrylic must be checked against the worst-case backdrop, not the designer's chosen wallpaper.
  • Motion, flashing and timing. Honour the system "Show animations in Windows" setting; avoid content flashing more than three times per second (WCAG 2.3.1); and allow users to extend or disable time limits such as auto-dismissing toasts or session timeouts.
  • Keyboard access and focus. WCAG 2.1.1 (keyboard), 2.1.2 (no keyboard trap), 2.4.3 (focus order) and 2.4.7 (focus visible) map almost one-to-one onto the Windows keyboard conventions already described, which is why good Windows keyboard design produces most of your accessibility conformance for free.
  • Captions, alternatives and input modality. Media needs captions and transcripts; images need accessible names; drag-and-drop needs a keyboard or menu-based alternative (WCAG 2.5.7); and gestures should not be the only path to a function.

Practically, this means accessibility criteria belong in the acceptance criteria of each user story: "all commands on this toolbar are reachable by keyboard, announced by Narrator with a meaningful name, and legible in both contrast themes." Retrofitting is far more expensive — a custom canvas-based grid built without UIA in mind may need rearchitecting, whereas choosing the platform's DataGrid at the outset would have supplied the automation peers automatically.

Synthesising the constraints into a design method. Because Windows offers so few guarantees, a designer should make the assumptions explicit at the start of a project. A simple platform-constraint register is an effective artefact:

Constraint dimension Question to answer early Example decision and its design consequence
OS version floor What is the oldest Windows build in the target estate? Windows 10 22H2 → Mica and Snap Layouts hover treated as enhancements; WinUI 3 via Windows App SDK rather than Windows 11-only APIs
Display matrix Minimum resolution, typical scaling, single or multi-monitor? 1366×768 at 100% minimum, 4K at 200% common → per-monitor v2 awareness, vector icons, 1024×640 minimum window, breakpoints at 640/1008 epx
Input modalities Mouse only, or touch/pen/keyboard-only as well? Surface 2-in-1 field use included → 40 epx touch targets, no hover-only commands, pen-friendly annotation mode
User expertise and density Occasional users or all-day operators? All-day claims processors → compact density default, full keyboard command coverage, multi-level undo, tear-off windows
Deployment and permissions Store, MSIX via Intune, or legacy MSI? Admin rights available? Managed MSIX, standard user only → no elevation in core flows, settings stored in roaming profile, no self-updater
Accessibility target Which standard, and is a conformance report required? WCAG 2.2 AA plus VPAT for public sector tender → contrast-theme support, UIA naming, keyboard acceptance criteria per story
Performance envelope What is the weakest machine and graphics capability? Integrated GPU, 8GB RAM → Mica over acrylic, virtualised lists, animation disabled under battery saver

Finally, it is worth naming the trade-offs that have no universally right answer, because articulating them is the core of platform justification. Native WinUI maximises platform fidelity, accessibility, and performance but costs you macOS and Linux reach. Electron or a web-wrapped app maximises consistency and team velocity but imports web idioms into a desktop context and raises the accessibility and memory burden. A ribbon maximises discoverability for command-rich work but consumes vertical space that a video editor cannot spare. High density maximises expert throughput but raises error rates and excludes touch users. Supporting Windows 10 widens the addressable market but caps the visual language. Each of these is a defensible decision only when tied to an explicit statement of who the users are, what hardware they have, what their organisation permits, and what success looks like — which is precisely the brief a scope document should capture.

Alignment with Learning Outcomes

  • MO1: The topic supplies the desktop half of the mobile/web/desktop comparison, setting out Windows-specific constraints — DPI scaling and hardware heterogeneity, resizable multi-window usage, keyboard-first interaction, high information density, and OS-version lock in managed estates — against which mobile and web platforms can be contrasted for a given user population.
  • MO2: The application-model comparison (Win32, UWP, WinUI 3, Electron and other cross-platform stacks), the deployment and permissions discussion, and the platform-constraint register give students concrete criteria and evidence for selecting a platform and framework and defending that choice against stated project requirements.
  • MO3: The constraint register, OS-version floor, display and input matrices, density expectations and WCAG/VPAT accessibility targets translate directly into the objectives, constraints and measurable success criteria sections of a project scope document.
NotesMarket-share figures are approximate and move over time; students should cite a current source (e.g. StatCounter) rather than the indicative ~70% used here. UWP is described as in maintenance and WinUI 3 / Windows App SDK as the current recommended native path, which reflects Microsoft's present guidance — verify against current Microsoft Learn documentation before teaching. Effective-pixel values (40 epx touch targets, 640/1008 epx breakpoints, 32 epx compact list rows) follow WinUI guidance and are indicative rather than absolute. WCAG references are to 2.1/2.2 level AA.
2

Videos on This Topic

▶

The Windows desktop remains one of the most widely deployed application platforms in business, education, and engineering settings. Unlike a phone, a Windows machine typically assumes a large screen, a mouse or trackpad, a full keyboard, multiple overlapping windows, and long working sessions. Those assumptions shape everything from how much information you can place on a screen at once, to how you expose commands (menus, ribbons, toolbars, right-click context menus, keyboard shortcuts), to how users expect to move data between applications.

In this module you are deciding which platform fits your project. Windows is a strong choice when users need dense data views, precise pointer input, file system access, long-form content creation, or integration with an organization's existing productivity and identity systems. It is a weaker choice when your users are mobile, occasional, or touch-first. The constraints matter as much as the capabilities: varying screen sizes and DPI settings, accessibility and keyboard navigation expectations, installation and update paths, and the strong conventions users already carry from Office and other Windows software.

The videos below approach Windows from three angles: the Microsoft 365 ecosystem that many Windows users live inside, the current developer tooling story on Windows, and a low-code route to building Windows-friendly business apps. While watching, note the interaction patterns you see repeatedly (ribbons, panes, command bars, keyboard shortcuts), and ask yourself what each one assumes about the user's hardware, attention, and environment. Those observations are the raw material for the platform justification and scope document you will write.

3

Video 1: 🤷‍♂️ What is Microsoft 365 - Explained

▶

Kevin Stratvert · 14:10 · 1,323,786 views · 5y ago · captions — Watch on YouTube

About this video

A beginner-oriented walkthrough of what Microsoft 365 is as a subscription and ecosystem, covering the applications it bundles and how desktop apps relate to their cloud and web counterparts. Expect demonstrations inside familiar Windows productivity applications rather than a formal design lecture.

Why this video

It gives you a concrete tour of the software environment most Windows users already know, which is where the platform's design conventions - ribbons, panes, consistent command placement - come from; Kevin Stratvert is a former Microsoft product manager and explains the ecosystem clearly for newcomers.

4

Video 2: Developer Experience on Windows: Microsoft Build 2026

▶

Microsoft Developer · 5:58 · 2,483 views · 4mo ago · captions — Watch on YouTube

About this video

A short conference segment from Microsoft Build 2026 in which Kayla Cinnamon demonstrates recent additions aimed at developers working on Windows. It is likely to touch on tooling, terminal and workflow improvements, and how developers set up and work within the Windows environment.

Why this video

It is a first-party Microsoft source and gives a current snapshot of what building on Windows actually looks like today, which helps you weigh tooling and platform support when justifying a desktop choice.

5

Video 3: How to use Microsoft Power Apps - Beginner Tutorial

▶

Kevin Stratvert · 17:18 · 1,620,384 views · 5y ago · captions — Watch on YouTube

About this video

A step-by-step beginner tutorial on Microsoft Power Apps, showing how to assemble a business application with low-code tools rather than traditional programming. It walks through the app-building interface, data connections, and producing something usable by an organization.

Why this video

It illustrates a realistic path many Windows-oriented organizations take for internal tools, letting you compare build effort, constraints, and control against writing a full native desktop application when you select a platform for your project.

6

How These Videos Support the Learning Outcomes

▶

Together these videos let you characterize the Windows side of the mobile/web/desktop comparison called for in MO1: you see the input assumptions, screen density, and interaction conventions of desktop productivity software, plus the cloud and web counterparts that blur the line. The developer experience and Power Apps videos surface practical build-and-deploy considerations - tooling, low-code versus custom development, organizational integration - that you will need to cite when you select and justify a platform under MO2. Finally, the constraints you identify while watching (hardware assumptions, licensing and ecosystem dependencies, development effort) translate directly into the objectives, constraints, and success criteria sections of the scope document required by MO3.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Web Platform: Characteristics and Constraints

1

Web Platform: Characteristics and Constraints

▶

The web is the most widely reachable application platform ever built. Unlike a mobile app, which must be packaged, submitted to a store, approved, downloaded and installed, a web application is simply somewhere — identified by a URL and rendered by whatever browser the user already has. This single architectural fact shapes almost everything about web interface design: the audience is enormous and uncontrolled, the runtime environment varies wildly, the first interaction is nearly frictionless, and the designer's control over hardware, performance and persistence is correspondingly weak. Understanding the web platform for HCI purposes means understanding this trade: maximum reach and minimum friction, purchased with reduced device integration and increased environmental uncertainty.

From a human–computer interaction standpoint, the browser is not a neutral container. It is itself an interface with its own controls — back and forward buttons, address bar, tabs, bookmarks, zoom, reader mode, find-in-page, print — and users bring deeply ingrained expectations about how those controls behave. A web application that breaks the back button, hijacks scrolling, or disables text selection is not merely annoying; it is violating a mental model the user has built over decades of browsing. Designing for the web therefore means designing inside an existing interface rather than owning the whole screen.

Access model: URLs, browsers and zero installation. Every meaningful state in a well-built web app should be addressable. A URL is simultaneously an identifier, a navigation mechanism, a sharing primitive and a bookmarking primitive. Consider the difference between telling a colleague "open the app, go to Reports, filter by Q3, then select the Northern region" and simply sending them https://dash.example.com/reports?quarter=Q3&region=north. The second is a direct manipulation of shared state and costs nothing. This is why single-page applications must still invest in routing: if the URL never changes as the user navigates, the application has discarded one of the web's most valuable affordances.

The major rendering engines in practice are Blink (Chrome, Edge, Opera, Brave, Samsung Internet), Gecko (Firefox) and WebKit (Safari, and all browsers on iOS historically). Although standards compliance is far better than in the past, differences remain — in form control styling, date and file pickers, scroll behaviour, font rendering, and the availability of newer APIs. A design that assumes "Chrome on a 1080p desktop monitor" is a design that will be tested by reality.

The absence of installation is the web's strongest adoption lever. A user can go from seeing a link in a message to using the product in under two seconds, with no storage cost, no permission prompts and no account with an app store. For products with shallow or occasional engagement — a council's parking-permit renewal, a conference schedule, a one-off survey, a news site — this is decisive. The corresponding weakness is that the web has no icon on the home screen by default and therefore weak re-engagement: nothing reminds the user you exist. Mobile apps buy retention with installation friction; web apps buy acquisition with disposability.

Responsive design as a baseline requirement. Because the same URL is opened on a 320 px phone, a 768 px tablet, a 1440 px laptop and a 2560 px external monitor, a fixed-width layout is not a design decision — it is a defect. Responsive design combines three techniques: fluid grids (sizing in percentages, fr units, minmax() and viewport units rather than fixed pixels), flexible media (max-width: 100%, srcset for resolution-appropriate images), and media or container queries that change layout at defined thresholds.

/* Mobile-first: the default is the narrow layout */
.product-grid {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
}

@media (min-width: 600px) {
  .product-grid { grid-template-columns: repeat(2, 1fr); }
}

@media (min-width: 1024px) {
  .product-grid { grid-template-columns: repeat(4, 1fr); }
}

/* Better still: let the content decide, no breakpoints needed */
.product-grid--intrinsic {
  grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr));
}

Note also that responsive design is not only about width. pointer: coarse tells you a finger is the input device, which implies larger hit targets (a minimum of roughly 44 × 44 CSS pixels) and no reliance on hover; prefers-reduced-motion tells you the user is sensitive to animation; prefers-color-scheme tells you whether to serve a dark theme. Responsiveness in the full sense means responding to the user's device, input modality and stated preferences.

Progressive Web Apps. PWA technology narrows the gap between web and native. A web app that is served over HTTPS, provides a web app manifest and registers a service worker can be installed to the home screen or desktop, launch in a standalone window without browser chrome, display a custom icon and splash screen, cache assets and data for offline use, and (on supporting platforms) receive push notifications and perform background sync.

{
  "name": "Field Survey Recorder",
  "short_name": "Survey",
  "start_url": "/app/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0b5fff",
  "icons": [
    { "src": "/icons/192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

A service worker sits between the application and the network as a programmable proxy, which is what makes genuine offline operation possible. A field inspection tool, for example, can cache the shell and the day's job list, allow an inspector to record findings in a basement with no signal using IndexedDB, and flush the queue when connectivity returns. The HCI consequence is that offline capability must be visible: users need an unambiguous indicator of connection state, of which records are saved locally versus synced, and of what will happen if they close the tab. Silent offline queues are a trust hazard.

PWA support is uneven. Installability, push notifications and background sync are more complete on Android and desktop than on iOS, where Apple has historically limited or delayed support and where installation is only possible through a non-obvious "Add to Home Screen" step in the Share sheet. Any project that depends on push notifications to iPhone users should scope that assumption carefully rather than treating "PWA" as a single guaranteed feature set.

Navigation conventions. Web navigation has stabilised into a small set of well-understood patterns, and users read them almost without conscious effort. Choosing among them is a question of information architecture breadth and depth, not taste.

Pattern Best suited to Strengths Risks and caveats
Top horizontal navigation bar Shallow sites with roughly 4–7 top-level sections Always visible, scannable, conveys the whole structure at a glance Breaks down beyond about seven items; competes for vertical space when sticky
Hamburger / drawer menu Narrow viewports; secondary or account-level links Saves space, universally recognised on mobile Out of sight, out of mind — measurably reduces discovery of hidden items on desktop
Sidebar / vertical navigation Admin consoles, documentation, dashboards with many sections Scales to long lists, supports nesting and persistent context Consumes horizontal space; must collapse to a drawer on small screens
Breadcrumb trail Deep hierarchies: catalogues, knowledge bases, file stores Shows location in hierarchy and provides one-click ascent Useless and misleading on flat sites; must reflect hierarchy, not browsing history
Tabs Switching views of one object (Overview / Activity / Settings) Low cognitive cost, clear current-state indication Should not be used for unrelated destinations or for sequential steps
Search with filters/facets Large, heterogeneous content sets Fastest route for users with a specific goal Requires real investment in relevance, synonyms and empty-state design

Most substantial products combine several: a persistent top bar for global sections, a sidebar within a section, breadcrumbs for depth, and prominent search. The guiding principle is Nielsen's "visibility of system status" applied to location — at any moment, the user should be able to answer "where am I, what else is here, and how do I get back?"

Typography, contrast and accessibility. Accessibility on the web is both an ethical obligation and, in many jurisdictions, a legal one (for example the public-sector accessibility regulations in the UK and EU, and the Americans with Disabilities Act as applied to web services in the US). The Web Content Accessibility Guidelines (WCAG) organise requirements under four principles — Perceivable, Operable, Understandable, Robust — at conformance levels A, AA and AAA, with AA being the usual target.

  • Contrast. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 18.66 px bold or 24 px regular and above). Non-text elements that convey meaning — input borders, focus rings, icon buttons, chart segments — require 3:1. Light grey placeholder text on white is one of the most common AA failures.
  • Scalable type. Set font sizes in rem so that a user who has raised their browser's default size actually sees larger text. Content must remain functional at 200% zoom and must reflow without horizontal scrolling at a width equivalent to 320 px. Avoid user-scalable=no in the viewport meta tag; it removes pinch-zoom from people who need it.
  • Readability. Body copy of around 16–18 px, line height near 1.5, and measure (line length) of roughly 45–75 characters reduce reading effort. Justified text and very long lines increase the chance of losing one's place, which disproportionately affects dyslexic readers.
  • Not colour alone. A required field marked only in red, or a chart whose series are distinguished only by hue, fails users with colour vision deficiency (about 8% of men of northern European descent). Pair colour with an icon, a label, a pattern or a text cue.
  • Keyboard and focus. Every interactive element must be reachable by Tab in a logical order and must show a visible focus indicator. Custom components built from <div> elements need explicit roles, states and key handling; using a real <button> gets all of this for free.
  • Semantics for assistive technology. Landmarks (<header>, <nav>, <main>, <footer>), a single logical heading hierarchy, labelled form controls, meaningful alt text, and aria-live regions for dynamic updates allow screen-reader users to navigate structurally rather than linearly.
<!-- Accessible by construction -->
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email"
       aria-describedby="email-help" required>
<p id="email-help">We will only use this to send your receipt.</p>

<!-- Status messages announced without stealing focus -->
<div role="status" aria-live="polite">3 results found</div>

Breakpoints and layout adaptation. Breakpoints should be derived from the content, not from a list of popular device widths, which changes every year. The practical method is to widen the browser until a layout begins to look wrong — a line of text grows too long, a card grid leaves awkward gaps, a table starts to wrap badly — and place a breakpoint there. A common, workable starting set is shown below, but it is a convention rather than a rule.

Range Typical context Layout strategy Interaction notes
Up to ~599 px Phones, portrait Single column; navigation collapsed to a drawer or bottom bar; tables become stacked cards Touch targets ≥44 px; no hover-dependent features; primary action within thumb reach
~600–899 px Large phones landscape, small tablets Two-column grids; forms may pair short fields side by side Still touch-first; split views become viable
~900–1279 px Tablets landscape, small laptops Persistent sidebar appears; master–detail layouts; three-column card grids Mixed touch and pointer — design for both simultaneously
1280 px and above Desktops, external monitors Cap content width (around 70–80ch for prose); use extra space for secondary panels, not longer lines Hover, right-click menus and keyboard shortcuts are reasonable enhancements

Modern CSS increasingly removes the need for viewport breakpoints altogether. clamp() produces fluid type (font-size: clamp(1rem, 0.9rem + 0.5vw, 1.25rem)), auto-fit grids reflow by themselves, and container queries let a component respond to the width of its own container, so the same card can render compactly in a sidebar and expansively in a main column without the page having to coordinate it.

Respecting established conventions. Jakob's Law states that users spend most of their time on other sites, so they expect yours to work like those sites do. Deviating from convention imposes a learning cost that must be justified by a real benefit. The conventions that carry the strongest expectations include:

  • Links look like links. Underlined and/or clearly coloured, distinguishable from body text by more than hue alone, with a visited state where it helps orientation. Removing underlines from in-paragraph links is a frequent accessibility and usability regression.
  • The logo in the top-left returns to the home page. Almost universally expected; costs nothing to honour.
  • The back button works, and the URL reflects the view. Opening a modal that cannot be dismissed with Back, or a wizard whose Back button exits the whole flow, breaks a core browser contract.
  • Breadcrumbs read left to right from general to specific (Home > Catalogue > Outdoor > Tents), and reflect hierarchy rather than the path the user happened to take.
  • Forms behave like forms. Enter submits, labels are clickable, browser autofill works, validation messages appear near the offending field, and errors are shown after the user has had a chance to finish typing rather than on the first keystroke.
  • Icons that mean specific things — magnifying glass for search, three bars for menu, cog for settings, bin for delete — should not be reassigned to other functions.
  • Scrolling belongs to the user. Scroll-hijacking, infinite scroll in contexts where people need to reach the footer, and content that shifts under the cursor during load (cumulative layout shift) are classic violations.

Breaking a convention is sometimes correct — Gmail broke the convention of page-by-page email, and map applications legitimately take over scroll and zoom within the map canvas. The test is whether the new model is learnable in seconds and delivers a benefit the old one could not.

Scoping browser support. "Works in all browsers" is not a requirement; it is a wish. A project should state its support matrix explicitly, derived from analytics of the actual audience where possible, and the matrix should distinguish tiers rather than treating support as binary.

Tier Definition Example scope Commitment
Fully supported Tested every release; pixel-level fidelity expected Latest two versions of Chrome, Edge, Firefox, Safari (desktop and iOS) All defects fixed; design signed off against these
Functionally supported All tasks completable; minor visual differences tolerated Samsung Internet, Firefox ESR, Safari one major version back Blocking bugs fixed; cosmetic bugs triaged
Degraded / unsupported Core content accessible or a clear upgrade message shown Internet Explorer 11, Android WebView on very old OS builds No active testing; no new defect work

The engineering discipline that makes this manageable is progressive enhancement: build a layer of semantic HTML that works everywhere, enhance it with CSS, enhance that with JavaScript, and feature-detect rather than browser-sniff. Feature queries make the intent explicit and keep the fallback honest.

/* Everyone gets a usable stacked layout */
.layout { display: block; }

/* Browsers with grid support get the richer one */
@supports (display: grid) {
  .layout {
    display: grid;
    grid-template-columns: 18rem 1fr;
  }
}
// Feature detection, not user-agent detection
if ('share' in navigator) {
  shareButton.addEventListener('click', () =>
    navigator.share({ title: document.title, url: location.href })
  );
} else {
  shareButton.hidden = true;   // fall back to a copy-link control
}

Tooling supports this too: Babel transpiles modern JavaScript syntax, PostCSS and Autoprefixer handle CSS differences, polyfills fill API gaps (at a bandwidth cost), and browserslist configuration ties the build output to the stated matrix so the support decision lives in one place. Note, however, that transpilation handles syntax, not capability: no polyfill will give an old browser a real file-system handle or a Bluetooth radio.

Limited access to device hardware. The browser deliberately mediates everything between the page and the machine. Many capabilities exist, but they are permission-gated, secure-context-only (HTTPS), often require a user gesture, and are inconsistently implemented — especially on iOS, where WebKit does not ship several of the more powerful APIs on privacy grounds.

Capability Web availability Practical limitation
Camera and microphone getUserMedia, broadly supported Requires HTTPS and explicit permission; no background capture; limited control of advanced camera settings
Geolocation navigator.geolocation, broadly supported Permission-gated; no reliable background or geofenced tracking
Notifications / push Notifications API + Push API Desktop and Android good; on iOS limited to installed home-screen PWAs on recent versions
File system <input type="file"> everywhere; File System Access API in Chromium only No arbitrary browsing of the disk; "save in place" editing unavailable in Firefox and Safari
Bluetooth / USB / Serial / NFC Web Bluetooth, WebUSB, Web Serial, Web NFC — Chromium only Not available in Safari or Firefox; unsuitable where cross-browser support is required
Biometrics WebAuthn / passkeys, now widely supported Authenticates the user but gives no access to raw biometric data; platform-dependent UI
Background execution Service worker, Background Sync, Periodic Sync (Chromium) Heavily throttled; the browser may terminate workers at will; no long-running background process
Local storage of data localStorage, IndexedDB, Cache Storage Quota-limited and evictable; Safari may clear storage for sites unused for seven days unless installed

The design consequence is that any feature depending on a restricted capability must have a declared fallback and must never fail silently. A web-based stocktaking tool cannot assume it can drive a Bluetooth barcode scanner in Safari; it should therefore offer camera-based scanning via getUserMedia, and manual code entry as the final fallback. The interface should present these as equally legitimate routes rather than as error states, because for a substantial proportion of users the fallback is the primary path.

The same reasoning applies to permission prompts, which are an HCI problem in their own right. A prompt fired on page load, before the user understands why it is needed, is routinely denied — and in several browsers a denial is sticky and difficult for a non-technical user to reverse. The correct pattern is the pre-permission or "priming" step: explain in your own UI what the capability will be used for, let the user opt in with an in-page control, and only then trigger the native prompt.

// Bad: prompt on load, no context
navigator.geolocation.getCurrentPosition(show);

// Better: prompt in response to an intentional action
useMyLocationBtn.addEventListener('click', () => {
  status.textContent = 'Finding your location…';
  navigator.geolocation.getCurrentPosition(show, () => {
    status.textContent = 'Location unavailable — enter a postcode instead.';
    postcodeField.focus();
  }, { timeout: 8000 });
});

Network latency, variability and offline scenarios. A native app's code is already on the device; a web app must fetch its interface before it can show one. Every interaction that touches the server is therefore exposed to round-trip latency, packet loss, captive portals, metered connections and complete loss of signal. Latency is not merely a performance metric — it changes what interaction patterns are psychologically viable. The classic thresholds from Miller and Card, still used today, are roughly: 0.1 s feels instantaneous and preserves the sense of direct manipulation; 1 s keeps the user's flow of thought unbroken but is noticeable; 10 s is the limit of attention, beyond which people switch tasks and need a progress indicator with an estimate.

Condition Typical round trip Design implication
Fast broadband, nearby server 20–60 ms Server round trips can feel direct; little special handling needed
Good 4G 50–150 ms Batch requests; avoid chatty per-keystroke calls without debouncing
Congested 3G / rural mobile 300–800 ms Optimistic UI, skeleton screens and local validation become essential
Satellite, hotel Wi-Fi, train 600 ms–2 s, lossy Design for retry, idempotency and partial failure; never block the whole page
No connectivity — Cached shell, local persistence, queued writes, explicit sync state

Several interface techniques mitigate latency directly. Skeleton screens — grey placeholders shaped like the eventual content — reduce perceived wait better than spinners because they signal structure and progress rather than indefinite blocking. Optimistic updates apply the user's change to the interface immediately and reconcile with the server afterwards, with a clear, non-destructive rollback if the write fails; this is why "like" buttons and checkbox toggles feel instant. Stale-while-revalidate shows cached data at once and quietly refreshes it, with a subtle "updated just now" cue. Debouncing search-as-you-type by 250–300 ms avoids firing a request per keystroke. Prefetching the likely next page on link hover or intersection turns a navigation into an apparent instant.

// Network-aware behaviour: don't autoplay heavy media on a metered link
const c = navigator.connection;
const frugal = c && (c.saveData || /2g/.test(c.effectiveType));
videoPreview.preload = frugal ? 'none' : 'metadata';

// Reflect connection state honestly in the UI
function setOnline(on) {
  document.body.dataset.online = on;
  banner.hidden = on;
  banner.textContent = 'You are offline. Changes are saved on this device and will sync automatically.';
}
window.addEventListener('online',  () => setOnline(true));
window.addEventListener('offline', () => setOnline(false));
setOnline(navigator.onLine);

Offline design raises questions that are as much about trust as about engineering. Where multiple people can edit the same record, the architecture must decide between last-write-wins, server-authoritative rejection, or a merge strategy such as operational transformation or CRDTs — and the interface must then communicate the outcome in human terms ("Your note was saved, but Priya edited this record while you were offline. Review the differences?"). Equally, queued writes must survive the tab being closed, so they belong in IndexedDB rather than in memory, and the user should be able to see the queue rather than take its existence on faith.

The browser security sandbox. The browser runs untrusted code from strangers dozens of times a day, so it isolates pages aggressively. This security model is the direct cause of several capability limits that designers must plan around rather than argue with.

  • Same-origin policy. A page may not read data from another origin (scheme + host + port) unless that origin opts in via CORS headers. This is why an in-house dashboard cannot simply call a third-party API from the browser without server cooperation, and why many integrations need a backend proxy.
  • No arbitrary file-system access. A page cannot enumerate the user's disk, read a file the user did not choose, or write to an arbitrary path. Uploads require a user-initiated <input type="file"> or drag-and-drop; downloads land in the browser's download location. The File System Access API relaxes this with an explicit picker and persisted handles, but only in Chromium-based browsers, and only after a user gesture.
  • No OS integration by default. Web apps cannot install system-wide hotkeys, place items in the system tray, read the clipboard without permission, launch other applications, or inspect what else is running. Even clipboard writing generally requires a user gesture, and reading requires permission.
  • Secure contexts. Service workers, geolocation, camera, notifications, WebAuthn and most powerful APIs require HTTPS. A plain-HTTP deployment silently loses half the platform.
  • Storage partitioning and eviction. Browsers increasingly partition storage by top-level site and evict data under pressure or after periods of disuse, so local caches must be treated as an optimisation, never as the only copy of user data.
  • Autoplay, pop-up and fullscreen gating. Audio playback, new windows and fullscreen all require a genuine user gesture, which affects how onboarding tours, media players and kiosk-style interfaces can be designed.
  • Content Security Policy, XSS and CSRF. Because the web executes text as code, injection is the dominant attack class. A strict CSP, output escaping, SameSite cookies and anti-CSRF tokens are baseline requirements, and they occasionally constrain design choices such as inline styles or third-party embeds.

These constraints are also a usability asset, and should be framed as such to stakeholders. Users grant a web page far less trust than an installed binary precisely because they know the browser is holding it at arm's length, which is part of why a link converts so much better than an installer.

Judging suitability: when the web is the right platform. Platform selection should fall out of requirements, not preference. The web is usually the strongest candidate when reach, link-sharing, frequent updating and low adoption friction dominate; it is usually the weaker candidate when deep hardware integration, guaranteed offline operation, sustained background activity or extreme performance are the defining requirements.

Requirement signal Web platform fit Reasoning
Content must be discoverable by search engines and shareable by link Strong URLs and server-rendered HTML are native to the platform; app content is largely invisible to the open web
Occasional, one-off or first-time use (booking, renewal, survey) Strong Installation friction would exceed the value of the task
Rapid iteration; every user must be on the current version Strong Deploy once; no store review, no version fragmentation
Broad device and OS diversity with a small team Strong One responsive codebase instead of separate iOS, Android and desktop builds
Intermittent connectivity with local-first editing Moderate Achievable with a service worker and IndexedDB, but storage is evictable and the engineering cost is real
Daily habitual use needing push re-engagement on iOS Moderate to weak Possible only for installed PWAs on recent iOS versions; installation is non-obvious
Peripheral control (USB, serial, Bluetooth, NFC) across browsers Weak These APIs are Chromium-only; Safari and Firefox do not implement them
Heavy local file manipulation, OS shell integration, system-wide shortcuts Weak Blocked by the sandbox; a desktop application is the appropriate choice
Sustained high-performance 3D, large-dataset computation Moderate WebGL/WebGPU and WebAssembly close much of the gap, but memory limits and thermal behaviour still favour native

A worked example clarifies the reasoning. Suppose a university wants a module-enrolment tool used by 20,000 students over a two-week window each year, from a mix of personal laptops, library PCs and phones, with a hard accessibility obligation and no budget for app-store maintenance. Usage is intermittent, the audience is device-diverse, link-sharing from email matters, the only hardware requirement is an optional camera for uploading an ID photo, and the data is server-authoritative anyway. The web is unambiguously correct here, and the remaining design work is responsive layout, WCAG 2.1 AA conformance, a declared browser matrix driven by the institution's analytics, graceful behaviour on the campus Wi-Fi's variable latency, and a clear fallback for the photo upload where camera access is denied.

Contrast that with a warehouse picking application used for eight-hour shifts on rugged handhelds with a hardware scanner trigger, in a building with dead zones, where every second per pick is measured. Here the constraints point the other way: the sandbox cannot bind the physical trigger key, cross-browser peripheral access does not exist, and evictable local storage is unacceptable for hours of queued work. A native or hybrid application with a web-based management console is the better split — and articulating that split, with the evidence behind it, is exactly the kind of justified platform decision a project scope document should record.

Alignment with Learning Outcomes

  • MO1: This topic supplies the web half of the platform comparison by setting out the web's distinctive HCI constraints — browser-mediated navigation, responsive multi-device layout, WCAG obligations, sandbox limits on hardware and file access, and network dependence — in terms that can be contrasted directly with mobile and desktop characteristics and matched against target user needs.
  • MO2: The suitability table, browser-support tiering, capability matrix and the two worked scenarios give concrete, evidence-based criteria for choosing the web (or rejecting it) and for justifying that choice against stated requirements such as reach, update cadence, offline behaviour and peripheral access.
  • MO3: The material feeds scope documentation directly: declared browser support tiers, responsive breakpoints, accessibility conformance level, offline and latency behaviour, and permission fallbacks are all explicit constraints and testable success criteria that can be written into a project scope.
NotesThe body uses only the permitted tag set with one exception to flag: a <kbd> element appears in the accessibility bullet on keyboard focus ("reachable by Tab"); replace it with <code>Tab</code> or plain text if strict tag conformance is required. Figures cited (WCAG 2.1 AA contrast ratios, 44×44 px touch targets, the 0.1 s / 1 s / 10 s response-time thresholds, Safari's seven-day storage eviction for non-installed sites) are stable, well-documented values, but API support status — particularly iOS PWA push, File System Access, Web Bluetooth/USB/Serial/NFC — changes over time and should be re-checked against caniuse.com or MDN before the material is delivered. The browser-support tier table is deliberately illustrative; students should be encouraged to populate it from their own project's analytics rather than copying the example scope.
2

Videos on This Topic

▶

The web is the most broadly reachable application platform available to you. A web app runs inside a browser, which means a single codebase can be opened on a laptop, a tablet, a phone, or a shared kiosk without anyone installing anything. That reach comes with trade-offs: you inherit the browser's capabilities and limits, you depend on a network connection, and you must design for screen sizes and input methods you cannot predict in advance.

In this module you are deciding which platform fits your project. To make that call for the web, you need a working picture of three things: how web applications are typically structured (a client in the browser talking to a server over HTTP APIs), the design conventions users already expect from web pages, and the constraints that shape what a browser-based interface can realistically do. Those three threads map directly onto the subtopics for this topic.

The videos below approach the web platform from three angles: the communication layer that connects a web front end to its back end, the difference between responsive and adaptive approaches to varying screens and capabilities, and practical visual conventions for web layout. As you watch, keep asking what each idea implies for your own project proposal: what would it cost you in effort, what would it give your users, and where would the browser get in your way.

3

Video 1: What Is REST API? Examples And How To Use It: Crash Course System Design #3

▶

ByteByteGo · 5:21 · 1,461,297 views · 4y ago · captions — Watch on YouTube

About this video

A short crash-course explanation of REST APIs: what they are, how clients and servers exchange data over HTTP, and how requests and responses are typically structured, with examples. The video is part of ByteByteGo's system design series, so it frames REST in the context of how real applications are built.

Why this video

Web applications almost always separate a browser front end from a server back end, and REST is the most common way those two talk; understanding this gives you concrete grounding for the Web Platform Overview subtopic and for the network-dependence constraint of web apps.

4

Video 2: Adaptive vs. Responsive | Decoding Flutter

▶

Flutter · 5:09 · 119,135 views · 4y ago · captions — Watch on YouTube

About this video

The Flutter team explains the distinction between responsive design (adjusting layout to the amount of available screen space) and adaptive design (adjusting behavior to what the platform itself can do). Expect definitions, the reasoning behind each, and examples of when you would apply one, the other, or both.

Why this video

Responsive versus adaptive is the central vocabulary for discussing how a single web experience serves many devices, which speaks directly to cross-device reach and to Web Platform Constraints and Considerations; it comes from a platform team that deals with multi-device UI daily.

5

Video 3: Give Me 7 Minutes & Your Web Design Skills Will Take Off

▶

Self-Made Web Designer · 7:15 · 468,055 views · 1y ago · captions — Watch on YouTube

About this video

A fast, practical walkthrough of web design fundamentals from a working designer, covering common improvements to layout, spacing, typography and visual hierarchy that make pages feel polished. The framing is concrete tips you can apply immediately rather than abstract theory.

Why this video

It gives you the conventional patterns users already expect from web pages, supporting the Web Design Conventions subtopic with practitioner-level, applicable guidance you can carry into your own prototype.

6

How These Videos Support the Learning Outcomes

▶

Together these videos build the platform-specific knowledge MO1 requires: the REST video clarifies the client-server, network-dependent nature of web applications; the adaptive-versus-responsive video shows how web interfaces must stretch across screen sizes and device capabilities; and the web design video grounds the conventions users expect in a browser. That understanding of web strengths and limits is what lets you argue in MO2 why the web is or is not the right choice for your project, and it supplies concrete constraints and considerations, such as connectivity, browser capability, and multi-device layout, that you can name explicitly in the scope document required by MO3.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Platform Selection: Criteria and Decision-Making

1

Platform Selection: Criteria and Decision-Making

▶

Every interactive product begins life as an abstract idea — a set of tasks someone needs to accomplish, a problem someone needs solved. Before a single screen is sketched, however, a decision must be made that will constrain almost everything that follows: on what platform will this interface live? Will users reach it through a mobile app installed on a phone, through a browser on any device, through a desktop application that lives in the operating system's taskbar, or through some combination of these? This is not a technical formality to be settled later by developers. It is a design decision of the first order, because the platform determines the screen real estate available, the input modalities at hand, the interaction conventions users will expect, the hardware the interface can reach, and the conditions under which the product will be used.

A poor platform choice is extremely expensive to reverse. Teams that discover six weeks into development that their field-inspection tool cannot function in a basement with no mobile signal, or that their data-heavy analytics dashboard is unusable on a 6-inch screen, face a rewrite rather than a refinement. Conversely, a well-reasoned platform choice makes a great many subsequent design decisions almost automatic: the platform's human interface guidelines supply navigation patterns, control styles, gesture vocabularies, and accessibility hooks that the team can adopt rather than invent.

Platform selection is therefore best treated as a structured evaluation against four broad families of criteria: the audience and their context, the technical capabilities the product requires, the team's realistic capacity to deliver, and the discipline of documenting and defending the resulting choice. The sections that follow examine each in depth.

User audience as a primary driver. The single most common failure in platform selection is choosing the platform the team finds interesting rather than the platform the users already inhabit. A platform that your audience does not own, cannot install, or will not open is a platform that does not exist from the user's point of view. Audience analysis must therefore precede and dominate the decision.

Begin with device ownership and daily usage. It is not enough to know that a user "has a smartphone"; almost everyone does. The question is which device is actually in their hands at the moment the task arises. Consider three contrasting audiences:

  • Warehouse pickers in a distribution centre. They carry ruggedised handheld scanners or company-issued Android devices. They do not sit at desks. A desktop application is literally unreachable during the task. A mobile app, or at minimum a responsive web app optimised for a small touchscreen with large targets usable while wearing gloves, is the only viable option.
  • Secondary school teachers preparing lesson materials. Their task happens at a desk, often on a school-issued Windows laptop locked down by an IT administrator who forbids software installation. Here a browser-based web application is strongly indicated — not because the web is technically superior, but because installation privileges are the binding constraint.
  • Independent music producers. They work at a workstation with a large or multi-monitor display, a MIDI keyboard, an audio interface, and expect low-latency processing. A native desktop application is almost mandatory; the browser's audio latency and limited hardware access would make the product feel broken.

Useful evidence for this stage includes analytics from any existing product (what proportion of sessions come from mobile versus desktop, and on which operating systems), market or institutional data about device penetration in the target region or organisation, and direct user research — contextual inquiry, surveys, or interviews that ask not "do you own a tablet?" but "walk me through the last time you did this task; what were you holding?"

Next, examine the context of use. Context determines far more than screen size. A mobile context typically means short, interrupted sessions, one-handed operation, variable lighting, background noise, unreliable connectivity, and divided attention. A desk context typically means long sessions, two hands on a keyboard, a precise pointer, a stable network, and sustained focus. These differences cascade directly into interface design: a form that is perfectly reasonable as twelve fields on a desktop screen must be re-conceived as a multi-step wizard with generous touch targets on a phone.

Context dimension On the go (mobile) At a desk (desktop) Mixed / both
Typical session length 30 seconds to 3 minutes, frequently interrupted 15 minutes to several hours, sustained Quick capture on mobile, deep work on desktop
Primary input Thumb/touch, voice, camera Keyboard and precise pointer, shortcuts Must support both input vocabularies
Attention available Partial; user may be walking or supervising High; user is seated and focused Varies by session
Connectivity assumption Intermittent, metered, sometimes absent Stable broadband, usually unmetered Must degrade gracefully
Information density tolerated Low — one primary task per screen High — tables, side panels, multiple views Responsive or adaptive layouts required
Typical platform fit Native or hybrid mobile app Desktop app or desktop-class web app Responsive web app, or a mobile companion to a desktop core

A common and productive resolution to a genuinely mixed context is the companion model: a primary platform that carries the full feature set, plus a deliberately reduced secondary experience on another platform. A field-survey product might place full project setup, data analysis, and report generation in a web application, while a mobile app handles only the three things that genuinely must happen in the field — capture a photo, record a GPS-tagged observation, and add a short note. Designing the mobile companion as a subset chosen on purpose is vastly better than attempting to squeeze the whole web interface onto a phone.

Third, consider user technical proficiency. Interaction patterns are learned, and users transfer their learning across applications on a platform they use daily. An audience of older adults who have used Windows for twenty years but have never installed an app from an app store will find a conventional desktop application with menus, dialog boxes, and a visible file system far more legible than a gesture-driven mobile interface with hidden navigation drawers and swipe-to-delete actions. Conversely, an audience of teenagers will find a mobile app with bottom-tab navigation and pull-to-refresh entirely transparent, while a desktop application with a ribbon toolbar may feel archaic and intimidating. The principle at work is consistency with the user's existing mental model: choosing the platform whose conventions the audience has already internalised reduces the learning burden before you have designed anything.

Low proficiency also argues against platforms that impose procedural overhead. Installing a desktop application requires locating an installer, granting administrator permission, and trusting a security prompt — a sequence that defeats many non-technical users. A URL defeats almost nobody. For a one-off public interaction such as a council consultation survey or a museum exhibit guide, the web's zero-install property is frequently decisive on proficiency grounds alone.

Fourth, weigh the accessibility needs of the audience, which can tip the decision outright. Each platform offers a different accessibility infrastructure, and each imposes different risks:

  • Mobile platforms ship with mature, universally available screen readers (VoiceOver on iOS, TalkBack on Android), system-wide dynamic type scaling, high-contrast and reduced-motion settings, switch control, and voice control. If the app uses standard native components and sets accessibility labels correctly, much accessibility support comes for free. The risk is small touch targets and reliance on gestures that are difficult for users with motor impairments or tremor.
  • The web has the richest formal accessibility standard (WCAG) and the broadest assistive-technology ecosystem, including desktop screen readers such as NVDA and JAWS, browser zoom, and user stylesheets. Semantic HTML is accessible by default. The risk is that heavily customised JavaScript components — custom dropdowns, modal dialogs, drag-and-drop canvases — break keyboard operability and screen-reader semantics unless ARIA is applied with real care.
  • Desktop platforms offer excellent keyboard access, full-screen magnification, and tight integration with specialised assistive hardware such as braille displays, alternative keyboards, and eye-tracking systems that a browser sandbox may not reach as reliably.

If your audience is, say, visually impaired students using braille displays and desktop screen readers in a university computer lab, a desktop or carefully-built semantic web application is appropriate and a gesture-heavy mobile app is not. If your audience includes users with limited dexterity, large touch targets on a tablet may outperform a mouse-driven desktop interface. The point is that accessibility is not a layer applied after platform selection; it is an input to it.

Platform capability alignment. Once the audience narrows the field, the product's functional requirements must be tested against what each candidate platform can actually deliver. The disciplined way to do this is to enumerate the required capabilities first, as a checklist, and only then ask which platforms satisfy them — rather than choosing a platform and afterwards discovering what it cannot do.

Start with hardware features. Write down every physical capability the core user tasks depend on: camera (still, video, continuous frame access for scanning or augmented reality), microphone, GPS and background location, accelerometer, gyroscope, magnetometer, barometer, proximity and ambient-light sensors, biometric authentication, NFC, Bluetooth Low Energy, haptic feedback, push notifications, and access to the device file system or peripheral devices such as printers, scanners, and serial instruments.

Required capability Native mobile Web (modern browser) Native desktop
Camera capture (single photo) Full control over focus, exposure, frame rate Available via getUserMedia / file input; limited low-level control Available, but device may have no camera
Continuous background GPS tracking Supported with user permission and background modes Not reliable — suspended when tab is backgrounded Rarely applicable; devices usually stationary
Motion sensors (accelerometer, gyroscope) High-frequency access, low latency Available but rate-limited and permission-gated; inconsistent across browsers Generally absent
Biometric authentication Face/fingerprint APIs available Via WebAuthn / passkeys, increasingly well supported Platform-dependent (Windows Hello, Touch ID)
Bluetooth peripherals Full BLE and classic Bluetooth support Web Bluetooth: partial, not supported in all browsers Full support via OS APIs
Local file system access Sandboxed, limited Sandboxed; File System Access API partial support Unrestricted (subject to OS permissions)
Push notifications Mature and reliable Supported, with platform-specific caveats Supported via OS notification centre
Offline operation Native by default; local database available Possible via service workers + IndexedDB; requires deliberate engineering Native by default
Heavy computation / large datasets Constrained by battery, thermal limits, memory Constrained by browser sandbox; WebAssembly and WebGPU help Strongest — full CPU/GPU, large RAM, multi-threading

The second question is performance intensity. Some features are not merely "features" but sustained computational demands: real-time video effects, 3D rendering, audio processing with sub-10-millisecond latency, machine-learning inference on-device, CAD modelling, or manipulation of datasets measured in gigabytes. For these, the margin matters. A web-based photo editor handling 2-megapixel images is entirely feasible; the same editor handling 100-megapixel RAW files with non-destructive layer stacks will struggle against browser memory limits and will almost certainly be better served as a native desktop application. Likewise, a mobile app performing continuous on-device object recognition needs native access to the device's neural accelerator; a JavaScript implementation would drain the battery and overheat the phone within minutes. A useful heuristic: if the feature would make a user notice lag, dropped frames, or a hot device, it belongs on a platform with native access to the relevant hardware.

Third, decide explicitly whether web APIs are sufficient or native APIs are necessary. The web platform has advanced enormously — service workers, IndexedDB, WebRTC, WebAssembly, WebGL and WebGPU, Web Bluetooth, Web Serial, WebAuthn, the File System Access API — and the honest answer for many projects today is that the web is sufficient. But three qualifications apply:

  • Support is uneven. Several of these APIs are implemented in Chromium-based browsers but not in Safari or Firefox. If your audience analysis shows a large proportion of iPhone users, iOS browsers all run on the system WebKit engine, so a Chromium-only API is effectively unavailable to them. Capability tables must be read against your audience's actual browsers, not against the best-case browser.
  • Permissions and background execution differ. A browser tab can be throttled or discarded by the OS; a native app can register background tasks. Anything that must keep running when the user switches away — step counting, geofencing, large uploads, sync — argues for native.
  • Platform integration differs. Share sheets, widgets, deep links, Siri/Assistant shortcuts, app-store discoverability, and home-screen presence are native strengths. Installable Progressive Web Apps narrow but do not close this gap.

Fourth, treat offline functionality as a first-class requirement rather than an afterthought. Ask precisely what the user must be able to do with no connectivity, and for how long:

  • No offline requirement — e.g. an internal dashboard used only on the office network. The web is unconstrained here.
  • Read-only offline — e.g. a conference schedule or a field reference manual. A web app with a service worker caching the app shell and content is entirely adequate.
  • Offline capture with later sync — e.g. an environmental surveyor recording readings in a forest for six hours. This requires a durable local store, a queue of pending writes, conflict-resolution rules, and clear interface feedback about sync state (pending, syncing, synced, failed). Technically possible on the web via IndexedDB, but native mobile platforms provide more robust storage guarantees and are less likely to have their data evicted by the browser under storage pressure.
  • Fully offline operation — e.g. a clinical tool in a remote facility with no network at all. Native mobile or desktop is the realistic answer.

Note also the interface implications of offline support. An offline-capable design must communicate state honestly: show when data was last synchronised, indicate which records are local-only, never silently discard a user's work, and avoid interface patterns such as infinite scroll or server-side search that simply break when the network disappears.

Team skills and tool availability. The third criterion is often treated as embarrassing to mention, as though acknowledging a team's limits were an admission of weakness. It is the opposite: an honest capability assessment is a core element of professional judgement. An excellent design that the team cannot build, test, and ship within the available time is worth less to the user than a good design that actually reaches them.

Begin with a frank skills inventory. For each candidate platform, list what the team already knows and what it would have to learn. Distinguish between programming skills (languages, frameworks, build tooling, state management, testing, deployment) and design skills (familiarity with the platform's human interface guidelines, its component libraries, its gesture and navigation conventions, its accessibility APIs, its typography and spacing norms). A team fluent in HTML, CSS, and JavaScript has a far shorter path to a polished responsive web application than to a native iOS app in Swift with SwiftUI, even though the latter might be marginally better suited to the task on capability grounds alone.

Platform route Core skills required Typical learning curve for a web-skilled team Main risk
Responsive web app HTML, CSS, JavaScript, a UI framework, responsive and accessible design Low — builds directly on existing skills Capability ceiling for hardware-dependent features
Progressive Web App As above, plus service workers, caching strategies, offline data modelling Low to moderate Inconsistent platform support; cache-invalidation bugs
Cross-platform mobile (React Native, Flutter) JavaScript/TypeScript or Dart, mobile navigation patterns, native build toolchains Moderate — familiar language, unfamiliar platform conventions and build process Native modules and store submission still require platform knowledge
Native iOS Swift, SwiftUI or UIKit, Xcode, Apple HIG, App Store review process High Requires macOS hardware and a paid developer account
Native Android Kotlin, Jetpack Compose, Android Studio, Material Design, device fragmentation High Testing across many screen sizes and OS versions
Native desktop (Electron / Tauri) Web skills plus packaging, auto-update, OS integration, code signing Moderate Large bundle size; per-OS installers and signing certificates
Native desktop (WPF, Qt, Cocoa) C#, C++, or Swift; platform-specific UI toolkit High Little reuse across operating systems

The learning curve must be costed, not just acknowledged. In a twelve-week project, a team that must learn Swift from scratch will realistically spend three to four weeks reaching basic competence — time subtracted directly from user research, prototyping, usability testing, and iteration. Since HCI quality comes overwhelmingly from iteration against real users, spending a third of the schedule on language acquisition usually produces a worse interface than building on familiar ground. A reasonable rule of thumb: adopt at most one significant unfamiliar technology per project, and make sure it is the one that buys the most user value.

Tool availability imposes hard constraints that no amount of enthusiasm can overcome. These are worth checking before any decision is announced:

  • Operating system requirements. Building and signing an iOS application requires Xcode, which runs only on macOS. A team working entirely on Windows and Linux machines cannot ship to the App Store without acquiring Mac hardware or a cloud build service.
  • Accounts, licences, and fees. Apple's developer programme charges an annual fee; Google Play charges a one-off registration fee. Code-signing certificates for Windows desktop distribution cost money. Some design and IDE licences are paid. In a student or small-team context these can be prohibitive.
  • Hardware for testing. You cannot evaluate a mobile interface honestly on a desktop simulator alone. Touch target sizing, thumb reach, outdoor legibility, and performance on a mid-range device all require physical devices. If the team owns only high-end phones, it will systematically underestimate load times for users on older hardware.
  • Institutional restrictions. University or workplace machines may block software installation, restrict network ports, or prevent connecting devices for debugging.
  • Distribution gates. App store review introduces delays measured in days and the possibility of rejection; web deployment is immediate. For a time-boxed academic project, that difference can matter more than any technical consideration.

Taken together, these points support an important and sometimes counter-intuitive principle: choosing a platform the team can realistically deliver on is itself a valid design decision, not a compromise of design. Feasibility is a design constraint in exactly the same sense that screen size or colour contrast is a design constraint. The designer's obligation is to produce the best possible user experience within the real envelope of time, skill, budget, and equipment — not to specify an ideal that never reaches a user. A team that chooses a responsive web application because it can build, test, and iterate on it five times before the deadline will almost always deliver a more usable product than a team that chooses native iOS, spends the term fighting the toolchain, and tests with users once, late, on a half-finished build.

What this principle does not licence is using convenience as a substitute for analysis. "We chose the web because we know JavaScript" is a weak justification standing alone. "We chose the web because our audience analysis showed 70% of users access our service from locked-down institutional desktops where they cannot install software; because our feature set requires no hardware beyond file upload; and because our team's existing web skills allow us to run three rounds of usability testing within the schedule" is a strong justification in which skills play an honest supporting role alongside audience and capability evidence.

Where skills and requirements genuinely conflict, mitigation strategies exist: adopt a cross-platform framework that lets existing language skills reach a new platform; narrow the scope so the hardest capability is deferred to a later release; prototype the riskiest technical element in the first week as a spike to test feasibility before committing; or adopt the companion model and build only a thin native layer around a web core.

Documenting and justifying the platform choice. A decision that lives only in the team's collective memory is not a decision — it is an assumption waiting to be contested. The final element of platform selection is producing a written record that states the choice, grounds it in evidence, and names what was given up. This record belongs in the project description or scope document, near the front, where any reader encounters it before the detailed requirements.

First, state the chosen platform clearly and unambiguously. Vagueness here causes real downstream damage: "a mobile-friendly application" could mean a responsive website, an installable PWA, a React Native app, or two separate native apps, and each implies a different budget, different design conventions, and different testing needs. A precise statement specifies the platform type, the target operating systems and versions, the form factors supported, and the distribution method. Compare:

  • Too vague: "The system will be available on mobile and online."
  • Unambiguous: "The product will be delivered as a single native Android application, targeting Android 10 (API level 29) and above, designed for handset form factors in portrait orientation, distributed through Google Play. No iOS, tablet, or desktop version is in scope for this release."

Note that the unambiguous version also states what is not included. Explicit exclusions prevent scope disputes later and signal to the reader that the boundary was chosen rather than overlooked.

Second, provide a rationale that references the three evidence streams already gathered: audience analysis, feature requirements, and team constraints. A rationale is an argument, not an assertion, and an argument needs premises the reader can inspect. Each claim should point to something: a survey result, an analytics figure, a user quote from an interview, a capability the feature list demands, a documented tool limitation. A workable structure is:

  • Context sentence — what the product does and for whom, in one or two lines.
  • Decision statement — the platform, precisely specified.
  • Audience evidence — what the users own, where and when they work, their proficiency and accessibility needs, and why this points to the chosen platform.
  • Capability evidence — the hardware, performance, API, and offline requirements, and how the chosen platform satisfies them where rivals do not.
  • Feasibility evidence — team skills, tooling, hardware, licences, and schedule.
  • Alternatives considered and rejected — naming at least one serious rival and the specific reason it lost.
  • Trade-offs accepted — the known costs of the decision and how they will be managed or monitored.

Including rejected alternatives is what separates a justification from a rationalisation. A reader who sees that the web was considered and rejected on a named, checkable ground trusts the conclusion far more than a reader who is simply told the answer. A compact comparison table is an effective way to present this, provided the criteria are weighted according to the project's actual priorities rather than treated as equally important:

Criterion (weight) Native mobile Responsive web Desktop application
Device match to audience (high) Strong — users are mobile throughout the task Adequate — works on phones but requires connectivity Poor — users are not at desks
Offline capture for 6+ hours (high) Strong — local database, guaranteed storage Weak — browser storage may be evicted Not applicable in the field
GPS and camera access (high) Strong — full background and sensor access Partial — no reliable background location Weak — hardware usually absent
Team skills available (medium) Moderate — cross-platform framework reuses JS skills Strong — directly matches existing expertise Moderate
Zero-install access (low) Weak — store download required Strong Weak
Outcome Selected Rejected — fails the offline and background-location requirements Rejected — wrong context of use

Third, acknowledge trade-offs and limitations openly. Every platform choice forfeits something, and naming the forfeit is a mark of competence rather than weakness. Typical acknowledgements include: choosing native Android excludes iPhone users, who represent an estimated 20% of the audience, and an iOS release is deferred to a second phase; choosing a web application means the product cannot access background location, so time-stamped journey tracking is removed from scope; choosing Electron for desktop means a large download and higher memory use than a fully native application, accepted because it allows one codebase across Windows and macOS within the available schedule; choosing a desktop application means field staff must record observations on paper and transcribe them later, mitigated by a planned CSV import.

Each acknowledgement is strongest when it has three parts: the limitation, the reason it is acceptable, and the mitigation or future plan. "We accept X because Y, and will address it by Z" reassures the reader that the consequence was foreseen and is being managed, rather than discovered by them for the first time.

Fourth, write so that the rationale is persuasive to a stakeholder unfamiliar with the project. The realistic audience for this document includes a client, a module convenor, a funding panel, or a colleague joining the team in month three. Such readers do not share your context and may not share your technical vocabulary. Practical guidance:

  • Lead with the decision, then the reasons. Readers want to know the conclusion before the argument; do not build suspense.
  • Translate technical terms into consequences. Rather than "IndexedDB storage is subject to eviction under storage pressure", write "the browser may delete locally saved survey data without warning when the device is low on space, which would lose a day's fieldwork."
  • Quantify where you can. "Most users are on mobile" is weaker than "78% of sessions in the last quarter came from mobile devices."
  • Tie every reason back to a user or business outcome. A reason that only serves the development team's comfort will not persuade a stakeholder; the same reason framed as "this allows three rounds of usability testing before launch instead of one" will.
  • Keep it short and structured. Half a page to two pages, with headings or a table, is read; ten pages of prose is skimmed.
  • Date it and record who decided. Platform decisions are revisited; a dated record with named decision-makers allows future readers to judge whether the premises still hold.

A compact worked example illustrates the whole chain of reasoning in practice. Suppose the brief is a medication-adherence tool for adults aged 65 and over living independently, commissioned by a community health service.

Platform decision: Native mobile application (Android and iOS),
                   tablet-and-handset layouts, delivered via app stores
                   with assisted installation by a community health worker.
Date: 14 March    Decided by: design lead, clinical lead, development lead

Audience evidence
  - 61% of surveyed participants (n=84) own a smartphone; 34% own a tablet.
  - Task is time-triggered (medication times) and occurs at home or away.
  - Self-reported confidence with technology is low; 7 of 12 interviewees
    had never installed an app themselves.
  - 4 of 12 interviewees already rely on system-level text enlargement.

Capability evidence
  - Scheduled local reminders must fire reliably even if the app is closed.
  - Camera needed to scan medication barcodes.
  - Must work without connectivity (several participants have no home Wi-Fi).

Feasibility evidence
  - Team has Flutter experience; one Mac available for iOS builds.
  - Apple and Google developer accounts already held by the health service.

Alternatives rejected
  - Responsive web app: cannot deliver reliable scheduled notifications
    when the browser is closed. This is the product's core function.
  - Desktop app: users are not at a computer at medication times.

Trade-offs accepted
  - App-store installation is a barrier for this audience.
    Mitigation: health workers install and configure the app during the
    existing home visit, and a printed one-page guide is supplied.
  - Two platforms doubles device testing effort.
    Mitigation: Flutter shared codebase; test matrix limited to four
    representative devices agreed with the client.

Notice how each element of the framework appears, how every claim is anchored to evidence a stranger could check, and how the trade-offs are named with mitigations attached. A stakeholder reading this does not have to take the team's word for anything; they can see the reasoning and, if they disagree, point to the specific premise they dispute. That is precisely what a good platform justification should make possible.

Alignment with Learning Outcomes

  • MO1: The topic supports this outcome directly by setting mobile, web, and desktop platforms side by side against HCI design constraints — context of use, input modalities, information density, hardware and API access, offline behaviour, and accessibility infrastructure — and by relating each constraint to the needs and proficiency of specific target user groups.
  • MO2: The topic provides the selection framework and the justification structure required by this outcome, showing how to weigh audience evidence, capability requirements, and team feasibility against defined project requirements, how to compare and reject alternatives, and how to state a clear, evidence-based rationale for the platform chosen.
  • MO3: The topic contributes partially to this outcome. It addresses the constraints and documentation elements of a scope document — precise platform statements, explicit exclusions, accepted trade-offs and mitigations — but it does not cover the formulation of project objectives or success criteria, which are treated elsewhere in the module.
NotesSuggested teaching activity: give students three contrasting briefs (a warehouse picking tool, a public consultation survey, an audio production suite) and ask them to complete a weighted criteria table and a one-page justification for each, then swap and critique a peer's rationale as an "unfamiliar stakeholder". Capability support details for specific web APIs change frequently — students should be directed to check current browser support data rather than rely on the indicative table, and should read it against their own audience's browser mix.
2

Videos on This Topic

▶

Choosing a platform is one of the first real design decisions you make in an HCI project, and it constrains almost everything that follows: screen size and input method, interaction patterns, offline behavior, accessibility options, distribution, and even how users discover your app. In this topic we treat platform selection as a structured decision rather than a preference. You weigh who your users are and where they will realistically use the product, what capabilities the interface actually requires (camera, sensors, notifications, large-screen multitasking, keyboard-heavy entry), what your team can actually build with the tools and time available, and then you write the decision down with the reasoning behind it.

That last step matters more than students expect. A platform choice that is documented with criteria, alternatives considered, and trade-offs accepted can be defended to a client or instructor, revisited when requirements change, and reused as input to your scope document. An undocumented choice usually turns into an argument later in the term.

The videos below come from software architecture and system design rather than from HCI directly. Watch them for the decision-making method, not for the specific technologies: notice how each one starts from requirements and constraints, lays out options, names the trade-offs, and arrives at a justified choice. Then practice translating that same discipline to your own question — mobile, web, or desktop — where the constraints are users, context of use, and interface capability instead of servers and databases.

3

Video 1: System Design Interview: A Step-By-Step Guide

▶

ByteByteGo · 9:54 · 1,108,601 views · 3y ago · captions — Watch on YouTube

4

Video 2: How To Choose The Right Database?

▶

ByteByteGo · 6:58 · 445,628 views · 4y ago · captions — Watch on YouTube

5

Video 3: Top 5 Most Used Architecture Patterns

▶

ByteByteGo · 5:53 · 415,852 views · 3y ago · captions — Watch on YouTube

6

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Design and Development Tools by Platform

1

Design and Development Tools by Platform

▶

Choosing a platform for an interface project is only half the decision. The other half is choosing the toolchain — the combination of design, prototyping, coding, debugging, and testing tools that will carry an idea from a sketch on paper to a running application in a user's hands. Toolchains are not neutral. Each one encodes assumptions about how interfaces should be structured, what interaction patterns are "normal", and how much control a developer has over pixels, gestures, and timing. A team that prototypes in Figma using the iOS Human Interface Guidelines UI kit and then builds in SwiftUI will almost automatically produce an interface that feels native to iPhone users. A team that prototypes generic rectangles and builds in Electron will almost automatically produce something that feels like a website in a window. Neither outcome is wrong in every context, but both are consequences of tooling decisions made early, often casually, and expensive to reverse later.

This topic surveys the tools that matter for the four primary platforms considered in this module — Android, iOS, Windows desktop, and the web — plus the cross-platform frameworks that attempt to span them. The aim is not to make you an expert in any single tool, but to give you enough informed judgement to assemble a defensible toolchain for a specific project, and to articulate why that toolchain fits the users, constraints, and success criteria you have defined.

Design and prototyping tools sit at the front of every toolchain, regardless of platform. They are where interaction ideas are made visible and testable before any expensive engineering is committed. The dominant tool in contemporary practice is Figma, a browser-based design environment that supports vector design, component systems, interactive prototyping, and developer handoff in a single file. Figma's defining characteristic is that it is collaborative in real time: multiple designers, developers, and stakeholders can open the same file simultaneously, see each other's cursors, leave threaded comments pinned to specific elements, and branch a file to explore an alternative without destroying the original. For a student project this matters because it removes the version-control problem that plagued older desktop design tools — there is no final_v3_REALLY_final.sketch circulating by email.

Figma is platform-agnostic in the sense that it does not generate code for any particular platform, which is exactly why it works for all four. It produces specifications: measured spacing, colour tokens, type styles, asset exports at multiple densities, and clickable prototypes that demonstrate flow. A developer opening a Figma file in Dev Mode can inspect an element and read off its dimensions in density-independent pixels for Android, points for iOS, or effective pixels for Windows, and can copy generated CSS, Swift, or XML snippets as a starting point. The handoff is never fully automatic — generated code is a hint, not a deliverable — but it eliminates a large class of "the button is three pixels off" conversations.

The second reason Figma is central to platform-aware design is the ecosystem of platform-specific UI kits. These are published, maintained component libraries that mirror each platform's official design language:

  • Material Design (Android) — Google publishes an official Material 3 Design Kit containing buttons, navigation bars, FABs, bottom sheets, chips, snackbars, and the full Material type scale and dynamic colour system. Using it means your prototype's touch targets are already 48dp, your bottom navigation already holds three to five destinations, and your elevation shadows already follow the Material surface hierarchy.
  • iOS Human Interface Guidelines — Apple publishes an official Apple Design Resources library for Figma covering iOS, iPadOS, macOS, watchOS, and visionOS, including SF Symbols, the San Francisco type family, tab bars, navigation bars with large titles, action sheets, and standard alerts.
  • Fluent Design (Windows) — Microsoft publishes Fluent 2 UI kits covering Windows 11 controls, Mica and Acrylic materials, the Segoe UI Variable type ramp, navigation views, command bars, and content dialogs.

The HCI value of these kits is that they make convention compliance the path of least resistance. A designer who drags in an official iOS tab bar does not have to remember that iOS places primary navigation at the bottom with a maximum of five items, or that destructive actions are rendered in red in an action sheet — the component already embodies that knowledge. Conversely, when a designer deliberately departs from a kit component, that departure becomes visible and discussable rather than accidental. A practical workflow is to begin from the platform kit, document every deviation in a comment, and justify each deviation against a user need.

Before any of this high-fidelity work, however, there is a strong argument for low-fidelity wireframing, and tools such as Balsamiq exist precisely to enforce it. Balsamiq renders everything in a deliberately sketchy, hand-drawn style with a single ugly typeface and no colour palette worth speaking of. This is a feature, not a limitation. Three well-documented effects follow from low fidelity:

  • Feedback shifts from surface to structure. Stakeholders shown a polished mock-up comment on the shade of blue; stakeholders shown a sketch comment on whether the checkout flow has too many steps. The deliberately unfinished look signals that the design is still open to change.
  • Sunk-cost attachment is reduced. A wireframe that took eight minutes to produce can be thrown away without regret. A high-fidelity screen that took four hours tends to survive longer than it deserves.
  • Iteration velocity rises. It is realistic to generate six alternative layouts for a dashboard in an hour and hold a comparison session, which is how genuinely different structural ideas get surfaced.

A sensible sequence for a semester project is therefore: paper or whiteboard sketches → Balsamiq (or Figma used in a deliberately low-fidelity mode, e.g. greyscale boxes) for structure and flow → Figma high-fidelity with the relevant platform UI kit → interactive prototype for usability testing → handoff to implementation. Skipping the low-fidelity stage is the single most common cause of projects that look good and work badly.

Finally, a prototyping tool is only useful if it supports the interaction patterns native to the chosen platform. A clickable prototype that only models tap-to-navigate will validate information architecture but will tell you nothing about whether your gesture vocabulary is learnable. Platform-native interactions worth prototyping explicitly include:

  • Android: the system Back gesture or button, swipe-to-dismiss on notifications and cards, bottom-sheet drag states, pull-to-refresh, and long-press contextual action modes.
  • iOS: the interactive edge-swipe back gesture, sheet presentations with detents (half-height and full-height stops), swipe actions on list rows, context menus on long press, and the large-title navigation bar that collapses on scroll.
  • Windows desktop: hover states, right-click context menus, keyboard focus order and tab traversal, resizable and adaptive window layouts, and multi-select with Ctrl and Shift.
  • Web: hover and focus states, browser back/forward behaviour, URL-addressable states, responsive reflow at breakpoints, and keyboard accessibility.

Figma's "smart animate", component variants, drag interactions, and scroll-overflow settings can approximate most of these. Where a prototyping tool genuinely cannot express a pattern — true inertial scrolling physics, haptic feedback, voice input — the honest answer is to build a small code spike on the real platform rather than pretend the prototype has validated it. A worked example: a team designing a photo-triage app prototyped "swipe left to delete, swipe right to keep" in Figma using drag interactions and discovered in testing that participants expected the opposite mapping because of a dating-app convention they had internalised. That finding cost two hours in a prototype; it would have cost two weeks in code.

Android development tools centre on Android Studio, the official IDE built on JetBrains IntelliJ IDEA and distributed free by Google for Windows, macOS, Linux, and ChromeOS. It is a large, opinionated environment that bundles far more than a text editor. Its principal facilities are:

  • Layout tools. For traditional XML-based views, a drag-and-drop Layout Editor with a constraint-based visual canvas, a blueprint mode showing the constraint graph, and live preview across device sizes, locales, themes, and API levels simultaneously.
  • The Gradle build system, which manages dependencies, build variants (e.g. free vs. paid, staging vs. production), code shrinking with R8, and signing configurations.
  • Debugging and profiling. Breakpoint debugging, the Logcat log viewer, the Layout Inspector for examining the live view hierarchy on a running device, and profilers for CPU, memory, network, and energy — the last being directly relevant to mobile HCI, since battery drain is a usability problem.
  • Accessibility and quality checks. Lint rules that flag missing content descriptions, insufficient colour contrast, and touch targets below the 48dp minimum, plus integration with the Accessibility Scanner.

The language of modern Android development is Kotlin. Google declared Kotlin the preferred language for Android in 2019, and new platform APIs, samples, and documentation are Kotlin-first. Kotlin interoperates completely with Java — a project can contain both, and Kotlin can call Java libraries directly — but new work should be Kotlin. Its practical advantages over legacy Java for UI work include null safety enforced by the type system (eliminating a large share of the NullPointerException crashes that historically plagued Android), far less boilerplate, extension functions, and coroutines for structured concurrency. Coroutines matter for HCI directly: the main thread on Android must stay free to render at 60 or 120 frames per second, and any blocking work on it produces jank or an "Application Not Responding" dialog. Coroutines make it straightforward to move work off the main thread and back again without callback nesting.

// Kotlin coroutine keeping the UI thread responsive
viewModelScope.launch {
    _uiState.value = UiState.Loading
    val result = withContext(Dispatchers.IO) {
        repository.fetchArticles()   // network / disk work, off the main thread
    }
    _uiState.value = UiState.Success(result)   // back on the main thread
}

Jetpack Compose is Google's modern declarative UI toolkit and the recommended way to build new Android interfaces. Instead of defining a static XML layout and then imperatively mutating it from code (findViewById(R.id.title).text = "Hello"), you write composable functions that describe what the UI should look like for a given state. When the state changes, Compose recomposes the affected parts of the tree automatically. This removes an entire category of bugs in which the visible interface drifts out of sync with the underlying data.

@Composable
fun ArticleCard(article: Article, onBookmark: (Article) -> Unit) {
    Card(modifier = Modifier.fillMaxWidth().padding(16.dp)) {
        Column(modifier = Modifier.padding(16.dp)) {
            Text(text = article.title, style = MaterialTheme.typography.titleLarge)
            Spacer(Modifier.height(8.dp))
            Text(text = article.summary, style = MaterialTheme.typography.bodyMedium)
            IconButton(onClick = { onBookmark(article) }) {
                Icon(
                    imageVector = Icons.Default.BookmarkBorder,
                    contentDescription = "Bookmark ${article.title}"
                )
            }
        }
    }
}

Note two HCI-relevant details in that snippet. MaterialTheme.typography pulls type styles from the Material 3 theme, so the app inherits the platform type scale and respects the user's system font-size preference. contentDescription supplies the label that TalkBack, Android's screen reader, will announce — omitting it leaves a blind user with an unlabelled button. Compose also provides @Preview annotations that render composables directly in Android Studio without deploying to a device, which tightens the design iteration loop considerably, and it supports Material 3 dynamic colour, where the app palette is derived from the user's wallpaper.

The Android Emulator completes the toolchain. It runs a full virtualised Android system image, hardware-accelerated on modern CPUs, and allows a developer to create virtual devices spanning the fragmentation that defines Android: a small 5-inch phone at 720p, a 6.7-inch flagship at 1440p, a 10-inch tablet, a foldable with a hinge and two postures, Wear OS watches, Android TV, and Android Automotive. Beyond screen size, the emulator can simulate conditions that are tedious to reproduce physically — GPS coordinates and route playback, incoming calls and SMS interrupting a flow, poor network (2G, high latency, packet loss), battery level and charging state, device rotation, locale and right-to-left layout, dark mode, and large font scaling. Testing a layout at 200% font scale with a long German string in RTL mirroring will surface more real defects in ten minutes than an hour of tapping around in the happy path. The emulator does not replace physical devices entirely — real touch ergonomics, thermal behaviour, camera quality, haptics, and genuine one-handed reach can only be assessed on hardware — but it makes broad configuration coverage feasible for a student team with one phone between them.

iOS development tools are more tightly constrained, and the first constraint is a hard logistical one: Xcode is the required IDE for building, signing, and submitting iOS applications, and Xcode runs only on macOS. There is no supported Windows or Linux version. This single fact must be surfaced during project planning, because a team without access to a Mac (or a legitimately licensed cloud-Mac service, or a university lab machine) cannot ship a native iOS app at all. It is a classic example of a tooling constraint that should appear explicitly in a project scope document as a risk with a mitigation, not be discovered in week nine.

Xcode itself bundles the compiler toolchain, Interface Builder (for legacy UIKit storyboards and XIBs), SwiftUI live previews, the Simulator, Instruments for performance profiling, an accessibility inspector, test runners for unit and UI tests, and the signing and provisioning machinery needed to install builds on real devices and submit to App Store Connect. Code signing deserves specific mention because it reliably consumes a day of a first-time team's schedule: running on a physical iPhone requires an Apple ID and a provisioning profile, and distributing to external testers requires a paid Apple Developer Program membership and TestFlight.

Swift is Apple's modern language for all its platforms, introduced in 2014 and now thoroughly dominant over Objective-C for new work. It is statically typed, memory-safe through automatic reference counting, and designed for clarity at the point of use. Relevant features include optionals (making the possible absence of a value explicit in the type system), value-type structs and enums with associated values for precise state modelling, protocol-oriented design, and async/await with actors for safe concurrency — the same main-thread-responsiveness concern described for Android applies identically here.

SwiftUI is the declarative UI framework and the recommended starting point for new iOS projects. Conceptually it is very close to Jetpack Compose: UI is a function of state, state changes trigger re-rendering, and layout is expressed by composing small views with modifiers.

struct ArticleCard: View {
    let article: Article
    @State private var isBookmarked = false

    var body: some View {
        VStack(alignment: .leading, spacing: 8) {
            Text(article.title)
                .font(.headline)
            Text(article.summary)
                .font(.body)
                .foregroundStyle(.secondary)
            Button {
                isBookmarked.toggle()
            } label: {
                Label("Bookmark", systemImage: isBookmarked ? "bookmark.fill" : "bookmark")
            }
            .accessibilityLabel("Bookmark \(article.title)")
        }
        .padding()
    }
}

SwiftUI's strongest HCI argument is that it inherits platform behaviour by default. Using .font(.headline) rather than a fixed point size means the text automatically honours Dynamic Type, so a user who has enlarged system text for low vision gets a larger headline without any further work. Using Label with an SF Symbol gives an icon that scales with text and matches system weight. Standard controls get VoiceOver support, Dark Mode, high-contrast variants, and right-to-left mirroring essentially for free. Xcode's live previews render SwiftUI views beside the code and update as you type, and preview variants let you check a view simultaneously in light and dark mode, at the largest accessibility text size, and in several locales. Many teams still encounter UIKit, the older imperative framework, because it remains more mature for certain complex cases (highly customised collection layouts, intricate camera interfaces) and because existing codebases use it; the two interoperate through representable wrappers.

The iOS Simulator provides virtual iPhone and iPad models across screen sizes and iOS versions, launching far faster than the Android emulator because it runs the app natively on the Mac rather than emulating ARM hardware. It supports simulated location, rotation, Dynamic Type size changes, colour-blindness filters, Dark Mode toggling, slow-animation mode for inspecting transitions, and recording of video and screenshots for reports. Its limitations are significant and should be stated explicitly in any test plan: the Simulator has no real camera, no genuine Bluetooth or cellular radio, no haptic feedback, no Face ID hardware (only a simulated enrol/match menu), unreliable performance characteristics, and no way to assess thumb reach on a physically large handset. Device testing before release is therefore not optional.

Windows development tools revolve around Visual Studio, Microsoft's full-featured IDE (distinct from the lighter-weight Visual Studio Code). The Community edition is free for students, individuals, and small teams. Visual Studio provides project templates, a XAML designer with live visual tree inspection and hot reload, IntelliSense code completion, an exceptionally capable debugger with edit-and-continue, memory and CPU profilers, test runners, and integrated packaging tooling for MSIX installers and Microsoft Store submission.

The recommended modern native stack is C# with WinUI 3. C# is a mature, statically typed, garbage-collected language with first-class async/await, LINQ for data querying, and strong tooling. WinUI 3 is the current native UI framework for Windows, providing the Fluent Design control set that matches Windows 11: NavigationView for the standard left navigation pane with its hamburger collapse behaviour, CommandBar, TeachingTip for contextual onboarding, InfoBar for inline status messages, ContentDialog for modals, and materials such as Mica (a subtle wallpaper-derived window backdrop) and Acrylic (translucent blur for transient surfaces). Using these controls means an application automatically respects the user's light/dark theme, accent colour, animation-reduction setting, and high-contrast themes.

WinUI 3 ships as part of the Windows App SDK, which is the decoupling layer that solved a long-standing Windows problem. Historically, a developer could only use UI features present in the version of Windows the user had installed, which meant waiting years for adoption before new controls were usable. The Windows App SDK packages the modern UI stack and a unified set of APIs — windowing, app lifecycle, notifications, resource management, dynamic dependencies, and DWriteCore text rendering — with the application itself, so it works consistently across supported Windows 10 and Windows 11 versions and can be updated on the app's schedule rather than the operating system's. It also deliberately does not replace Win32: existing Win32, WPF, and WinForms applications can adopt individual Windows App SDK features incrementally, which matters in enterprise contexts where a twelve-year-old line-of-business application cannot be rewritten.

XAML (eXtensible Application Markup Language) is the declarative markup used to define WinUI layouts. It separates UI structure from behaviour, and its data-binding system connects UI elements to view-model properties so the interface updates when data changes — the same state-driven principle as Compose and SwiftUI, expressed in markup rather than code.

<StackPanel Padding="16" Spacing="8">
    <TextBlock Text="{x:Bind ViewModel.Title, Mode=OneWay}"
               Style="{StaticResource TitleTextBlockStyle}" />
    <TextBox Header="Project name"
             PlaceholderText="e.g. Campus Navigator"
             Text="{x:Bind ViewModel.ProjectName, Mode=TwoWay}" />
    <Button Content="Create project"
            Command="{x:Bind ViewModel.CreateCommand}"
            Style="{StaticResource AccentButtonStyle}"
            AutomationProperties.HelpText="Creates a new project with the entered name" />
</StackPanel>

Several desktop-specific HCI concerns are handled through XAML attributes: AutomationProperties feed the UI Automation tree used by the Narrator screen reader; TabIndex and KeyboardAccelerator define keyboard traversal and shortcuts, which desktop users expect far more strongly than mobile users; and AdaptiveTrigger with VisualStateManager lets a single layout reflow as the window is resized from a narrow snapped pane to a full 4K display. It is also worth noting the alternative Windows stacks you will encounter: WPF (mature, XAML-based, still widely used in enterprise), WinForms (legacy, drag-and-drop, fine for simple internal tools), and .NET MAUI (cross-platform, sharing C# and XAML across Windows, macOS, Android, and iOS, and itself built on WinUI 3 on Windows).

Web development tools have the lowest barrier to entry of any platform, which is a large part of why the web is so often the pragmatic choice for a time-boxed project. The common editor is Visual Studio Code: free, open-source, and available on Windows, macOS, and Linux. It is a text editor rather than a full IDE, but its extension marketplace closes most of the gap — syntax support for essentially every language, Prettier and ESLint for formatting and linting, Live Server for instant reload, Git integration, Docker and remote-container support, debugger integration with Chrome and Node.js, and accessibility linters such as axe or the webhint extension that flag missing alt text and ARIA misuse as you type. Its cross-platform availability also means a mixed team on different operating systems can share an identical configuration through a committed .vscode folder.

Underneath every framework and build tool, the web rests on three foundational technologies, and understanding them is non-negotiable:

  • HTML provides structure and, critically, semantics. Using <button>, <nav>, <main>, <label>, and heading levels correctly gives screen readers a navigable document outline and gives keyboard users working focus and activation behaviour for free. A <div onclick> styled to look like a button has none of that and must have role, tabindex, and key handling added manually — which is why semantic HTML is an accessibility decision before it is a coding style.
  • CSS controls presentation and responsive behaviour. Flexbox and Grid handle two-dimensional layout; media queries and container queries adapt to viewport or component size; custom properties implement design tokens shared with Figma; and prefers-color-scheme, prefers-reduced-motion, and prefers-contrast let a site respect user accessibility preferences expressed at the operating-system level.
  • JavaScript supplies behaviour, asynchronous data fetching, and state management, running in a single-threaded event loop where long synchronous work blocks rendering and input handling — the web's equivalent of main-thread jank.
<!-- Semantic, accessible by default -->
<label for="search">Search articles</label>
<input id="search" type="search" name="q" autocomplete="off">
<button type="submit">Search</button>

<!-- Visually identical, behaviourally broken -->
<div class="label">Search articles</div>
<div class="input" contenteditable="true"></div>
<div class="button" onclick="search()">Search</div>

Frameworks such as React, Vue, and Angular sit on top of these foundations. They all solve the same core problem — keeping a complex UI synchronised with changing application state — using the same declarative, component-based idea seen in Compose, SwiftUI, and XAML binding. They differ in philosophy and weight:

Framework Character Typical strengths Costs to weigh
React A library, not a full framework; JSX components plus hooks Largest ecosystem and hiring pool; shares mental model with React Native; meta-frameworks such as Next.js add routing and rendering You assemble routing, state, and data fetching yourself; many competing conventions; easy to misuse hooks
Vue Progressive framework with single-file components Gentle learning curve; template syntax close to plain HTML; official router and state libraries Smaller job market than React; two API styles (Options and Composition) can confuse beginners
Angular Opinionated full framework, TypeScript-first Batteries included: routing, forms, HTTP, dependency injection, testing; consistency across large teams Steepest learning curve; most ceremony; heavier for small projects

The honest trade-off is that frameworks accelerate development only once the learning cost has been paid. For a four-week project in which no team member has used Angular, adopting Angular will almost certainly slow you down; the time goes into dependency injection and build configuration rather than into user research and iteration. For a ten-week project building a dashboard with thirty interactive components and shared state, writing it in hand-rolled DOM manipulation will slow you down instead, because you will reinvent a worse version of what the framework already provides. A defensible rule of thumb: match framework weight to interface complexity and existing team skill, and prefer the simplest option that will not require a rewrite. A largely static informational site may need no framework at all, or only a static-site generator.

Browser developer tools in Chrome and Firefox are the web's debugging, profiling, and auditing environment, and they are essential rather than optional. The panels that matter most for interface work are:

  • Elements/Inspector — live inspection and editing of the DOM and CSS, with the box model, computed styles, Flexbox and Grid overlays, and a colour picker that reports WCAG contrast ratios against the background and will suggest a compliant colour.
  • Console — logging, error messages, and an interactive JavaScript REPL against the live page.
  • Network — request waterfalls, payload sizes, caching behaviour, and throttling presets that simulate slow 3G or offline, which is how you discover that your 2 MB hero image makes the page unusable on a bus.
  • Performance — frame-by-frame recording of scripting, layout, and paint, exposing long tasks that block input and the layout thrashing that causes jank.
  • Device toolbar / Responsive Design Mode — emulated viewports, device pixel ratios, touch input, and orientation for responsive testing.
  • Accessibility panel — the accessibility tree, computed roles and names, focus order inspection, and colour-vision deficiency simulation (Chrome also simulates blurred vision).
  • Lighthouse (Chrome) — automated audits producing scores for performance, accessibility, best practices, and SEO, including Core Web Vitals such as Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. These map directly onto user-perceived responsiveness and visual stability, making them useful, measurable success criteria for a project.

Automated audits catch perhaps a third to a half of real accessibility defects; they will flag a missing alt attribute but not an unhelpful one, and they cannot tell you whether a flow makes sense. They are a floor, not a ceiling, and must be paired with keyboard-only walkthroughs and screen-reader testing.

Cross-platform tools and frameworks exist to amortise effort across targets. Flutter, from Google, builds Android and iOS applications (plus web, Windows, macOS, and Linux) from a single Dart codebase. Its distinguishing architectural choice is that it does not use the host platform's native widgets; it ships its own rendering engine (Impeller, formerly Skia) and draws every pixel itself. The consequences are double-edged: you get pixel-identical output everywhere, a very fast hot-reload development loop, and excellent control over custom-branded design; but you also inherit responsibility for platform fidelity, because a Flutter widget only behaves like an iOS control if the framework's Cupertino library happens to replicate the current behaviour accurately. Flutter does provide both Material and Cupertino widget sets to mitigate this.

// Flutter: declarative UI in Dart
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: const Text('Articles')),
    body: ListView.builder(
      itemCount: articles.length,
      itemBuilder: (context, i) => ListTile(
        title: Text(articles[i].title),
        subtitle: Text(articles[i].summary),
        onTap: () => openArticle(articles[i]),
      ),
    ),
  );
}

React Native, from Meta, takes the opposite approach: JavaScript (usually with React and TypeScript) drives actual native platform components, so a <Switch> renders as a real Android Material switch and a real iOS toggle, with each platform's own animation and accessibility behaviour. This buys better native feel and lets web-skilled teams reuse their React knowledge and much of their business logic. The costs are a bridge/interop layer between JavaScript and native code that can become a performance bottleneck for animation-heavy or computation-heavy screens, a dependency on third-party native modules of variable quality, and more complex upgrade paths. Expo, a managed toolchain around React Native, substantially reduces setup friction and is a common choice for student projects — though note that even with Expo, producing a signed iOS build for the App Store still ultimately requires Apple's tooling and a developer account, via a cloud build service if not a local Mac.

Electron wraps a web application — Chromium for rendering plus Node.js for system access — into a desktop application for Windows, macOS, and Linux. It is the technology behind Visual Studio Code, Slack, Discord, Figma's desktop client, and Obsidian, which demonstrates that excellent products can be built this way. Its advantages are that a web team can ship a desktop app with existing skills, gain file-system, menu-bar, tray, and auto-update capabilities, and maintain one codebase for three desktop operating systems. Its costs are equally well documented: each app bundles an entire browser, so installers run to 80–150 MB and idle memory use is high; startup is slower than native; and the app does not automatically honour platform conventions such as macOS menu-bar placement, Windows accent colours, or native context menus unless the developer implements them deliberately. Tauri is a newer, lighter alternative that uses the operating system's built-in webview and a Rust backend, producing much smaller binaries.

The central HCI trade-off across all of these is that cross-platform tools may sacrifice platform-specific UI conventions, and that sacrifice is paid by users, not developers. Users do not experience your codebase; they experience whether the Back gesture works, whether the date picker looks like the one in every other app on their phone, whether Ctrl+W closes the window, whether the screen reader announces controls properly, and whether a new OS feature appears in your app this year or in two years. Jakob's Law — users spend most of their time on other products and therefore expect yours to work the same way — is the principle at stake. Concrete symptoms of convention drift include Android-style overflow menus appearing on iOS, missing support for iOS swipe-back, non-native text-selection and context menus, scroll physics and overscroll behaviour that feel subtly wrong, delayed support for new system font sizes or dark-mode variants, and inconsistent haptics.

The following comparison summarises how the options trade off against each other:

Approach Languages / tools Targets Native UI fidelity Best suited to
Native Android Kotlin, Jetpack Compose, Android Studio Android phones, tablets, foldables, Wear Highest Android-first audiences; deep OS integration; performance-critical or hardware-heavy apps
Native iOS Swift, SwiftUI/UIKit, Xcode (macOS only) iPhone, iPad Highest Apple-centric audiences; accessibility-critical work; earliest access to new OS features
Native Windows C#, WinUI 3, XAML, Windows App SDK, Visual Studio Windows 10/11 desktop Highest Enterprise desktop tools; heavy keyboard/multi-window workflows; local file and hardware access
Web HTML, CSS, JavaScript, optional framework, VS Code Any modern browser N/A — web conventions apply Broad reach, zero install, instant updates, link-shareable content
Flutter Dart, Flutter SDK Android, iOS (+ web, desktop) Medium — self-rendered widgets Strong custom branding across mobile platforms with one team
React Native JavaScript/TypeScript, React, Expo Android, iOS Medium-high — real native components Web-skilled teams needing a credible native mobile feel
Electron HTML, CSS, JavaScript, Node.js Windows, macOS, Linux desktop Low-medium — web UI in a window Reusing an existing web app as a desktop product

A practical way to decide is to ask a short series of questions and record the answers as justification. Who are the users and what devices do they actually hold? What is the team's existing skill set, and how much of the timeline can be spent learning? Is a Mac available? How much of the interface is standard platform chrome versus custom-drawn content — a game or a drawing canvas loses little by going cross-platform, whereas a form-heavy productivity tool loses a great deal? Does the app need capabilities that are awkward outside native code, such as background location, widgets, deep OS integration, or specialised sensors? How critical is accessibility, and can you test it adequately in the chosen stack? What are the distribution constraints and timeline for updates? A team that answers these honestly and writes the answers down has a defensible toolchain decision; a team that picks Flutter because a tutorial was convenient has a guess.

A final, often-overlooked point: the toolchain extends beyond design and coding tools to version control (Git with GitHub or GitLab), issue tracking, continuous integration for automated builds and tests, crash and analytics reporting, and user-testing infrastructure such as screen-recording or remote testing platforms. For a small project these can be lightweight, but choosing them deliberately — and noting them in the project scope — prevents the common failure mode in which three weeks of work exists only on one laptop.

Alignment with Learning Outcomes

  • MO1: The topic supports this outcome by exposing the concrete design constraints that each platform's tooling embodies — Material Design and 48dp touch targets on Android, the Human Interface Guidelines and Dynamic Type on iOS, Fluent controls and keyboard traversal on Windows, and semantic HTML with responsive breakpoints on the web — giving students a tool-level basis for comparing platforms against target user needs.
  • MO2: The comparison of native, cross-platform, and web stacks, together with the trade-off table and the decision questions on team skill, device access, UI fidelity, and distribution, provides the evidence base students need to select a platform and toolchain and justify that selection against stated project requirements.
  • MO3: The topic feeds scope definition by identifying tooling constraints and risks that belong in a scope document — the macOS requirement for Xcode, framework learning curves, emulator versus physical-device testing limits — and by supplying measurable success criteria such as Lighthouse accessibility and Core Web Vitals scores.
NotesTool versions and vendor recommendations change frequently (for example Material 3 expressive updates, SwiftUI releases, WinUI/Windows App SDK versioning, and React Native's New Architecture). Verify current official guidance before delivery. If students lack macOS access, flag cloud-Mac or Expo EAS build options early in project planning. Code snippets are illustrative rather than complete compilable projects.
2

Videos on This Topic

▶

Once you have a rough idea of what your project should do and who it is for, the next practical question is: what will you actually build it with? Every platform — Android, iOS, Windows, and the web — comes with its own expected toolchain, from design and prototyping software through to IDEs, UI frameworks, and testing tools. Choosing well early saves rework later; choosing poorly can lock your team into a workflow that fights your design goals or your available skills.

This topic surveys those options in two layers. The first is design and prototyping: tools like Figma that let you sketch, wire up, and test an interface before any code exists, so usability problems surface cheaply. The second is implementation: the native tool sets for each platform (Android Studio and Kotlin, Xcode and Swift, Visual Studio and .NET, plus the browser-based web stack) and the cross-platform frameworks such as Flutter, React Native, .NET MAUI, and Compose Multiplatform that promise one codebase across several targets.

As you watch, keep your own project in mind. Note what each tool assumes about your team's skills, what it makes easy versus awkward, and how much control it gives you over platform-specific interaction conventions. Pay attention to the trade-offs discussed around cross-platform work — code reuse, performance, access to native UI patterns — because those trade-offs are exactly the kind of justification you will need to write into your scope document.

3

Video 1: Figma Prototype Tutorial for Beginners

▶

Aliena Cai · 6:06 · 214,087 views · 1y ago · captions — Watch on YouTube

About this video

A short beginner tutorial on building an interactive prototype in Figma, covering how to link frames, set up interactions and transitions, and play back the result. It is aimed at people new to the tool and focuses on the prototyping mode rather than advanced design systems. Expect a quick, hands-on walkthrough rather than a deep reference.

Why this video

Figma is the de facto standard for interface design and prototyping across platforms, and this video gives a compact entry point into the prototyping subtopic from a UX-focused channel, so you can mock up and test screens before committing to a development toolchain.

4

Video 2: I Built the Same App with 6 Different Frameworks

▶

Tastemaker Design · 19:29 · 124,161 views · 6mo ago · captions — Watch on YouTube

About this video

The creator builds the same application six times using Flutter, React Native, .NET MAUI, SwiftUI, Capacitor, and Compose Multiplatform, then compares the experience and results. Expect discussion of setup, developer experience, UI capability, and the practical differences between native and cross-platform approaches. It is a comparison piece rather than a tutorial on any single framework.

Why this video

This directly serves the cross-platform tools subtopic and also touches the native iOS and Windows stacks, giving you a side-by-side basis for arguing why one toolchain suits your project better than another.

5

Video 3: Flutter for iOS developers

▶

Flutter · 13:43 · 218,630 views · 3y ago · captions — Watch on YouTube

About this video

An official Flutter video that introduces Flutter by mapping its concepts onto what an iOS developer already knows, covering ideas such as widgets, layout, and navigation in comparison to native iOS development. It is framed as an orientation rather than a full course. Viewers unfamiliar with iOS can still use it as a contrast between a native and a cross-platform mental model.

Why this video

Coming from the Flutter team itself, it is an authoritative look at how a cross-platform framework relates to a native platform's tooling and conventions — useful context when weighing iOS development tools against a shared-codebase approach.

6

How These Videos Support the Learning Outcomes

▶

Together these videos move from design tooling to implementation tooling, which is the bridge between deciding on a platform and planning the work. The Figma tutorial supports MO3 by showing how prototypes can make objectives and success criteria concrete before development starts. The six-framework comparison and the Flutter-for-iOS orientation support MO1 and MO2 by exposing the real constraints of each platform's toolchain — native UI fidelity, code reuse, and developer effort — so your platform choice can be justified against stated project requirements rather than preference alone.

7

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.