Design for mobility

A phone is a different design problem, not a smaller one

Mobile products are among the harder things to build well, and the reasons split into two groups.

Development considerations. A product is expected to run on several platforms with different operating systems, different capabilities and wildly different screen sizes, which multiplies cost and makes configuration management harder. It will be written in one of several languages against one of several frameworks, and very little of it can be developed on the device itself — you work through emulators that do not faithfully reproduce the device's limits. Each platform has its own store with its own acceptance rules, so each version needs someone who knows those rules. And the market moves fast enough that development cycles are short, which is why mobile teams reach for agile process models.

Technical considerations. The screen is small and the interaction repertoire is large — touch, gesture, camera, sensors, voice — so interface design carries more weight and often means deciding what not to show. Users expect the app to use context: where the device is, what is near it, what time it is. Battery life constrains everything, so backlighting, memory traffic, radio use and processor speed are design variables rather than implementation details. Wireless traffic is hard to protect from eavesdropping and a lost device is a security event, yet policies that increase confidence usually reduce usability — a trade-off you must make deliberately. Computation and storage are limited. Thin clients depend on external services, which imports availability and security concerns you do not control. And testing is harder, because users genuinely will run the product in physically different environments.

The mobile life cycle

A widely used mobile SDLC has five stages, visited repeatedly rather than in order: inception (goals, features, scope of the first increment or feasibility prototype, including the human and organisational context), design (architecture, navigation, interface and content design, worked out through screen mock-ups and paper prototypes across the target devices), development (coding the functional and non-functional requirements, with usability and accessibility evaluation running as the product grows), stabilization (a prototype ladder — feasibility prototype proving one path, alpha with minimum viable functionality, beta largely complete and tested, then a release candidate), and deployment (store review, or a product-owner review for an internal app). The shape is an agile spiral, not a waterfall.

Thin, thick and hybrid clients

Where does the logic live? A thin client keeps almost everything on a server and renders results, which makes it easy to port across devices and easy to update everywhere at once, at the cost of needing connectivity and trusting an external service. A thick client puts logic and data on the device, which works offline and feels fast, but must be ported and updated per platform and puts data at risk if the device is lost. A hybrid client splits the two, keeping the pieces that must work offline on the device. Service-oriented and cloud architectures make thin and hybrid designs practical: the service runs on the provider's infrastructure, is loosely coupled to the app through messaging, and is treated as a black box behind an API. Cloud provision itself stacks in three layers — infrastructure, platform, and software as a service — with less control the higher you go.

Context-aware apps

A context-aware app changes what it offers based on location, time, nearby devices and the identity of the person holding it. Doing that well is harder than it looks: sensor data is noisy, miscalibrated, weather-affected and inconsistent, so a context-aware design has to fuse several sources and remain sensible when they disagree.

The design pyramid

Mobile and web design work is usually drawn as a pyramid with the user at the top and the technology at the bottom: interface design, aesthetic design, content design, architecture design, navigation design, and component-level design. Quality is judged mostly by the same generic attributes as any other software — usability, functionality, reliability, efficiency, maintainability — with portability, security, availability and scalability added, and with the reminder that a user's perception of goodness may outweigh every technical measure you have.

Worked example — BorrowBox in the rain

BorrowBox is used standing at a locker bank on a public street, one-handed, in weather, on whatever phone a member already owns — the requirement says a four-year-old Android must work. Read the constraints off the situation rather than off a checklist. Connectivity is unreliable next to a metal locker bank, so a pure thin client is wrong: the app must hold the current QR token and the member's active holds locally and reconcile later, which makes it hybrid. Because the token is now cached on the device, security must move with it — bind the token to one locker, make it single-use, and give it a short validity window, so a stolen phone is not a stolen tool. One-handed use in the rain sets a floor under touch-target size and rules out any gesture needing two fingers. Bright sun sets a floor under contrast, and a noisy street rules out an audio-only confirmation. Battery matters because a member arriving at 20% charge still has to open a door: keep the camera live only while the scanner is on screen, and cache the token so a failed network call does not spin the radio. Every one of those decisions is traceable to an attribute of the situation, which is exactly what an applied answer has to demonstrate.