Boost your form completion rates with this microcopy checklist

Just before you release a new form out into the world, or if you already have a form that too many users abandon without completing or call support to deal with, go through this checklist and make sure you have everything covered.

And yes, the checklist is just as good for websites and apps as well as for complex systems.

Before you dive in

1. Do the users have enough good reasons to fill the form?

Do users understand — as soon as they start filling the form, and even when they first lay eyes on it — why they need to fill it, and what’s in it for them? This understanding is crucial for users to complete the form, especially long or complicated one.

So add — on the top of the form or on the page leading to it — a call to action that guaranties true value.

In complex systems, the CTA can be replaced by a one-line explanation on why we need the form, and what will happen after it’s sent.

2. Is there to much microcopy in the form?

Does it look overcrowded and requires a lot of reading comprehension?

It could happen if:

• You over-explained, even the parts that need no explanation.
• You’ve explained just what’s needed, but used too many words. The microcopy can be more concise (search for repeating words and for unnecessary instructions like type, select and enter).
• The UI/UX is not intuitive enough and needs the help of text instructions. Go back to the UX designers and reopen the issue.

3. Is there not enough microcopy in the form?

Did you skip on giving important explanations or reassuring words, in order not to overburden the users?

Are critical instructions hiding in tooltips because the designers are White Space fans?

If so, see this fascinating lecture by Sara Walsh and find out how her form’s completion rate leaped from 26% to 92%.

In this post I wrote about how to introduce instructions in a form, and when it’s too much or too little.

Clarity

4. Conversational writing

Make sure you:

• Address the users directly
• Use everyday common words
• Use active voice
• Ask questions to move the dialogue forward (only when called for, of course)
• Use short, straight forward language

5. Control labels

Labels are control titles that define what to type-in, choose or mark here.

Check each label individually and make sure they can be easily understood by all users.

Make sure they don’t include:

• Professional language that can be stated with simpler words (even experts prefer plain language, devoid of unnecessary jargon, according to this usability study by NNG).
• Terms you made up for internal use and were just left there.
• Abstract or vague terms that might be ambiguous.

If you find one of the above –
a. Substitute it with simpler, down to earth terms
or
b. Add an explanation

BTW, Control labels should always be visible to the users, and never disappear from the screen.

6. When users have several options to choose from

In drop-downs, radio-buttons or checkboxes — make sure all the options are:

• Easily and quickly understood.
• Their meaning and implication is evident from their name (if not, consider adding a tooltip beside the control label explaining the options).
• Distinguishable from one another (none can be confused with another).

Where multiple choices can be made — say it. The average user can’t tell the difference between radio-buttons and checkboxes, and when can they make multiple choices vs. just one.

7. Placeholders

• As they disappear quickly, they shouldn’t contain any information the user might need while typing.
• Make sure they add relevant information and don’t just repeat the label. If they do — they’re redundant, go ahead and delete them, the form will be airier, and according to eye tracking studies, the empty fields would be more noticeable.
• Placeholders should be in high contrast, to best serve accessibility guidelines (here are 7 guidelines for writing accessible microcopy).

8. Tooltips

• Make sure they don’t contain critical information better left always visible (benefiting users that don’t bother opening tooltips, you’ll be surprised how many there are). Write the critical information beside the control, where the user can’t miss it.
• If this is a one-time or seldom filled form, consider using tooltips that automatically appear when the field comes into focus.
• If the tooltip appears when you press an ‘i’ or ‘?’ icon, add an alt text that clearly explains what it contains, so the sight impaired also know about it.

Proceeding smoothly with no interruptions

9. Preventing banal, irritating error messages

Check with the product manager or developers about each and every field: What values and format the system accepts, and which values and formats will it reject with an error message?

For those that will return errors, give the users an advanced warning about them around the field.

For example:

• Are special symbols allowed?
• Is it OK to use a hyphen between the area code and phone number?
• How many characters should the password include?
• What are the max. and min. values allowed for this field?

10. Marking required/optional fields

Use the asterisk or write “Optional”. If they are all required — mention this loud and clear.

11. Open questions

• Did you provide users with a lead to start their answer? Something to help them focus and make your meaning clear? Maybe a good tip on how to effectively frame an answer?
• If there’s a limit to the number of characters in the answer — tell the users about it. Even add a counter.

12. Switches and checkboxes

Wherever there’s an option to turn something on or off (enable/disable)— using a switch or a checkbox — make sure the users have all the necessary information to decide if to switch on or off, including the implications of each choice.

13. Attaching files to the form

If there are any restrictions on file type or size — make it clearly known, to avoid getting an error message.

14. Error messages

• Have you received all the potential error scenarios in this form from the development team?
• Have you written good microcopy for them, reassuring the users with efficient writing, following the best practices for writing error messages? (See the chapter “Error messages” in Microcopy: The Complete Guide)

Address questions and concerns

15. Asking for personal information (email address, social security number, phone number, date of birth, etc.)

• If you absolutely need a piece of personal information — explain why this is so. For example, to contact the user about a shipment, or because you are required to by law.
• If the piece of personal information is optional — tell the users how will it serve their needs. For instance, so we can send them a gift on their birthday.

One way or the other, promise not to share the information, or use it for anything other than what you said you would.

16. Asking for complex information

Do users know where to get this information from? If they don’t — explain where it can be found.

17. Security

• With online payment — clearly indicate it’s secured, preferably in more than one location, preferably by the credit card fields.
• If your business requires a higher level of discretion (financial, dating, health) — clearly note, both at the beginning of the form and at its end, that the information given will be secured and kept confidential.

18. Making changes later

• If users can change later whatever they input into the form — tell them that, it will be easier for them to go ahead and fill it with no worries.
• If they cannot change it later — give them a heads up to avoid disappointment later.

It doesn’t end when clicking Send

19. Waiting time

If there’s a loading and processing time between clicking the Send button and the success message — prepare a nice message suitable to the experience, and show your users you gave some thought even to this small detail.

20. Success message

What do users see as soon as they complete the task and submit the form?
Is the success message pleasantly rewarding and completes the experience you wish to create?

After you go through this checklist and change things, let me know how it went and what difference did it make :)