Forms are a Conversation
The users of your software always visit with a goal in mind. Often in web applications, a form stands between them and that goal. Whether the user wants to join a community like Facebook to connect with their friends or use a project management tool to organize their business, forms are there to hurdle.
These forms aren’t necessarily bad, we just need to remember that they are a step in the process—a step that must be completed before the user can reach their goal. So we want to make that step as painless as possible.
Try thinking about the form as a conversation: “I’m going to ask you a few questions so that you can complete your task.” But like any conversation, context and order are really important. Let’s say you and I have just met and after a quick introduction I ask, “What’s your address?” Your likely response would be shock: “Why should I tell you?” After all, we’ve only just met, you don’t know anything about me, and I am asking for personal information. I haven’t given you any reason why I need it.
Online forms are the same. If you ask for too much information too early, your users will pull out. “Why does this shopping website need my address? I haven’t even decided if I am going to purchase from them yet?”
Let’s try another example. You and I meet, but this time we talk for a while, find a mutual interest, and I offer to give you a copy of my favorite book on the subject. Now if I ask for your address to send you the book, your reaction will probably be completely different.
So before asking for personal information in a web application you need two things: trust and a reason.
The best way to build trust is to share information about your software: what it does, who created it, and especially how it will help the potential user. After all, at this point they are just reading about it, and not yet using it. The more you share about how it will help them, the more they will want to trust your software. Then when it comes time to ask for information about them, such as their name and email address to create an account, there will already be some trust built up.
Having a Reason
Let’s say that to browse an exclusive e-commerce website you need to create an account (a silly requirement, but this is just an example). If the create-account form asked for your physical address you may feel your privacy violated, because they haven’t given you a reason yet. Sure, if you buy something your address is needed to ship it to you, but you haven’t made that purchase yet. If the website instead waits to ask for your address until you’ve decided to make a purchase, then there is a reason for asking. You will be much more likely to give it to them.
So, just like in a conversation, when and how a question is asked has a huge impact on whether or not it will be answered.
A Conversation not an Interrogation
If I ask you a few sensible questions, then we are having a conversation. If instead I bombard you with questions, our friendly conversation starts to feel more like an interrogation. So limiting the number of questions asked will go a long way toward maintaining a friendly relationship with your user.
In real life you may feel like you have a social obligation to stay active in the conversation, rather than flipping me off and walking away. But that social obligation is not there at all on the web. With a single click of the back button users can exit a conversation they don’t like and never come back.
Look carefully at every question you are asking. It’s likely that about half of them can be removed. If later on you need more information, you can always ask the question when you have a reason for asking.
If you approach the questions in your form like you would a conversation with a stranger, then your users will be more likely to answer them.
Portions of this article are excerpts from Nathan Barrys’s book, Designing Web Applications, an everyman's guide to building apps with solid usability that launches today.
Image of chatty tea party courtesy Shutterstock.
ABOUT THE AUTHOR(S)
Nathan Barry is an interface designer and app developer who is passionate about designing software that is a joy to use. After leading the software design team at a startup in Boise, Idaho, where he lives, Nathan began working independently, designing and developing his own apps. He is the author of Designing Web Applications and he loves to travel. Follow him @nathanbarry on Twitter.