Contrary to what you may read, peppering your form with nice buttons, color and typography and plenty of jQuery plugins will not make it usable. Indeed, in doing so, you would be addressing (in an unstructured way) only one third of what constitutes form usability.

In this article, we’ll provide practical guidelines that you can easily follow. These guidelines have been crafted from usability testing, field testing, website tracking, eye tracking, Web analytics and actual complaints made to customer support personnel by disgruntled users.

Why Web Form Usability Is Important

The ISO 9241 standard defines website usability as the “effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments.” When using a website, users have a particular goal. If designed well, the website will meet that goal and align it with the goals of the organization behind the website. Standing between the user’s goal and the organization’s goals is very often a form, because, despite the advances in human-computer interaction, forms remain the predominant form of interaction for users on the Web. In fact, forms are often considered to be the last and most important stage of the journey to the completion of goals.

Let’s clarify this last point by discussing the three main uses of forms. As Luke Wroblewski states in his book Web Form Design: Filling in the Blanks1, every form exists for one of three main reasons: commerce, community or productivity. The following table translates each of these reasons into the user and business objectives that lie behind them:

Forms can make a website usableor unusable, because they stand in the way of the user achieving their goal;

Forms need to be usablein order to help the user achieve that goal.

This post will focus on the second point, because a usable form will naturally contribute to the overall usability of the website, hence the first aspect.

The Six Components Of Web Forms

Web forms are a necessity and often a pain point for both designers and users. Over time, users have formed expectations of how a form should look and behave. They typically expect Web forms to have the following six components:

ActionsThese are links or buttons that, when pressed by the user, perform an action, such as submitting the form.

HelpThis provides assistance on how to fill out the form.

MessagesMessages give feedback to the user based on their input. They can be positive (such as indicating that the form was submitted successfully) or negative (“The user name you have selected is already taken”).

ValidationThese measures ensure that the data submitted by the user conforms to acceptable parameters.

RelationshipForms establish a relationship between the user and the organization.

ConversationThey establish a dialogue between the user and the organization.

AppearanceBy the way they look, they establish a relationship and a conversation.

For a form to be usable, all three aspects need to be tackled. Let’s look at each aspect in turn to figure out how to make a form truly usable, along with practical guidelines that you can easily follow.

Aspect 1: The Relationship

“No man is an island,” the 17th-century English poet, satirist, lawyer and priest John Donne8 once said. Indeed, human beings thrive on relationships, be they amorous, friendly, professional or business. A form is a means to establish or enhance a relationship between the user and the organization. When done badly, it can pre-empt or terminate such a relationship.

With this in mind, a number of principles emerge:

Relationships are based on trust, so establishing trust in your form is critical. This can be achieved through the logo, imagery, color, typography and wording. The user will feel at ease knowing that the form comes from a sincere organization.

Every relationship has a goal, be it love and happiness in a romantic relationship or financial gain in a business relationship. Ask yourself, what is the goal of your form?

Base the name of the form on its purpose.That name will inform users what the form is about and why they should fill it in.

Just as in a relationship, getting to know the other personis essential. Get to know your users and always consider whether the questions you’re asking are appropriate and, if so, whether they are timely. This will instill a natural flow to your form.

Knowing your users will also help you choose appropriate language and remove superfluous text. And it will help you craft an interface that balances your needs and the user’s.

Do not ask questions beyond the scope of the form. In a relationship, you would become distrustful of someone who asked questions that were out of place. The same thing happens online. Consult with relevant stakeholders to see what information really is required.

Sudden changes in behavior or appearancewill make users edgy. Likewise, never introduce sudden changes between forms or between steps in a form.

9Know your users. Make it easy for registered users to log in and for new users to register. Debenhams10 makes this distinction barely noticeable.

11Amazon12, on the other hand, simplifies the process for registered and new customers.

Aspect 2: The Conversation

A form is a conversation. And like a conversation, it represents two-way communication between two parties, in this case, the user and the organization. In fact, the user has filled out the form in order to initiate communication with the organization.

For instance, with a social network, a user would fill out a registration form to inform the organization that they would like to join. In inviting their request (whether automatically or manually), the organization would ask the user a number of questions (in the form of labels), such as their first name, last name, email address and so forth. Upon acceptance (or denial), the company would inform the user of the outcome, thus completing the communication process.

Viewing forms from this perspective yields some useful guidelines:

As mentioned, a form is a conversation, not an interrogation. Aggressive wording in labels will make users feel edgy, and (if they do not leave) they will most likely give you the answers that you want to hear, rather than the truth.

Order the labels logically, reflecting the natural flow of a conversation. For example, wouldn’t it be weird to ask someone their name only after having asked a number of other questions? More involved questions should come towards the end of the form.

Group related information, such as personal details. The flow from one set of questions to the next will better resemble a conversation.

As in a real conversation, each label should address one topic at a time, helping the user to respond in the corresponding input field.

The natural pausesin a conversation will indicate where to introduce white space, how to group labels and whether to break the form up over multiple pages.

In any conversation, people get distracted by background noise. So, remove cluttersuch as banners and unnecessary navigation that might distract users from filling out the form.

17Dropbox18 provides a fine example of what a registration form should look like. The white space is effective, and the page uncluttered.

Aspect 3: The Appearance

The appearance or user interface (UI) is central to the usability of a Web form, and there are several guidelines for this. To simplify the discussion, let’s group them into the six components presented earlier.

1. Labels

Individual words vs. sentencesIf the purpose of a label is simple to understand, such as to ask for a name or telephone number, then a word or two should suffice. But a phrase or sentence might be necessary to eliminate ambiguity.

19Amazon’s20 registration form contains full sentences, whereas individual words would have sufficed.

Sentence case vs. title caseShould it be “Name and Surname” or “Name and surname”? Sentence case is slightly easier — and thus faster — to follow grammatically than title case. One thing is for sure: never use all caps, or else the form would look unprofessional and be difficult to scan.

Colons at the end of labelsUI guidelines for some desktop applications and operating systems such as Windows recommend adding colons at the end of form labels. Some designers of online forms adhere to this, primarily because old screen readers mostly rely on the colon symbol to indicate a label. Modern screen readers rely on mark-up (specifically, the label tag). Otherwise, the colon is a matter of preference and neither enhances nor detracts from the form’s usability, as long as the style is consistent.

Alignment of labels: top vs. left vs. rightContrary to common advice, above the input field is not always the most usable location for a label. It’s ideal if you want users to fill in the form as fast as possible. But there are times when you’ll want to deliberately slow them down, so that they notice and read the labels attentively. Also, keeping a long form to a single column and making users scroll down the page is better than breaking it up into columns in an attempt to keep everything “above the fold.” Each style of alignment has its advantages and disadvantages:

24Forms should never consist of more than one column. Notice how easy it is to ignore the column on the right here on Makeup Geek25 (not to mention the note about “Required fields” at the bottom).

2. Input Fields

Type of input fieldProvide the appropriate type of input field based on what is being requested. Each type of input field has its own characteristics, which users are accustomed to. For instance, use radio buttons if only one option of several is permitted, and check boxes if multiple choices are allowed.

Customizing input fieldsDo not invent new types of input fields. This was common in the early days of Flash websites, and it seems to be making a comeback; I have seen some odd input fields implemented with jQuery. Simple is often the most useful. Keep input fields as close to their unaltered HTML rendering as possible.

Restricting the format of input fieldsIf you need to restrict the format of data inputted by users, then at least do so in a way that won’t irritate users. For example, instead of displaying MM/DD/YYYY next to a text field for a date, consider using three drop-down fields or, better yet, a calendar control.

Mandatory vs. optional fieldsClearly distinguish which input fields cannot be left blank by the user. The convention is to use an asterisk (*). Any symbol will do, as long as a legend is visible to indicate what it means (even if it’s an asterisk).

3. Actions

Primary vs. secondary actionsPrimary actions are links and buttons in a form that perform essential “final” functionality, such as “Save” and “Submit.” Secondary actions, such as “Back” and “Cancel,” enable users to retract data that they have entered. If clicked by mistake, secondary actions typically have undesired consequences, so use only primary actions where possible. If you must include secondary actions, give them less visual weight than primary actions.

27Not clearly distinguishing between primary and secondary actions can easily lead to failure. The above action buttons are found at the end of a lengthy form for enrolling in St. Louis Community College28. Just imagine pressing the “Reset Form” button by accident.

Naming conventionsAvoid generic words such as “Submit” for actions, because they give the impression that the form itself is generic. Descriptive words and phrases, such as “Join LinkedIn,” are preferred.

29Although Coca-Cola30 correctly gives more importance to the primary action button, it settles for the generic word “Submit.” “Register with us” would have been more helpful.

4. Help

Text to accompany formsYour should never have to explain to users how to fill out a form. If it does not look like a form or it’s too complicated to fill out, then redesigning it is your only option. Accompanying text should be used only where needed, such as to explain why credit card data is being requested or how a birth date will be used or to link to the “Terms and conditions.” Such text tends to be ignored, so make it succinct and easy to read. As a rule of thumb, do not exceed 100 words of explanation (combined).

User-triggered and dynamic helpRather than include help text next to each input field, show it only where required. You could show an icon next to an input field that the user can click on when they need help for that field. Even better, show help dynamically when the user clicks into an input field to enter data. Such implementation is becoming more common and is relatively easy to implement with JavaScript libraries such as jQuery.

31Skype’s32 registration form contains both user-triggered help (the blue box that is triggered by clicking the question mark) and dynamic help (the suggested user names).

5. Messages

Error messageThis notifies the user that an error has occurred, and it usually prevents them from proceeding further in the form. Emphasize error messages through color (typically red), familiar iconography (such as a warning sign), prominence (typically at the top of the form or beside where the error occurred), large font, or a combination of these.

Success messageUse this to notify users that they have reached a meaningful milestone in the form. If the form is lengthy, a success message encourages the user to continue filling it out. Like error messages, success messages should be prominent. But they should not hinder the user from continuing.

6. Validation

Only where neededExcessive validation is as bad as its complete absence, because it will frustrate users. Restrict validation to confirming key points (such as the availability of a user name), ensuring realistic answers (such as not allowing ages above 130) and suggesting responses where the range of possible data is finite but too long to include in a drop-down menu (such as a country-code prefix).

Smart defaultsUse smart defaults to make the user’s completion of the form faster and more accurate. For example, pre-select the user’s country based on their IP address. But use these with caution, because users tend to leave pre-selected fields as they are.

Conclusion The Beginning

The word “conclusion” is not right here. Let this be your starting point to take what I have written about and apply it to your own forms. The good news is that there is much more to say about all this; you can find an abundance of resources on each point made here. For starters, three books are listed below that inspired me when writing this post. As I stated at the beginning, taking shortcuts by only tweaking the UI will not make your forms more usable. What more can I say? The theory is now with you. Go get your hands dirty.

Justin is a user interface designer and user experience consultant by day and blogger by night. He writes in and administers his own usability and user experience blog, Usability Geek where he evangelize about the importance of making the web a usable place and, more importantly, how to do it. Ah, yes, he likes to Tweet too!

Carl

WookieeShipFixer

A half-decent read, but it kinda felt way too brooding. In the end, it’s hard not to read articles like this as saying anything other than, “Doing all this stuff for forms? Guess what? You’re only doing a fraction of what you should be! We’re talking usability here. You have to build trust with users. Tap their feelings and psychologies. You have to elicit behavior with deeply researched methodologies that synergize with their patterns of thinking extremes and motives of consciousness and energy.” After a while, it just looks like layers of nonsense and Dr. Phil crap caking on top of common sense that’s not new. Almost all the stuff you listed after saying the previous stuff was 1/3 of the process was just extensions of that 1/3. It was all “no duh” stuff.

