Designed for one thumb, bad light and two spare minutes
Nobody uses your app the way it looks in the presentation. They use it one-handed on a bus, half-watching something else, until a call interrupts them. That is the situation we design for.
In short: Most apps lose most of their new users in the first minute after install, and the most reliable way to cause it is a sign-up wall standing between someone and the thing they downloaded the app to do. We design around thumbs, interruptions and impatience, and we treat the empty state, the offline state and the error state as real screens with real work to do.
The hand is the constraint
A phone held in one hand has a comfortable zone and an awkward one. The bottom middle of the screen is easy. The top far corner takes a grip change, and a grip change on a crowded train is a reason to stop. So the actions people repeat sit low and central, destructive actions sit away from where a thumb naturally lands, and nothing important hides behind a gesture with no visible clue that it exists.
Reach zones
Primary actions in the easy arc, secondary actions above them, and rarely used settings wherever they like. Tall phones make this more important, not less.
Targets you can hit while moving
Tap areas follow the platform minimums with space between them. A finger is not a cursor, and neither Apple nor Google guessed those numbers at random.
Legible in sunlight
Contrast checked against the standards, not against a bright office monitor. Pale gray on white disappears outdoors and for anyone over forty.
Survives interruption
A call, a message, a locked screen. Half-finished input is kept, and coming back lands where you left rather than at the start.
The first sixty seconds are where apps die
Getting the install was the hard part. Someone saw your app, decided it might solve something, waited for a download and opened it. That is more effort than a website ever asks for, and it is the highest intent they will ever have. Most apps spend that goodwill immediately.
A sign-up wall on the first screen is the most reliable way to lose them. It asks for an email address, a password and trust before the person has any evidence the app is worth it. A carousel of feature slides is the polite version of the same mistake. Both put your priorities ahead of theirs while they are still deciding whether to care.
The alternative is not complicated. Let people see or do the valuable thing first, with sample content if that is what it takes. Ask for an account at the moment it becomes necessary, and say why in one line. Ask for notification and location permissions after the app has shown what it will do with them, not on launch. Every field in that first form should be defensible, because each one costs you people. When the app has to have accounts from the first tap, say so honestly on the screen and make signing in take seconds, which usually means the platform sign-in options rather than a form.
Empty, offline and broken are screens too
Designs are usually presented full. Lists with twelve items, a dashboard with a year of history, a profile with a photo. Then the app ships and the first thing a new user sees is that same screen with nothing in it. The empty state is the state most people meet first, so it gets designed with the same care as the full one: what this screen is for, what will appear here, and the one action that starts it.
Offline is not an edge case either. Phones lose signal in elevators, on trains and in buildings. We design what is readable without a connection, what can be queued and sent later, and how the app tells someone that their action is waiting rather than lost. Errors get the same treatment. A message should say what happened, whether the person can fix it, and what to try. Something went wrong is not a design, and neither is a spinner that never resolves. Loading states, retry paths and slow-network behavior all belong in the design files, which is also what makes them testable before release.
What you get, and what the developers get
Work starts with the two or three things people came to do, mapped as flows before anything is styled. Then wireframes, then a design system of type, color, spacing and components that scale to the whole app. Prototypes go on a real device, in a real hand, because a layout that looks generous on a laptop can be cramped on a phone and you only find that out by holding it.
Handoff includes every state of every component, both platforms where they differ, dark mode where you want it, larger text settings, and the copy in place rather than filler. Developers should not have to invent the answer to what happens if this is empty. If you also run a web product, the design system is built so the two can share a visual language with the rest of your interface work instead of drifting apart.
What we won’t do
We won’t put a sign-up wall in front of the value
Marketing teams ask for it because it fills the database. It empties the app instead. If your product genuinely cannot work without an account first, we will design that honestly, but we will not put one there to collect addresses.
We won’t hand over a design that only shows the happy path
Empty, loading, offline, error, permission denied and long-content states are part of the deliverable. Leaving them out looks faster and simply moves the design work onto a developer at build time.
We won’t trade contrast or tap size for a look
Thin light gray text and tiny targets photograph beautifully and fail in daylight, in a moving car, and for anyone whose eyesight or hands are not perfect. If a style choice costs usability, the style loses.
Where are your new users dropping out?
Show us the first three screens someone sees after install. We will tell you what is costing you people and what we would change first.
Can you redesign our existing app instead of starting over?
Usually yes. We look at where people stop, what the support inbox says and how the current screens are built, then propose the smallest set of changes that moves the number. A full redesign is sometimes right, but it is not the default answer.
Do iOS and Android need separate designs?
They share the structure, the content and the brand. They differ in navigation patterns, system controls and typography, and forcing one platform to imitate the other makes the app feel wrong to half your users.
Do you test designs with real users?
We test on real devices as a matter of course, and with real users whenever you can give us access to a handful of them. Watching five people try a flow tells you more than another round of internal opinions.
What do developers actually receive?
Flows, screens, a component library with every state, spacing and type rules, both platforms where they differ, dark mode and larger text if in scope, and final copy rather than placeholder text.
