Form design best practices: order and labels

Many forms show a field's name only inside the box, in gray, until the visitor clicks in. Once they type, the name goes, and a visitor who paused to think cannot tell which box wants a phone number and which wants a budget. On a phone the problem is worse, because the top of the form scrolls out of view while the keyboard covers the bottom. The owner never sees it, since the owner already knows that the second box is the company name. A visitor who is not sure what to type stops typing, and then leaves.

• Every field keeps a visible label above it when the field has text in it.
• Fields that answer one question sit together, in the order the visitor thinks of them.
• The form shows how many steps remain when it runs longer than one screen.
• The button names the result, such as Send my request, not only Submit.
• Optional fields are marked optional, so the visitor does not stop to decide about them.

The wrong version is a gray hint inside the box that is the only thing naming the field. The visitor clicks in, the hint vanishes, and a field with a typed value has no name on it at all. The right version is a visible label above the box that stays while the visitor types. A hint can still help inside the box, but as an example of the answer, such as a sample name or a date format, not as the only label. Check it on a phone with the keyboard open, because a label near the top of the screen is the first to scroll out of view.

A contact form built from a customer table asks for a first name, a last name, a company, a title, a phone and an email, in that order. A visitor asks something else first: who am I talking to, how do I hear back, and what do you need from me. The wrong version puts the record's order on screen, so the message box comes after eight fields. The right version asks for a name and a way to reply first, then the message, then the details that help you answer, such as the size of the job. Two short fields on one line read as one question, so give a separate answer its own line.

A button that says Submit tells a visitor nothing about what the press starts. Send my request says a request is made, and Book a free call says what the visitor gets next. On a form that runs over more than one screen, put Step 2 of 3 above the fields, so the visitor can see the end before deciding to go on. Without it, a visitor on the second screen cannot tell how much is left, and quits there even if the first screen went well. A simulated visitor that stops on a screen shows you which one, with the field and the screenshot.

A team adds a company size field for sales, or a consent box for a new mailing list, and the halfway drop returns. Send simulated visitors through the form after every change, and compare the step where each one stopped with the last run. Test the phone version every time, with the keyboard open, since a small edit changes it most.