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.

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.

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.