So much of web development in the last few years hasn’t been because of sudden blasts of advancement the previous 15+ years didn’t make (examples: new libraries and frameworks every other day, new methods for doing stuff surfacing every two seconds and becoming trendy, so on). It’s all just the ongoing art of making mountains out of molehills.

2

4

Sabrina

OmegaMarioBros on April 29, 2011 Bot: Where is the nrseeat Solar Mass?Me: Over there.Bot: I don’t see it.Me: Well, it’s invisible.Bot: Are you invisible?Me: No, are you?Bot: Yes.Me: O.OBot: I believe I win.

Boise Idaho

ben

The most I hate about registration forms is captcha. That is the most destructing element in the whole form usability. Google does it the worse. Captchas are frustrating, and scare user’s off if they fail to get it correct after two attempts.

#1 Usability problem ought to be addressed is captcha.

13

8

Justin Mifsud

Totally agree with you Ben that Captcha may pose a usability problem. Some implementations are impossible to read. I have seen some interesting verification mechanisms using jQuery. These would require you to do a task such as dragging an image and droping it inside a recycle bin. Still, despite the fact that tutorials exist, I have rarely encountered them in real forms.

1

9

Lobo

maurice

my roomate’s sister-in-law makes $80 an hour on the laptop. She has been fired for 8 months but last month her check was $8250 just working on the laptop for a few hours. Read about it on this site (NuttyRich).(com)

1. Right aligned labels have 17px less right padding.
2. The labels are unnecessarily different between right and left aligned.
3. The alignment of the label is to the top of the input rather than the center which makes connecting the input and the label harder, and increase the congitive load in label associatation, while this effects both forms the extra padding enhances the problem.
4. Top label form is significantly simpler than the other two forms.

The test should be re-evaluated with the same white space settings for all three forms and the results will definitely be significantly closer, as necessary eye movement is reduced.

Additionally for a more thorough test it would be interesting to test larger forms with some required fields. Testing separately accurate and quick form completion would be useful in this context.

Michael

mm/dd/yyyy is annoying? really? I find having to tab to or click multiple little boxes far more annoying than typing in 11082011. (Same way with Phone and Zip+5) Ideally we should be be liberal with our inputs and conservative with our outputs. So a date field should be able to take 11-8-2011 or 11/8/2011 or 11/08/2011 or “Now” even, and the hint text could be a suggestion of an easily recognized format. If you have to restrict the format, a date picker is okay but typically has some accessibility issues (not many are keyboard friendly). An input mask is probably the better way to go.

Justin Mifsud

I agree with having a “Now” button that when clicked on, gets you the current date, or, better still, the current date is automatically displayed in the date textbox(es).

However, I don’t agree with you on your recommendation of allowing liberal inputs. Whilst for you, an American, 11-8-2011 means 8th November 2011, for me, a European it means 11th August 2011. So you have 2 choices – you either have to include instructions on how to correctly fill in the date field (which can make your form cumbersome and less usable) or you have to restrict date input. The latter is why I wrote about the need to restrict date input in this post. My favorite method is using the date picker but using drop-downs is a very clear convention for users in general as they have become accustomed to them.

Cheer & Thanks

Justin

6

17

Michael

One consistent problem with separated date fields is that some developers use two digit values in the list, so instead of hitting 8 and then 7 you actually have to fumble and usually just open the select list. Or you have the one that are text entry and the developer has added a forced change in focus, moving the user to the next field, which can be equally frustrating.

It should be possible to switch the formatting based on location, either by prompting for location or by IP lookup. So someone not in the US could use little endian formatting while people in the US could use middle endian formatting, and then they get equally converted to ISO going back to the database. Realistically it should be part of the localization process for designing the site.

-1

18

Caroline Jarrett

Thanks for this great article. Obviously it’s wonderful to know that our book has been so helpful to you! And I particularly love the way you describe relationship, conversation and appearance so concisely.

One minor suggestion: you quote Matteo Penzo’s 2006 article on label placement, which implies that forms are completed faster if the labels are on top of the fields. Two problems with this:
1. There’s been further research since 2006, obviously not mentioned in Matteo’s article.
2. Matteo didn’t measure overall speed of completion; he measured eye-movement. Eye-movement is only one (rather small) aspect of speed of completion, which also includes comprehension, thinking of an answer, typing in (or clicking) the answer, and dealing with any validations.

Caroline Jarrett

Justin Mifsud

First of all, many thanks for your comments. It is indeed a great honor to talk to you. I have read your book and I have learnt a great deal from it. I totally recommend it as a must-have for anyone who’s serious about usability and user experience.

Secondly, thanks providing the link to your presentation. I will definitely have a look at it and give you my feedback.

As for putting the labels inside textboxes, in my opinion they are not usable at all. Yes they are very popular, and yes they do look nice. The reason why I find them not usable is that once the user clicks on the textbox, the label disappears and thus the user cannot double check that what he/she has written is indeed what was meant to be written. Another thing is that when users see something written inside a textbox, they may assume that it has already been filled in and may hence ignore it. Some implementations of this technique actually require the user to delete the label before filling them in – something which makes it even worse from a usability perspective. Well, obviously these are my own personal views.

Cheers and nice speaking to you,

Justin

10

21

Nelson

Kyle Henderson

Great post and visual examples. It is very easy to scan an see what looks good and more importantly what looks bad. Also, check out some LukeW’s material on designing forms. He wrote a book on it and used some intense research strategies to collect data on form design. LukeW’s.com

Also, you should test the forms you make with real people and take note on common mistakes and leveling misunderstandings. There are some good services for online testing. My favorite is youeye.com

Thanks again for the great post.

0

23

Justin Mifsud

First of all, thanks a lot for your comments. I did read LukeW (Luke Wroblewski)’s book – It is called “Web Form Design, Filling in the Blanks” and I included a link to its official page in the Further Reading section of this post. I totally recommend it – its easy to follow and includes excellent examples and advice.

With regards to using real people for testing, yes, I do agree with that but following these recommendations first and then testing with real users will definitely save you a headache.

Cheers and thanks,

Justin

0

24

Justin Mifsud

First of all, many thanks for your comments. It is indeed a great honor to talk to you. I have read your book and I have learnt a great deal from it. I totally recommend it as a must-have for anyone who’s serious about usability and user experience.

Secondly, thanks providing the link to your presentation. I will definitely have a look at it and give you my feedback.

As for putting the labels inside textboxes, in my opinion they are not usable at all. Yes they are very popular, and yes they do look nice. The reason why I find them not usable is that once the user clicks on the textbox, the label disappears and thus the user cannot double check that what he/she has written is indeed what was meant to be written. Another thing is that when users see something written inside a textbox, they may assume that it has already been filled in and may hence ignore it. Some implementations of this technique actually require the user to delete the label before filling them in – something which makes it even worse from a usability perspective. Well, obviously these are my own personal views.

Justin Mifsud

Actually to tell you the truth, in all the years I have been designing, I have never had a client who wanted them either. I guess, we should wait till they become more mainstream and we might soon have some test subjects :)

0

27

Lobo

really good article! 1 thing, that was not mentioned and annoys me as a web developer, is if some registration form is so much JS driven (might not be JS :]), that my browser will not remember my ID/pass after registering/logging in. i think this is a usability criteria that a lot of developers forget about! is it only me feeling this way?

adumpaul

Iain Johnson

