The mobile keyboard is a design surface

The first time I watched a real person enter a postcode on a checkout I’d designed, the keyboard opened with letters, not numbers. They tapped the 123 key, mistyped, switched back, tried again. It took them twenty-eight seconds.

I had spent four weeks on that page. I had not spent four minutes thinking about the keyboard.

Mobile keyboards are one of the most overlooked parts of our craft. They appear and disappear outside our control. When they’re up they cover roughly 45% of the screen. They suggest things you didn’t ask for, and they change what people can reach. If you design a mobile form without thinking about the keyboard, you are designing a desktop form and hoping.

• 28s to type one postcode
• 45% of the screen hidden by the keyboard

Show the right keyboard for each field

This is the easiest win, and I still see it missed on live checkouts in 2026.

Each field can tell the phone which keyboard to show. It’s a small setting in the code, and it’s the designer’s job to say which one each field needs. Get it right and you remove keystrokes entirely.

• Number pad for postcodes, card numbers and one-time codes.
• Number pad with a decimal point for prices and weights.
• Phone keypad for phone numbers. On iOS it’s also great for card numbers, because the digits are big and well spaced.
• Email keyboard for email addresses.

Let the phone fill things in

Fields can also be labelled with what they contain: name, email, postcode, card number and so on. Browsers and password managers rely on these labels. With the right one, the phone offers the person’s saved details above the keys, and they fill the field with one tap. With the wrong label, or none, they type it all by hand.

One label deserves special mention: the one for one-time codes. It lets the phone suggest the code from a text message the moment it arrives. If your sign-in flow doesn’t use it, fix it today. It’s a one-line change at one of the most nervous moments in the whole journey.

Don’t let the keyboard hide your button

When the keyboard opens, the visible screen shrinks, and not always in a tidy way. On iPhones, a layout sized to “the full height of the screen” doesn’t shrink by default, so anything pinned to the bottom ends up behind the keyboard. On Android it depends on a setting, and the defaults changed in late 2023.

In practice, a “Continue” button pinned to the bottom vanishes the moment someone taps into a field. They have to close the keyboard or scroll to find it.

Developers have fixes for the sizing. The design fix matters more: keep the main action close to the field people are typing in, not stuck to the bottom of the page. A button straight after the last field works. So does a sticky button the form scrolls into view.

A button that the keyboard hides has the same conversion rate as a button that doesn’t exist.

Thumbs move when the keyboard is up

This is something I’ve never seen written down, but I’ve watched it in maybe a hundred user tests. When the keyboard is up, the thumb hovers near the keys, not the middle of the screen. Anything in the top third of what’s visible gets much harder to reach without changing grip.

So a “show password” toggle in the top right is effectively out of reach. The same goes for a country picker sitting above an address form, or a back arrow in the header. People either close the keyboard or shift their grip, and often lose their place.

The fix is to keep small, secondary actions right next to the field they affect, not at the edges of the screen.

When autofill helps, and when it hurts

Autofill is one of the quiet wins of the modern web, but it also causes bugs. Two come up again and again.

First, group fields the way the browser expects. If you split one address line into “house number”, “street” and “town”, the browser may not recognise it as an address and won’t fill it in. If you need separate fields for visual reasons, each one has to be labelled with its exact part of the address.

Second, keep shipping and billing apart. If the fields don’t say which address they belong to, the browser reuses one for the other. I’ve debugged checkouts where the only bug was this missing label, and addresses were quietly leaking from one form into the other.

Typing in other scripts

This one I missed for years. People typing Chinese, Japanese, Korean or Vietnamese often build each character in a few keystrokes before it’s committed. If your form checks the field on every keystroke, it checks half-finished characters and shows nonsense.

The fix is to wait until the character is finished before checking. Most form tools get this wrong out of the box, and search boxes that update on every key suffer most.

Treat it like a component

Stop thinking of the keyboard as something the phone imposes on your design. Treat it as a component whose behaviour you own. It has states: shown, hidden, opening. It has variants: letters, numbers, decimal, phone, email. It needs specifying in your design files as carefully as a button.

When I review a mobile flow now, the keyboard is the second thing I check, after the small-screen layout. I tap into each field and walk through the form with the keyboard up. Half the issues I find aren’t logic bugs. They’re keyboard bugs. They cost nothing to fix in design, and real money to leave.

Twenty-eight seconds to type a postcode is twenty-eight seconds of someone wondering whether to buy. The keyboard is part of your funnel. Design it.