Designing for one hand

Designing for one hand means assuming the person using your app is holding a coffee, a bag strap, a child or a handrail with the other one. That is not an edge case. Steven Hoober's often-cited field observations from 2013 found that about half of the people he watched were using their phone with one hand, and phones have grown a lot since then. Yet many apps still put their most important controls in the one place a thumb cannot reach: the top corner.

This post is about one-handed mobile design in practice: where thumbs actually go, what the platform guidelines say about tap targets, and a few decisions we made while sketching the list interface for our Humanly Phone concept.

Where the thumb actually reaches

Hold a phone in your right hand with your thumb resting on the screen. The thumb pivots from its base, somewhere near the bottom right edge of the phone, and sweeps an arc. Inside that arc, near the bottom and the middle of the screen, tapping takes no effort. Further out, towards the left edge and the upper half, you have to stretch or bend the thumb. The top left corner, on a large phone, usually means shifting your grip or bringing in the other hand.

That arc is the thumb zone. It is not a precise shape: it depends on hand size, phone size, grip and whether you are walking. But the pattern is consistent enough to design around. The bottom third of the screen is prime space. The top corners are the worst.

People also do not hold phones the same way for long. They cradle the phone in one hand and tap with the other hand's index finger, switch to two thumbs for typing, and shift the phone up in the palm to reach the top. Hoober's observations showed a lot of this switching. So the goal is not to put everything in the easy zone. It is to make sure the frequent, important actions are there, and that the rare ones are allowed to be a stretch.

Put frequent actions at the bottom

This is the single biggest change most apps can make.

Bottom navigation. Both iOS tab bars and Android's navigation bar component put top-level destinations at the bottom of the screen, where a thumb can switch between them without a grip change. A hamburger menu in the top left does the opposite. It hides the navigation and places it in the hardest spot to reach.

Primary actions low. The main action on a screen, such as "new message," "add to basket" or "save," belongs within the easy zone. A floating action button in the bottom right, or a full-width button just above the keyboard or the bottom edge, both work.

Content can go high. Reading does not need reach. Titles, images and information that people look at rather than tap can live in the upper half. The top of the screen is still useful. It is just not where the buttons should be.

Sheets rise from the bottom. Menus, filters and confirmations presented as bottom sheets appear right under the thumb. Centred alert dialogs with buttons halfway up the screen are harder, and top-anchored dropdowns are harder still.

Search is an interesting case. For years it lived in a bar at the top. Several major apps, and some system apps, have moved search fields to the bottom of the screen, and we think that is the right direction for anything people use often.

Tap targets: 44 pt and 48 dp

Reach is half the problem. The other half is hitting the thing once you get there, often with the side of the thumb rather than the tip, and often while moving.

Apple's Human Interface Guidelines recommend a minimum tap target of 44 by 44 points. Google's Material Design guidance recommends 48 by 48 density-independent pixels. Those are the sizes of the touchable area, not necessarily the visible icon. A 24 point icon can sit inside a 44 point target, as long as the padding around it responds to touches. The web has its own version in WCAG 2.2, which sets a lower minimum target size for accessibility and a larger enhanced one.

Spacing matters as much as size. Two 44 point targets pressed right up against each other invite mistakes, especially when one of them is destructive. Put a gap between "archive" and "delete," or better, make the dangerous one ask for confirmation or offer an undo.

We treat those minimums as the floor for rare actions. For the controls someone uses dozens of times a day, we go bigger. A thumb in a moving train is not a precise instrument.

Gestures versus buttons

Gestures are great for one hand when they are big. Swiping from the screen's edge to go back, or swiping a list item to archive it, works anywhere along the edge or row, so it barely needs aim. Pull to refresh works from anywhere in the list.

The trouble is discoverability. A gesture that is not visible has to be learned, and people who never learn it are stuck. Small gestures, like a two-finger tap or a swipe on a thin strip, are also hard to perform with one hand. So our rule is simple: gestures are shortcuts, never the only way. Every swipe action should also be reachable with a visible button, even if that button is one level deeper.

Watch out for gesture conflicts too. The system owns the screen edges for back, home and app switching. An app gesture that starts at the bottom edge or the left edge fights the operating system and loses.

Left hands and small phones

Roughly one in ten people are left-handed, and plenty of right-handed people hold the phone in their left hand while the right is busy. A left thumb has the mirror-image zone: the easy corner is bottom left and the stretch is top right.

This is a good argument for centring primary actions, or making them full width, rather than pinning everything to the bottom right. A floating button in the right corner is close for a right thumb and a reach for a left one. A full-width button at the bottom works for both. Swipe actions should work in both directions where it makes sense.

Both platforms also offer help at the system level. On iOS, Reachability lets the user pull the top of the screen down towards the thumb. Android 12 added a one-handed mode that does something similar, and several manufacturers have their own versions. These features are useful, but they are a fallback. An app that needs them for everyday use has put its controls in the wrong place.

Small phones change the maths. On a compact phone most of the screen is reachable with one thumb, so a layout designed for a 6.7 inch phone can feel cramped and bottom-heavy on a small one. Test on the smallest screen you support as well as the largest. The problems are different, and both are real.

What we did with the phone concept

The Humanly Phone is a concept, not a product, and nothing about it is for sale. But sketching its interface was a good exercise in one-handed design, because its 4.3 inch screen is small enough that most of it sits inside a thumb's reach.

The home screen is a list of eight words, set in a single column on the left. On a small screen that works for either hand, and each row is meant to be a full-width target well over 44 points tall, so you can tap the word, the space next to it, or anywhere along the row. The call screen has two large round buttons, mute and end, at the bottom, where the thumb already rests during a call. There are no controls in the top corners at all.

If we moved the same interface to a larger phone, the first change would be to anchor the list to the bottom of the screen instead of the top, so the most used tools sit closest to the thumb. We have not drawn that version yet. Our guess is that it would look a little less elegant and work better, which is often how you know it is the right one.