Lesson 04 / 07

Design and interaction: an app that fits the hand

A phone is driven by a thumb, not a mouse. Platform conventions, navigation patterns, gestures, screen states, and accessibility that make an app feel native.

Nobody uses your app sitting calmly at a desk with two monitors. They’re standing on a tram, holding on with one hand, driving the app with the thumb of the other, squinting at a screen they can barely see in the sun, and any second now a call will come in and kick them out of the app entirely. If you don’t keep this in mind while designing, you’ll build a beautiful app that’s genuinely awkward to use. And that’s the quietest way there is to lose a user: they don’t complain, they just uninstall.

A phone isn’t a shrunk-down website

The most common mistake is taking a desktop website (or its design) and just narrowing it until it fits on a phone. What comes out is an app full of tiny links you can’t hit and content packed so tightly you can’t move your thumb through it.

A phone has its own rules, because it gets used differently:

  • It’s driven by a thumb, not a cursor. You don’t have the precision of a mouse. Targets have to be big and spaced apart, or people will tap the wrong thing.
  • The screen is small. Less fits on it. Instead of ten options on one screen, show the three that matter and tuck the rest a level down.
  • It’s used on the move, in small bursts. A session lasts a few seconds, not half an hour. The main action has to be right there, not three taps deep.
  • Something is always interrupting. A notification, a call, losing signal in a tunnel. The app has to survive someone abandoning it mid-task and coming back an hour later. A half-filled form that gets wiped in the meantime is a reason to close the app.

Don’t ask “how does this look on the web.” Ask “what does someone need to do here, one-handed, in line at the checkout.”

Respect the platform your app runs on

Apple and Google each have their own rules for how an app should look and behave: the Human Interface Guidelines on iOS, Material Design on Android. These aren’t just style manuals. They describe what people on that phone already know and expect without even thinking about it.

An Android user expects a gesture or the system back button to take them one step back. An iPhone user expects the share button to open the familiar system panel. Break these conventions and the app feels foreign, and people get lost, even when it’s “pretty.”

  • Unify what’s yours. Colors, logo, tone, iconography. Here you want the app to look like you on both systems.
  • Honor what belongs to the system. Back gesture, sharing, date and time, picking from a list, notifications. Don’t invent your own solutions here, you’d only be setting yourself up for confusion.

A perfectly identical look on both iOS and Android sounds tempting, but it costs something. Either you let foreign elements into the app that won’t sit right with native users, or you fight the platform and pay for it in extra development. For most teams it pays off to keep a consistent brand and let each system be itself when it comes to controls.

Reach for navigation people already know

Navigation is the last place you want to be original. People have hundreds of apps in hand and they all work in similar ways. Use that similarity instead of teaching the user a new system.

  • Tab bar. Three to five main sections you switch between. Great for an app where someone moves between a few equal places (overview, search, profile).
  • Stack / push. You tap an item in a list, the screen slides in from the right, and the back button returns you. The basic pattern for “list → detail.”
  • Bottom sheet. Slides up from the bottom, shows options or supporting content, and disappears again. It’s within thumb’s reach and doesn’t yank the person out of context.
  • Modal. Covers the whole screen for one self-contained task, like signing in or entering a payment. Use it sparingly: every modal is an interruption and needs a clear “done” and “cancel.”

The rule is simple: put the main crossroads in the tab bar, go deep with a stack, and save the pop-up things for short, well-bounded tasks.

Mind thumb reach, target size, and screen states

Take your own phone and hold it in one hand. The thumb comfortably reaches the bottom half of the screen and barely touches the top corners at all. That’s why the main actions and navigation belong at the bottom, where you can hit them, not at the top, where you have to fumble and shift your grip.

  • Make targets big enough. Apple and Google both recommend a tap area of roughly 44 to 48 points. The icon itself can look smaller, but the clickable area around it has to be large.
  • Give targets some space. Two buttons glued together means people will hit the wrong one. Especially when the action can’t be undone.

And then there’s the thing designs forget most often: an app doesn’t only live in the happy path, where everything is loaded and fine. Design the other states too, or at the worst possible moment a blank white screen will “design” them for you.

  • Loading. What does someone see before the data arrives? A skeleton of the content feels snappier than a spinner going round forever.
  • Empty. First launch, an empty cart, no search results. Instead of emptiness, this is where a sentence telling them what to do next belongs.
  • Error. Internet dropped, server not responding. Say in plain language what happened and give a “try again” button. Never just leave the app silently hanging.

Accessibility on mobile isn’t an extra, it’s the standard

An accessible app can be used even by someone who sees poorly, can’t hear, or has shaky hands. Both platforms have excellent tools for this built right into the system, so you get a big chunk of it for free, as long as you think about it while designing.

  • Respect the system font size. Plenty of people have enlarged text on their phone, because otherwise they can’t read it. If you nail the text to a fixed size, their layout breaks or they simply can’t read it.
  • Account for VoiceOver and TalkBack. Screen readers read out what’s on the display. For them to work, every button and icon needs a meaningful label, not just an image.
  • Keep contrast and don’t rely on color alone. Light gray text on white looks classy and nobody can read it outdoors. And “checked is green, error is red” doesn’t help someone who can’t tell the colors apart. Add an icon or some text.

Before you send the app out into the world, go through it once one-handed with enlarged text and once with the screen reader on. Whatever you catch yourself won’t surprise you in the reviews.

Treat it as business, too. Accessibility opens you up to users you’d otherwise lose, both stores increasingly expect it, and in the EU the rules around it are tightening. An app that fits everyone’s hand is simply a better app.