To the front pageThe Interaction Designer's Coffee Break - Weekly postings and quarterly articles about interaction design  
  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI  




The usability of real-time feedback in forms

To better understand the usability of inline validation in forms - that is, forms that provide real-time feedback as people fill in answers - Luke Wroblewski set up a usability test comparing different types of form feedback.

Though the participants were confused when simple questions, such as a person's name, were marked "correct", he found that they were faster, more successful, less error-prone, and more satisfied when they used a form with inline validation.

Also, giving feedback after the particpants finished typing - rather than while they were typing - helped the participants complete the forms more quickly.


  • Inline Validation in Web Forms Open link in new window

Henrik Olsen - September 07, 2009

Permanent link Comments (0)

See also: Research (129) 



Tips on how to design forms

To find out how to design user-friendly forms, cxpartner have tested four registrations forms at Yahoo! Mail, Googlemail, Hotmail and eBay.

Here are their recommendations based on the study:
- Use a simple vertical layout and vertical aligned labels where possible
- If vertical aligned labels are not possible, use bold left-aligned labels
- When more than one field is placed on a line, ensure that they are designed to look like a single piece of information
- Emphasize the headers if you want users to read them
- If optional fields are needed, make them clear instead of using asterisks for mandatory fields
- Use single field for numbers or postcodes, allow input in various forms
- Let users focus on their task and avoid distractions
- Use real time feedback carefully
- If possible, place tips at the side of the relevant fields
- Provide users with a progress indicator showing them the steps involved to complete the form


  • Web form design guidelines: an eyetracking study Open link in new window

Henrik Olsen - June 02, 2009

Permanent link Comments (0)

See also: Research (129)  Tips and guidelines (95) 



How removing a button can make you $300,000,000 a year

In this article, Jared Spool tells a story of how his company helped an e-commerce site increase purchases by 45%.

The site lost lots of purchases because the required customer registration frustrated people. Usability tests showed that they resented having to register and repeat customers couldn't remember their account login.

The designers fixed the problem simply. They took away the Register button and made customer registration optional. With an increased sale of $300,000,000 the first year, the client was happy.


  • The $300 Million Button Open link in new window

Henrik Olsen - January 15, 2009

Permanent link Comments (0)

See also: Cases and Examples (28)  E-commerce (27)  Shopping Carts (9)  Cost-justification and ROI (27)  Usability testing (68) 



Spell out whether form fields are required or not

In a comparative test, Erin Walsh learned that spelling out that a form field is optional works significant better than indicating it with some visual means.


  • Erin Walsh's post on the IxDA discussion list Open link in new window

Henrik Olsen - September 06, 2008 - via Luke Wroblewski's Web Form Design blog

Permanent link Comments (0)

See also: Research (129)  Tips and guidelines (95) 



Study of login functions

In a study, UIE had the opportunity to learn how the login functions at different travel sites works.

They found that:

- There doesn't seem to be much consistency across travel site in how they locate their login and whether they use a login form or a login link

- When looking for the login, user seemed to first look for a pair of text fields. If they couldn't find it, they would start looking for a link.

- The location and type of login made no discernable difference.

- Users had trouble when the login feature wasn't visually distinct from the rest of the page

- If two text fields were located close to each other, some users would mistake them for the login form

- Once logged in, a pattern that worked well was to replace the login feature with the user's name and a logout link.

- Users had strong expectations about when the login features should appear. The most successful approach was to give users the option when it was beneficial to them.


  • The Wheres and Whens of Users' Expectations Open link in new window

Henrik Olsen - June 09, 2008

Permanent link Comments (1)

See also: Research (129)  Links (19) 



OK button first or Cancel first?

Should the OK button come before or after the Cancel button? According to Jakob Nielsen, this is one of the questions that people can argue about for hours but really doesn\'t matter much.

But if you really want an objective decision criterion, follow the platform conventions. If you users are primarily Windows users, put Cancel last. If your users are primarily Mac users, put Cancel first.

If Windows users equals Mac users, flip a coin.


  • OK–Cancel or Cancel–OK? Open link in new window

Henrik Olsen - June 01, 2008

Permanent link Comments (8)



