The form of forms … We need them, but also hate them

I do not know whether you thought about it, but ...
When I think about rich websites, applications and interfaces – Aren’t they all ought to make live easier? Easier, more supportive, comfortable – providing a maximum of convenience and joy.
Well – and then are these boring forms – I think none of us falls in love with forms – but we need them.
I believe forms have to make our lives easier, not more difficult, as well. As design team, and I really think of the whole team graphical designers, projectmanagers, developers, IAs, and and and, we can or we should make our users' lives less hard and less difficult, just easy and as simple as possible, by thinking about the way people interact with our app, providing clear direction, and then putting the trouble of sorting out the details in the hands of the computers—not the users.
We've all heard and read about big usability mistakes time and time again: "Don't use images or flash for navigation," "Avoid using Java Script for links," and I certainly hope we're all considering those “good words” in our work. Yes - Often Java Script can help us and the user to develop supportive and helpful forms. And YES there are cases we can’t avoid or it’s recommended to use flash or images for navigation. But it shouldn’t be always our first step to do it that way.

Here are some basic rules you should know and you should deal with …
1. _ keep your form as easy and effortless as possible
2. _ be clear and stringent
3. _ be consistent in the way you use areas on the screen for help and for the main form flow
4. _ give the user enough room to type or give him room he needs
4.1. _ For instance – The length of zip-codes are almost the same for one country – If the user needs space for five or six letters why offer him an input field with space for twenty.
5. _ mark mandatory fields obviously and clearly
5.1. _ and before you do this – cut them down! - to make the form as short and smart as possible, I recommend a three-step evaluation of every element of the form.
5.1.1st _ Why is this a piece of data, answer, question valuable to us?
5.1.2nd _ Is this a data that is so important that it's worth denying users access to (whatever lies beyond the form) if they do not decide to offer it?
5.1.3rd _ Does the user need help to offer this data (we live in a mobile world – And do you have always the needed customer-numbers with you) – and then … :-)

5.1.4th _ The convention is to use an asterisk (*)

6. _ provide descriptive labels for all of the form fields – does the user “understand” the expression/phrase – is it common to him
7. _ the computer, not the user, handle information formatting - e.g. telephone number - There are many ways these numbers can be represented:
___ 0049 1234 123 123
___ or
___ 0049.*1234.12.31.23
___ or
___ #49-1234-123-123
___ or
___ (*49) 01234 123123
___ or or or … the system has to accept every input !
8. _ use informative error messages
9. _ and at least show him what’s called to do – what are the next steps or just give him a feedback every thing is fine

Hmmm – you say that this is all common and well known? If it so – please – tell me why are so many forms – sign ins, log ins, newsletter registrations, order forms, … and and and … and finally tax forms often so bad as they are?

And one more last comment - More than every other case when we develop forms for financial, insurance or government - a Use-Lab is more then helpful …
A. _ how easy is it for users to accomplish basic tasks the first time?
A.1 _ absolute beginners?
A.2. _ experienced users – who know the former versions?
A.3. _ experienced users – who know the offline / paper version?
A.x. _ and further more users regarding your project
B. _ once users have understood / learned the app, structure and design, how quickly can they act with it or complete tasks?
C. _ How well to remind of - When an user revisit to the application after a period of not using it, how straightforwardly can he bring back his capacity?
D. _ Does your user act as like you have expected and planed it?
E. _ How many errors do users make or appears during the session?
F. _ How helpful were these errors? How pleased and satisfied were your user?

… and never the least - How pleasant is it to your users to use the interface? And how can we improve the pain-points?
There are many other important quality attributes. A key one is utility, which refers to the design's functionality: Does it do what users need? Does it fit to the user? Is he satisfied?
Oooh forms - I like them and I hate them :-)


  1. I like your list.

    The most crucial part (and often neglected) is to be really stringent in thinking about why you want the data - and whether the user is willing to give you this data in this context.

    Do you have a misprint in this line:
    "3 - use constantly areas for the commission/help and the task"?
    I think perhaps you mean:
    "3 - be consistent in the way you use areas on the screen for help and for the main form flow"

    Caroline Jarrett

  2. what is the sequence of data on th form?

  3. do you have any model to suggest the sequence of data(fields) on the forms?

  4. Hi "Anonymous"
    maybe - but I need your task and aim.
    What kind of form?
    Which country?
    For example if we talk a about a address form in
    - Germany and Netherlands it's almost the same.
    - Germany and UK it will be less the same.
    - Also between Germany and Austria = same language different form fields
    - Europe and US it might be the same - it might be different
    without any further information I can't help you


Post a Comment