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.

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.

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.

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:

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.