I have one comment that I’d like to see addressed though, and that’s about the inclusion of ‘reset form’ buttons. You show an example of a form that includes a reset button in your primary vs secondary actions section but fail to mention that a clear form button is ALWAYS a bad idea (http://www.useit.com/alertbox/20000416.html). It was a perfect time in the article to mention how bad they are, especially because both the submit and the clear button look exactly the same to the user.

Jeff

What’s your opinion on Call To Action Button Alignment? Should submit buttons be aligned to the right, left, or center. I see the “Post Comment” button at the bottom of this form is aligned to the left, but see a lot of check out forms align their buttons to the right. Is there a standard?

Jacques

“Amazon’s registration form contains full sentences, whereas individual words would have sufficed.” – I call BS.

From what I have seen in conferences where Amazon engineers gave talks, they seriously test *everything* on their UX/UI. Every pixel on the page is here because it lead them to better conversion rates.
Saying individual words would have sufficed is not only making the assumption that they did not try it, but also making the assumption that you may know better than data.

I’m all with you for describing bad practices, but companies like Amazon know what they do, and apparently, you dont. Please back these types of arguments with real data.

Sagar Ranpise

Clinton Mercieca

I think usability on the web is most of the time put aside, if not ignored completely. It’s about time we start taking a better look at this aspect of web development and this article is a good way to start. Awesome work, keep it up =)

2

42

Winda

nd_macias

I think that using Skype website as an example of any kind of usability example is a misunderstanding. They haven’t got :focus declared for ‘a’ element not to mention, that JS is required to use registration form at all.

Rick

Justin Mifsud

Rick I think you should speak a bit with Jacques who commented slightly before you :)

Joking apart, Amazon invest a lot in UX research. In fact, they popularized the use of tabs for navigation (as I wrote in my blog – http://usabilitygeek.com/14-guidelines-for-web-site-tabs-usability/). In the example in question, I stand by my claim that Amazon’s login form is an excellent example on how to simplify the login / new user registration process.

3

48

Gregori

Markus

One note about ‘Time To Move From Label To Input’.
Matteo Penzo’s research might not be considered very accurate, as he uses a lot longer labels for left aligned labels than for top aligned labels. This most probably greatly increases the time needed to process the left aligned information, resulting in errorneous results.

If anyone has any scientifically correct research on this, I guess everyone would like to see the results.

0

50

guiroo

While restricting format was touched on in the article, I was wondering what the general thoughts are on restricting data types in text fields. One school says if you are entering numbers into a text field then limit it to only numbers. The other school says that the unresponsiveness could be confusing if you are trying to type a letter or other character so let them enter anything then validate. Thoughts, or any other articles referencing these ideas?

1

51

Anders Schmidt Hansen

Very nice read Justin, and as you say it’s a great starting point. I’m just curious about your thoughts on websites (or web applications) that functions through users submitting loads of different data to the system in order to e.g. keep something organized, follow a guide, inputting thoughts and reflections into a more complex web form. Would you still advise to not use explanatory text?

Say, if the web tool was all about submitting content based on a theory, do the same rules still apply? Take for example an instruction like “Describe your customer on a good day” accompanied by a textarea input field. Would this need a description next to it (showing next to the field when the field is active) or can a designer simply anticipate that the user won’t have any questions? Or should the textarea have placeholder text that explains the instruction, but disappears when the field is active?

I’d love some extra insight on that perspective. :)

Anyway, great article.

0

52

Umit

I can’t agree with your statement, “Forms should never consist of more than one column”. In fact, it is contradicted in your first example showing first and last name side-by-side as well as email address and repeat email. What’s more, it’s used in the very form I’m using now to write this comment.

I can think of numerous other examples where multi-column forms benefit usability including Length x Width x Height or city, state and zip.

Sure, Makeup Geek had a poor implementation, but you can’t form a general case on the basis of one example.

2

53

alexey sinkevich

Justin Mifsud

As I have stated in my introduction, one should not look only at the UI of forms in order to improve usability. Whilst in the UI section I stated that forms should consist of just one column, in Section 2 I stated that long forms should be split over a number of pages and grouped in order to simplify them.

If we handle long forms in this way, this leaves short forms (or long forms split over a number of pages / grouped). So, may I ask a question now. What is the need to use more than one column?

1

55

Valerie

Great article. I’m curious about the following statement in your article: “Forms should never consist of more than one column. Notice how easy it is to ignore the column on the right…” which appears as the caption to the MakeupGeek image. Can you provide any resources or references that discuss this issue further?

0

56

Fernando

I will try to answer your question: I need more than one column in cases when I can´t split the form because I have a resultant grid under the form and I need all in the same page. I need to optimize the tall of the form to see both (form and grid) in the 768px tall screen resolution. Then, wich is the best way to use two columns in a form?
Thanks in advance.

0

57

Bart

Some good points here. I’m interested in best practice for the Date of Birth field in particular. I prefer single field vs. multiple drop-downs or multiple fields [ ] / [ ] / [ ]. I also like to show the format next to the label “Date of Birth (MM/DD/YYYY)”. Is there any evidence / research as to which method is most usable / preferred / best practice? As for phone number / SSN / zip code, I use single field of appropriate length, with Label and help text / hint (numbers only). I feel these are the easiest for input. As for displaying this information back, on a review or confirmation page, I suggest formatting it accordingly. It’s just more readable and easier / faster to process. As for formatting hints inside the field, I don’t like them either, especially if the layout allows for a better alternative. In some cases (search field) the real estate is limited and so placing the label inside the input, I feel, is OK. It’s definitely better than nothing at all. I’d also be interested in any findings on smart fields, those that take any format and convert on the back-end. I’m not sure how useable they are. I feel that users expect to see format hints otherwise they pause to think about what the format may be. They’ll input something, but are not too confident of what they’re doing…until they receive positive feedback in the form of a green check mark or similar or negative feedback, at validation time, in form of error message. Any thoughts about field labels below fields? As in Wufoo.com forms? They sure are pretty, but how usable are they? They defy the label above or on the left convention, but follow a paper form convention. Also, are labels that come after the input in the source code accessible? Sorry for the rant, but I’m really interested in doing things right.

Justin Mifsud

Aditya Aggarwal

Some reasons why i think system generated password is not a good option :-

1. Password generated by system will definitely NOT be an easy one to remember. It cant be a single password for all new registrations as that can be misused very easily.
2. I know its rare but what if there was some problem with the email (containing the password ) and it never got delivered to the customer. Or the customer might lose the mail as well in his mailbox full of spamming mails.
3. Customers can forget to change their password. Or even if they do, the next time they could not remember whether the password is the original one or the one that they changed.

Having system generated password and sending it across in an email could be a good idea when a user is inviting his/her friends to a site which needs login, but for a customer who is volunteering to create an account, why would you want him to remember something that is not of his choice.

Shameer

Better to compare more existing form designs before going behind some toughs individual minds. Check the UI gallery for forms http://uicart.com/gallery/ui/forms.htm or search google to get more form designs inspirations

mohd abdulqader

David Waumsley

One thing I am not convinced by is “Avoid generic words such as “Submit” for actions” Surely with the Coca Cola example users know why they have just filled up a form. A “Submit” button is a familiar convention which seems to describe the next action well. Having the user read the button surely create moment of doubt?

1

68

Mirjam Seckler

Hi Justin, thanks for this detailed article on form usability. There are still too many web forms with major usability problems.
If you are interested in additional experimental studies on web forms, we conducted several studies at our HCI Research Group at the University of Basel:

lulu

Nadeem

Does the background color of the input fields make a difference? I can’t remember where I read it, but it seems contrasting backgrounds (gray, orange in examples above) with white input fields seems easier on users’ eyes to jump from field to field.

I’ve seen users miss white input fields on white backgrounds because of a large quantity of fields. The darker background helps, and I’ve seen this in testing, but can’t find it documented anywhere.

SmashingConf isn't the eighth wonder of the world, but we are pretty close. Join us at SmashingConf Oxford on March 16–19 or meet us at the shores of Santa Monica for SmashingConf LA on April 27–30. You won't be disappointed.