There is no single best way to have users sign up for an account online, because there are too many variables to be considered for this aspect of the user experience. Varying factors can include security, purpose of the account, understanding of the user at the time of signup, what information they must have ready and what they will have to do next, among other things. So to point to a cool new site – even a competitor’s – and say “I want a one-field signup process like that!” does not necessarily serve your needs or your user’s. In fact, there is an awesome site I recommend to people that suffers greatly from a confusing signup process because they tried to simplify it too much.
I have been thinking about this a lot, because we’re examining the
VisualCV signup process (I do consulting for them) plus I needed to develop a process for a product my partner and I are about to release called Twitterface.
Twitterface is an alternate
Twitter interface that is browser-based. It offers distinctions like multiple accounts, and a modified brand experience, and so the potential for pain is moderate, but not too severe for Twitter users. Since the software can’t be used without a Twitter account, the vast majority of our audience should find our settings and design options familiar, and will likely want to move quickly into the site so they can see if this is a product they want to add to their Twitter toolkit or not. Here are step-by-step prototypes of the signup process for Twitterface:
Step 1: Signup from the Home Page
One of the first problems I ran into is that users will need a Twitterface account, which is separate from their Twitter account (although they could use the same name/password if they choose.) This is because we will have settings we keep track of for people so their account is easy & pleasant to use. I am hoping this signup form makes that clear by specifying the words “Twitterface URL” but user testing will have to be conducted to make sure.
Step 2: Add Primary Twitter Account
Now the user needs to add a Twitter account that will be considered (by us) their primary account, for the purpose of setting up a personal account on their Twitterface page & responding to search tweets. Users will be able to add multiple accounts here before moving on, or they can start with one.
Step 3: Select Twitterface Options
The user is asked to select the number of accounts to show on one web page, and their level of security for logging in and out.
Step 4: Choose the Page Design
A default Twitterface theme is selected, but the user can either change it or design their own interface, including background, logo, colors and icons. Because that sounds like a lot to do in the signup process, I made it easy by telling users they can come back and do this later.
Signup Done! User Sees New Twitterface Page
A four-step process may seem like a lot to do before arriving at the point of the product, but I feel it is the smoothest way to enter the user into our system. An alternative would be to let them signup and dump them straight into their Twitterface page, where they would need to figure out how to go down to the settings and make all the changes we just had them set up in a few steps. That idea didn’t feel very pleasant to me, despite the appeal of getting a user in front of the product immediately.
After we have a working prototype of the product online, I will do user testing and ensure this is as smooth as I want it to be, and the design may be adjusted. It is an art to guide users through complex or unfamiliar steps while employing the restraint to have them do enough to get started and begin learning the software, but not too much. I hope I struck the right balance with this design.
If you’re an application designer, think about your user’s first few minutes. Could you take them through a guided flow so that they ultimately arrive at the product with some understanding of the different components? If not, what would it take to provide this kind of path? If you look at the prototype screens carefully, you’ll see a lot of guided text on the sides of the page, and buttons that indicate next behavior (they don’t just say “next” or exist on the page if they aren’t needed yet. I also included “hints” about how to swiftly complete the step and keep moving in some cases (see the light blue “psst…” text.) This extra programming effort usually results in a significantly more simple experience for users in the interface. It’s well worth it!
Getting people to signup is a marketing and conversion issue not covered in this article, but the signup experience itself is your user’s first impression of using the product for their own benefit. I’d love to hear your thoughts about this design and see other great examples of signup processes. Link me up! 🙂
Great post! I’d suggest to additional ways to assist a user sign up. Roadmaps and sandbox accounts.
I think roadmaps (of a visual sort) are a good idea – something to give users an overview of what’s expected of them before they start signing up. Perhaps a dedicated page which gives them an option of either signing up immediately or looking at what they would need to do to sign up.
On my own site I have “play calculators” people don’t need to use to sign up.
Great post.
One of the things that I have discovered is that the ease of use and intuitiveness of the signup page is critical, so getting it right is important. This is a great starting place and I would encourage any designer to think about all of the painful signup pages they’ve been through. Signing up for a new application should not feel like filling out insurance papers at the hospital. It’s just a bad feeling. Offering the level of progress (step 2 of 4) the user has made and even encouragement (screenshots of great gestures found inside) throughout the signup page is a good idea too.
When it comes to privacy it is important to make sure that the information you collect captures necessary information, not ALL information. Be as transparent as possible with users, and let them know what you intend to do with information that is not necessarily required for the application to work. That’s just my two cents.
Sidebar: I like your choice of topics and writing style. Keep up the good work. I’ll be back.
-Justin
Great points guys!!
Jay, I LOVE the idea of a trial-without-signup where people can play. I have products I have user-tested where the user really can’t become as excited about the product until they play with it themselves, because they have not yet *related* it to their specific needs. Playing with a product is a great way to whet the appetite and get users to make that final decision to sign up for the account.
Justin, the point you make about transparency is so valid. People have gotten better about giving information out and doing business online, but we shouldn’t take their comfort level for granted. I also am firmly against gathering more information than is truly necessary without making it optional. If you want and need demographics, put them in a section below and explain why you want the info and what it will be used for. And if you don’t need it, don’t waste the user’s time and limit your success by making the signup form too overbearing. (Obvious to user experience designers, sometimes not so obvious to managers/marketing.)
Thanks for your comments!
Kristi
I would use Twitter username instead of Twitter URL when signing up. My URL is http://twitter.com/miketempleton, but my Twitter username is miketempleton.
Outside of that, I think you have a great process outlined. I can’t wait to get my first look at Twitterface!
Mike, the URL/Username are one in the same, as you describe. I was trying to make it MORE clear by adjusting the wording, but I think maybe made it confusing. Good feedback & I’ll tweak it to make it clearer. Thanks!
This looks very cool – could it be adapted to do my Twitter Bot ideas? http://chrissaad.wordpress.com/2008/11/30/internet-wish-twitter-bot/
this is very exciting. i like the concept, approach, and based on what i’ve seen… the execution. can’t wait to learn more!
I guess I’m going to be the counter view here. I look at this from the user’s point of view. I can’t stand sites that make me jump thru six flaming hoops to get an account. I’m hoping that eventually web sites learn about sign-up what merchants have learned about MasterCard and Visa. It’s all about getting them in the door, not satisfying your desire for advertising information.
Think about it this way: Would you patronize a restaurant that made you give your name and address, telephone number, age, income, before seating you? I wouldn’t. They don’t need that information to provide the service. And most web sites don’t either. They make you provide it usually because it serves their advertising strategy or because the investors think there’s some value in collecting demographic information on subscribers. But in reality, most sites can function perfectly well without anything but a unique ID. Which brings me to OpenID.
When it comes to signup processes, I won’t be satisfied until I don’t have to put in *anything*. 🙂 That is, the web equivalent of a cash transaction. One step away from this is to accept OpenID for the registration. These are globally unique and much easier for the user since they don’t have to remember yet another name and password. In addition, your site can get some demographics that the user wants to reveal from the OpenID site, saving the user the trouble of having to type them in yet again. To extend the credit card analogy, accepting any OpenID is like accepting MasterCard or Visa. It makes it easier for the customer to buy your wares and visit your site.
I hope this didn’t come across as too much of a rant, but I find that designs for sites are too often oriented toward what the site wants, not what the user wants. Thanks for listening.
Joe, I can appreciate your perspective on this, which is why my first paragraph addresses many of the things you talk about here. I believe I have looked at this from the user’s point of view, and spent a lot of time planning this, so that it goes pretty quickly, but gives a user some orientation rather than just dump them inside the product and let them figure out the settings on their own (after they find them, that is.) When the product is in beta, however, I will validate that this is the correct approach.
Regarding using Open ID – I have not considered that for this product, but once we get the product launched will investigate this more and consider it. It’s a fair comment – to be honest I didn’t want to add the complexity in coding… my developer is my business partner, and he has a day job, and I have other work so this product unfortunately does not have our full-time focus. Believe me, if it did there are any number of things I would love to do to make it better, and this might be one! I will add it to the list of future requirements to consider and give it my attention later. Thanks for voicing your concerns!
Thanks Kristie, just added all this and your writing is very nice. I’m Twittering all the time but am not too clued up on what it’s all about. But what I do know is Twittering seems pretty cool thing to do, right. Have a happy 2009. Yours faithfully, Robert.
You were done in step 2, if your goal is registration. You can set interface & design later on.
I’ve seen your tweets re: Twitterface and after taking a look, I think it’s brilliant. Anything that makes Twitter easier to use and saves time is a great idea. I’ve only been on for about a week and a half, but great posts and information from folks like you are helping me catch up to the curve quickly. Thanks!