Mobile app design

Most app design is judged on the screens that look good in a portfolio. Users judge it on the screens nobody photographs: the first launch, the empty list, the failed request, the moment they consider deleting it.

An app is kept or deleted in the first few minutes. That decision is made on onboarding, on what the app looks like when it is empty, and on whether the thing someone came to do is obvious. Those are design problems, and they are worth more attention than the screens that photograph well.

The screens that decide everything

First launch

The most common mistake is asking for things before giving anything: an account, a notification permission, a tour of features nobody has context for yet. Every one of those is a place people leave. The goal of a first launch is to get somebody to the value as quickly as possible and ask for permissions at the moment they make sense.

Empty states

Every list is empty on day one, and that is the version most new users see. An empty state that explains what will appear and offers the single next action does more for retention than almost any feature. An empty state that shows a blank screen is a design decision to lose people who were willing to try.

The failure states

No network, slow network, expired session, permission denied, out of storage, request failed. These get discovered during the build if they were not designed, and get improvised badly under time pressure. Drawing them costs an afternoon each and is the clearest difference between an app that feels solid and one that feels fragile.

Designing for the platform, not against it

iOS and Android have different conventions for navigation, back behaviour, sharing, typography and system controls. Users of each platform have thousands of hours of learned expectation about how those work. Shipping one design to both platforms saves a little design time and spends it on every user who finds the app subtly wrong without being able to say why.

• Respect back behaviour and gesture navigation on Android rather than reimplementing an iOS pattern.
• Use the platform's own type scale and system controls unless there is a reason not to.
• Design for the smallest supported screen first, then let it breathe on larger ones.
• Touch targets big enough to hit while walking, which is how a large share of mobile use actually happens.

Accessibility, treated as design rather than compliance

Sufficient contrast, text that scales when someone has set a larger system size, labels on controls that screen readers can announce, and not using colour alone to carry meaning. None of this is expensive if it is considered while designing. All of it is expensive to retrofit, and larger text in particular breaks layouts that assumed a fixed size.

How we work

1. Flows first. What someone is trying to do and the shortest honest path to it. Reversing a flow decision here costs a conversation.
2. Wireframes, to argue about structure without arguing about colour.
3. Interface design, including every state, not only the populated happy path.
4. Handover into build, done by the same team, so the intent behind a decision does not have to be reconstructed.
5. Iteration on live usage after launch, because the first design is a hypothesis.

The cheapest design decision is the one made before code exists. The most expensive is the one made after launch, when changing it means a release, a review, and everyone who already learned the old way.

Why we take retention seriously

We run our own apps, so a design that looks good and retains badly costs us directly rather than being someone else's problem after handover. That tends to make us conservative about anything that adds friction early and enthusiastic about the unglamorous work of onboarding and empty states.

It also means we will push back on requests that look good in a review and hurt in use. That is usually the most valuable thing a design partner does.