There is one common and fundamental key to good user experience, the user should never have to guess. This becomes even more important when you are asking the user to divulge personal information by creating a user account. A few months ago, I wrote an article on the importance of branding and design for registration forms. For an industry growing around web applications, user interaction has taken on a new role. Those points of interaction within a website, the programming and scientific elements have also taken a new role. In essence, this challenges the user. As a user interface designer, I want to reduce that challenge and make the experience as seamless and direct as possible.
Creating Web Application Forms
About a month after I wrote this article, Ryan Singer from 37 Signals gave a compelling presentation at the The Future of Web Design London, on Web Application Form Design. Ryan classified the information requested in form, into two distinct categories:
- Wrote Information
- Made Up Information
Wrote information is easy, as Ryan points out: Name, Birthday, Email Address. He recommends starting with these kinds of questions and work your way up to the “thinking questions”, like Username and password. In many cases, this approach can be very effective. However, there are also a considerable number cases where this approach would not create an inviting doorway for new users. Case in point: any new start up that needs to earn the trust of its’ users.
The problem I see with most “wrote” information requested in forms, is that it tends to also be personal information. Yes, they are easy to answer, but they fail to give anything in return. I keep referring to PB Wiki as an example. In my opinion, they all but have a perfect sign up form. The steps are incredibly minimal and the user is told up front what will be required of them.
They start with a question that falls under the “made up” category, but gives enormous payoff to the user, “Choose a Site Name“. The user already feels accomplished.
Next, they ask for “wrote” information, ” Your Email Address“.
And finally, they ask for a little information about what you are doing here, in this case, with your wiki. This kind of falls between the two categories defined by Ryan. It requires a little thinking, but it has been simplified by limiting the possible responses with a selection menu. Again, leaving the user at the end of the process with a sense that this is going to be easy.
Granted, not all applications can offer something as simple as PB Wiki, but the model they represent in their sign up form can translate to any web application environment. This model works following 3 basic principles.
- Let users know what is required, before they start.
- Give something, when you ask for something.
- Never let them guess.
Let users know what is required, before they start
When it comes to web forms, the number one thing you can do to encourage a visitor to become a user, is to let them know what is involved in the sign up process, before they start. Common thinking back in the day, was that you could avoid scaring off visitors by hiding the depth of commitment needed to get through the sign up process, by burying it in a multi-step procedure. This led to the dreaded multiple-screen registration forms. Suddenly, these were everywhere. They were deep, convoluted and seemingly endless mazes. User bail out on these forms was high.
That said, sometimes it’s just unavoidable. So letting the user know what is ahead of them and rewarding them along the way, can make the process much friendlier.
Giving something, when asking for something
The question of single screen sign up form versus multi-screen, was one that I came upon when designing the user interface for SparkSprite. Originally, we had gone with a single screen form, that was visually divided into 3 steps. We kept the process simple and limited the fields to only those that were essential to getting the account started.
This worked well, for all practical purposes. The form was clean and simple and inviting. However, after putting it into a testing environment, we quickly realized that some of the user interface objectives we set out to accomplish, were being sacrificed for the desired user experience. We went back to the drawing board.
User interface and user experience are very similar things, but not to be confused. The first is directly tied to product efficiency, while the latter to expectation. If you meet the users’ expectations, the experience is a good one. If this is at the sacrifice of accomplishing any of your interface objectives, that is quite bad. Our initial process was less demanding on the user to get signed up, but for most users, would require additional steps, once they had their account.
There were both pros and cons to this approach, but when the nuts met the bolts, we wanted nothing less than a completely intuitive experience for the user. We were falling short. To streamline our process, we decided a multi-screen approach would work much better for our needs. SparkSprite, unlike other web applications, presented some unique challenges. In the first place, we needed to collect a lot of sensitive information from the user, the names and addresses of children they want to send mail to. And in the second place, while most of this information was wrote, it required that the user plan in advance and have everything prepared beforehand.
To accommodate for these requirements, we used two tactics. One, provide a progress table so users would know how many steps there would be and what each would entail. And two, start with the user information first, since that is readily available to the user and a tad bit friendlier than asking for a credit card right off the bat.
Since we had to jump right into asking for personal information from the user, we made sure that we closed the first step of our sign up process by asking for something specific to the account they were setting up. In this case, the type of mail plan they wanted to sign up for. The reason for this was to provide the user with a sense of accomplishment.
It may sound like a really minor thing, but aside from that one question, there was nothing else we were asking for in the first step that distinguished our form from any other. We had asked for something from the user and now we were giving something. Now they have an account type.
Never let them guess
The key to good user interface design, in general, is to never let the user feel like they have to guess about something. I can’t tell you how many sites I’ve been on, where I felt at some point, how should I know that? When it comes to forms, this is especially important. Remember, any time you ask for something from the user, like fill out this form, you are asking more than you really have a right to. Why should they? What are they going to get out of it? And how long will it take and what will be required?.
These are the questions you need to answer beforehand. If you compare the web application environment to that of walking into a convenience store, you start get a clear sense of the size of the barrier this extra step of registration creates. If you were asked to fill out a quick form before entering the grocery store, you’d probably go across the street and shop.
Fortunately, most web applications have this sign up process to contend with, so users don’t necessarily have that option to “shop across the street.” This is why it is so important that your users don’t need to do any guess work when they come to your site.
This was, perhaps, the most important factor when designing SparkSprite. When it came to the sign up form, this idea is most critical. If a user has questions during the sign up process, you have a good chance of losing them as a client. To help avoid this, we applied a simple strategy when building our forms:
If there is an action being requested of the user, give them only one choice. Simple. Fill in your name. Fill in your email address. Continue. This model is ideal, as a starting point. Needless to say, or maybe I should say needful to say, this isn’t always possible. People make mistakes. That once choice, could have been made wrong. Then they have to go back and fix it.
Our focus, then, was to limit choices. If one choice would do, that’s all we offered. If two, then. If three, then three. This approach helped us keep our process direct, while at the same time keeping it from being too restrictive.
The important thing to remember, in all user interface design, is that no matter how clear you are, and how much you think you covered all your bases, someone is not going to get it. That was the person we didn’t want to lose. Striking a clean balance with a web application form, that will satisfy both user interface and user experience goals, really comes down to lots and lots of user testing. But having a solid strategy and clear set of objectives when you start, can greatly improve the tiime it takes to reach those goals.
[...] User Experience and the Registration Form Pt. 2 [...]