Form Design That Feels Like Two Fields, Not Ten

Every field in a form is a small interview question, and nobody likes being interviewed by a stranger.

That’s the frame I’ve come to after looking at a lot of signup and checkout forms. The usual advice is “fewer fields,” and it’s not wrong, but it’s incomplete in an interesting way. I’ve seen four-field forms that feel like paperwork and eight-field forms that feel like nothing. The variable that matters isn’t the count. It’s the perceived effort, and perceived effort is governed by things you can design.

Start with the question of what you actually need right now, as opposed to what you’ll need eventually. Most forms conflate the two. A company wants the phone number eventually, for the sales team, so the signup form asks for it now. But “now” is the worst possible moment to ask. At the point of signup, the visitor hasn’t received anything from you yet. They’re extending credit. Every additional question raises the price of that credit, and phone number is an expensive question, because everyone knows what companies do with phone numbers. The fix is deferral: ask for the minimum needed to deliver the first unit of value, deliver it, and then ask for more. A person who has gotten something from you answers questions far more willingly than a person who hasn’t. This is just how trust works between humans, and forms are conversations between humans, with extra steps.

Then there’s the work you can do for the visitor instead of asking them to do it. Browsers have gotten genuinely good at filling forms, but only if you let them. The autocomplete attribute in HTML exists precisely for this: mark a field as autocomplete="email" or autocomplete="postal-code" and the browser can fill it in one gesture. Set type="email" and phones show a keyboard with the @ sign on it. Use inputmode="numeric" for card numbers and the number pad appears. None of this reduces the field count. All of it reduces the effort. A form the browser fills for you feels like zero fields no matter how many boxes are on the screen.

Splitting is another trick that works better than it should. One name field beats separate first and last name fields, not just because it’s fewer boxes but because separate fields impose a model of names that isn’t universally true, and forcing people to shred their own name into your schema is a small indignity. In the other direction, a long form split into two honest steps often outperforms the same form on one page, because the first step looks easy, and looking easy is what gets people to start. Once someone has completed step one, finishing feels like protecting an investment rather than starting a chore. The caveat is honesty: a progress indicator that says two steps and delivers four burns exactly the trust you were trying to conserve.

Error handling is where forms most often turn hostile. The classic failure is the form that waits until submission to reveal everything wrong, discards the password field, and presents the visitor with their own answers marked in red like a graded exam. Validation should happen inline, when a field loses focus, in words a person would use. “Please enter a valid value” is a shrug. “That email is missing an @ sign” is help. And the difference between the two is the difference between a visitor fixing the field and a visitor closing the tab, because remember, the tab next door has a competitor in it whose form might not scold them.

There’s a category of field I’d single out for special scrutiny: the ones that exist to protect you from the visitor. The confirm-your-email field. The confirm-your-password field. CAPTCHAs on a form that has never been attacked. Each of these takes effort from every legitimate visitor to guard against a hypothetical minority, and each has better modern answers: a show-password toggle instead of a confirmation field, sending a verification email instead of asking someone to type their address twice, invisible bot detection instead of making humans identify traffic lights. When you make everyone pay to keep a few people out, you should at least check what the toll is collecting.

When GazeSite audits a page, forms are one of the places where the desktop and mobile screenshots diverge most. A form that’s tolerable with a keyboard becomes a gauntlet on a phone: tiny tap targets, the wrong keyboard for the field, a layout where the submit button hides below an ad. Since the majority of first visits now happen on phones, the mobile rendering of your form isn’t the edge case. It’s the main event, and it deserves to be tested the way visitors actually experience it, thumb and all.

The principle underneath all of this is that a form is the moment your relationship with a visitor becomes reciprocal. Everything before it, you were giving. Now you’re asking. People are surprisingly generous at that moment if the asking is graceful, and surprisingly unforgiving if it isn’t. So design the form the way you’d ask a favor from someone you’d like to know for a long time: ask for little, make it easy, be forgiving of mistakes, and save the personal questions for after you’ve done something to deserve them.