And if you are using GNOME on Linux, Unix, or Solaris, you will put the action/OK button in the lower rightmost area of the dialog, and the cancel to the left of it. Although it's preferred to use a more descriptive verb than the word "OK" whenever possible:

KDE, of course, is the opposite of this and cancel always appears further to the right than the action button(s).

M - May 29, 2008

Permanent link Comments (0)



Book: Web Form Design

Luke Wroblewski's book about designing effective and engaging web forms is available for purchase. Luke has been writing a great deal about form design at his blog and I'm sure his book is worth a read.


  • The book Web Form Design Open link in new window
  • Luke's blog entries on form design Open link in new window

Henrik Olsen - May 05, 2008

Permanent link Comments (0)

See also: Books (47) 



Account sign-in - 8 more design mistakes to avoid

Jared Spool shares 8 more design mistakes with account sign-in:

9. Not telling users the requirements for username and password up front

10. Requiring stricter password requirements than the NSA

11. Using challenge questions people won't remember

12. Not returning users to their desired objective after they have signed in

13. Not explaining users it's the username or password they got wrong

14. Not putting a register link when the sign-in is an error

15. Not giving the user a non-email solution to recover their password

16. Requiring more than one element when recovering passwords


Henrik Olsen - January 16, 2008

Permanent link Comments (1)

See also: Tips and guidelines (95) 



Account sign-in - 8 design mistakes to avoid

Jared Spool has watched users struggle with online accounts and sign-in procedures. From his observations, he has compiled a list of 8 common design mistakes:

1. Requiring users to crate an account when it really isn't necessary (e.g. when buying a product or downloading a white paper)

2. Requiring users to sign in before they are ready to do so (e.g. before they can see the products they can buy)

3. Not stating the benefits to creating an account (such as the option to change flight reservations after they are made)

4. Hiding the sign-in button

5. Not making "Create New Account" or "Forgot Your Password" a button or link

6. Not providing sign-in opportunities when people need them (e.g. at the checkout where it can save people for re-entering their billing information)

7. Asking for too much information when registering

8. Not telling users how their information will be used (e.g. not giving a reason for asking people for their phone number)


  • Account Sign-in: 8 Design Mistakes to Avoid Open link in new window

Henrik Olsen - January 06, 2008

Permanent link Comments (1)

See also: Shopping Carts (9)  Tips and guidelines (95) 

<< Back | More posts >>

Browse GUUUI postings

Methods and the design process

Prototyping and wireframing (119)  Usability testing (68)  Cost-justification and ROI (27)  User research (23)  Personas (19)  The design process (24)  Eye-tracking (14)  Card sorting (13)  Web traffic analysis (12)  Expert reviews (11)  Implementing user-centred design (9)  Site and flow diagramming (6)  Envisionments (4)  Use Cases (3) 

Design elements

Navigation (63)  Web page design (40)  Search (27)  Text (24)  Forms (30)  Links (19)  Guidelines and Standards (15)  Site design (14)  Ads (9)  Design patterns (8)  Sections (8)  Shopping Carts (9)  Error handling (7)  Home pages (9)  Help (3)  E-mails (3)  Sitemaps (2)  Personalization (1)  Print-friendly (1)  Landing pages (5) 

General aspects

E-commerce (27)  Persuasive design (21)  Visual design (19)  Information architecture (15)  Accessibility (13)  Search engines (7)  Credibility, Trust and Privacy (6)  Emotional design (10)  Simplicity vs. capability (7)  Web applications (6)  Intranets (3) 


Flash (6)  Download time (5)  Javascript (3)  URLs (3)  Browsers (3)  Web standards (2) 


Bad designs (20)  Cartoons (14)  Fun music and videos (13)  Funny tools and games (12)  Misc humor (8)  Fun with Jakob Nielsen (9)  Designs with humor (3)  Fun posters (5)  Funny 404 pages (2) 

Resource types

Research (129)  Tips and guidelines (95)  Tools (106)  Books (47)  Audio and video (48)  Interviews (30)  Cases and Examples (28)  Talks and presentations (18)  GUUUI articles (11)  Primers (14)  Online books (5)  Posters (5)  Glossaries (3)  People and organisations (3) 

Information sources

Blogs (12)  Websites (11)  Discussion lists (4)  News (3)  Newsletters (3)  Online magazines (3)  Wikis (1) 

  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI