App Design in New York

By treating offline as a first-class state, because for New York users the subway is frequently the only uninterrupted window they have to use anything. A product that shows an error, blocks interaction or loses entered data underground is unusable during precisely the period when people have attention available — and they will notice, because everyone here has experienced the difference between apps that work on the train and apps that do not. Practically this means content pre-fetched while connected so it is available offline, actions queued and completed on reconnection rather than failing, local persistence so nothing typed is lost, and honest visible sync state. This is an architectural decision made at the flow-mapping stage, not something that can be added once the product assumes connectivity.

Placing primary actions within thumb reach and not requiring precision, which constrains layout more than most designs allow for. The default New York usage posture is standing, in motion, holding a rail or a bag, operating the phone with one hand — so anything at the top of a large screen is genuinely awkward to reach, and small targets are unreliable when the train moves. The implications are concrete: primary actions in the lower portion of the screen, generous touch targets with spacing that prevents mis-taps, gestures that work from the edges the thumb can actually reach, and no interactions requiring two-finger precision. Destructive actions should be somewhere a stray thumb will not find them. Testing this means testing while standing and moving, not seated at a desk.

Very little before receiving something in return, and less than in most markets. The pattern that fails is asking for account creation, permissions and preferences across three screens before the product has demonstrated why any of it is worth doing — users here abandon quickly because everything is competing for a narrow attention window and there is always an alternative. What works is reaching a genuine outcome as fast as possible, ideally before requiring an account at all, then requesting permissions in context at the moment they become relevant rather than in an upfront block. Configuration should be deferred until the user has a reason to care about it. This is good practice everywhere and it is enforced here, because the market punishes the alternative faster than most.

Yes, in ways that catch out products designed elsewhere. GPS accuracy degrades substantially in dense street canyons between tall buildings, so a product that relies on precise location will place users a block or two away — which in a walking-distance city is a meaningful error rather than a rounding issue. Underground there is no GPS at all. The design responses are to allow manual location entry and correction as a first-class path rather than a fallback, to prefer neighbourhood or cross-street granularity over precise coordinates where the use case permits, and to handle the "we cannot determine your location" state as a normal condition with a useful path forward rather than an error. Products that assume reliable location work fine in testing and fail in Midtown.