10 things every designer needs to know about forms

10 things every designer needs to know about forms

There are a lot of badly designed forms out there, but whether you like them or not, forms are essential. Joe Leech, user experience director at cxpartners, presents the lessons he wishes he'd learnt before he began designing forms

Forms, there's nothing many designers hate more than forms. They don't necessarily bring the creativity out, or do they? Maybe it's time we looked at forms again and understand that a form, at its most basic, is a conversation between the user and the software.

Forget point and click, forms represent the richest interaction we as digital designers will face. Next time a form comes your way don't think it's just a matter of applying some nice CSS effects or adding a nice jQuery flourish. There's much more depth to designing forms.

I've user tested hundreds of forms and designed some complex forms for insurance companies, holiday booking interactions and many more. Chances are you've used one of my forms in the last few months.

Here's the lessons I wished I'd learnt before I began designing forms.

1. Don't mark mandatory fields

You know the little asterisk that denotes a mandatory field? I've seen that fail many times in user testing. As a concept, mandatory fields don't make much sense, they have no offline equivalent. They are great for developers because they offer a nice black and white approach to completion. The asterisk and mandatory field fails because it is a learnt behaviour. Typical behaviour I've seen in user testing is the user completing the form at the top and finishing either when there is something to stop them or they hit a button.

The solution is simple, mark optional fields, mark the place where our nice user has to stop and think about if they need to complete that field.

2. Don't use spinners

HTML5 is brilliant isn't it? It offers loads of exciting new shiny tools to play with. We need to think about the appropriateness of our new toys. The number field now includes little up and down arrows to allow the user to cycle through numbers.

There are two problems here. Firstly the default browser display of the arrows makes them really small. Very fiddly to click and the fat fingered amongst us are going to struggle on an iPhone. It's called Fitt's Law, the smaller something is the harder it is to click on it.

But I hear you shout, you can just type the number directly into the number field. Yes, you can, but let's look at the browser display, the up/down spinner arrows resemble our trusty friend the select box. A user presented with a spinner for the first time is going to assume, as it resembles a select box, that they can't type into it.

My advice is to steer clear until they become more common place or the browser developers sort the default design out.

3. Have only one type of button or better still just one button per form

There's a little known psychology principle called Hick's Law. Hick's Law states the more options we are offered the harder it is to make a choice. Not rocket science I know, but a rule worth keeping in mind.

You can help your nice user by helping them make a choice. By making all primary buttons one colour, and having only one of them per page makes choice easier. Which is the button I should be hitting? Oh, it's easy, it's the big coloured one.

4. Chunk fields

I studied neuroscience in a previous life and so studied the psychology of memory – specifically short term or working memory. Now before you say it; no, short term memory capacity is not 7+/-2, 4+/-1 or in human speak three to five chunks. We as humans are great at evaluating visual stimuli, the constraint is we are better when the number is smaller. Chunking a form into smaller groups makes evaluation easier, as often what the user has to enter into the form comes from their memory.

Make sure your groups of fields are about four in length.

5. Think why you are asking something and how it feels to the user

This is probably the most straight forward piece of advice I give but is often the least utilised.

Let's take the following:

Question every question you ask. Is it necessary? How does it feel to be asked this?

More often than not there is a business need to ask a question and we as designers can argue about necessity until we are blue in the face. The question has to be asked. In understanding the business need for this data we can often compromise.

We can help by telling our nice user why we need to ask that question. Reassure about the usage and sharing of that data and just generally be nice.

Taking our example again:

It's still a tough ask but hopefully we've sweetened the pill.

6. Dates are squirmy little fellas

Entering dates can be a real challenge and there a few pitfalls you can avoid. The single biggest problem is dealing with errors.

The easiest approach is to launch a calendar. It's worth noting that weeks start on a Monday in the UK and a Sunday in the US. If your user isn't concentrating they may well select a Sunday when they mean a Monday.

It's also worth mentioning international date formats. The US places month first, in Japan it's year first. So a date like 4/5/12 could be interpreted in three ways.

That's why it's best to use select boxes.

7. Forms as developer craft

Forms are craft for developers as well as designers. Understanding what possible mistakes could be made with entering data and designing your back-end code to cope is a challenge.

Here's a simple one. Entering a currency value. The possible mistakes the user could make are huge. Forcing data formats that users have to meet is frustrating for your user and, let's face it, a little lazy on the developers part. 

What better challenge for a developer than building a bullet-proof form.

8. Don't use columns in forms

The big problem in using columns in forms is flow. We start a form at the top and end at the bottom. In introducing columns the flow of the form can be broken.

Don't assume users tab through forms and therefore focus is a way of navigating forms in columns. It's rare that I've seen that in user testing. Most of the time we see enter details, click to the next field with the mouse/trackpad/finger then enter details and so on.

9. Don't use two fields when one will do

Most people are not touch typists. In user testing we see people looking at the keyboard as they type.

When entering a telephone number splitting the form field, say to add area code and number, causes real issues. Users don't see or indeed remember that there are two fields so enter the full number in the first field, worse if the field is limited to a certain number of characters.

Use just one field for phone number, the same is true of house number/street – use just one text entry box.

10. Be nice

You'd be surprised about how many rather quite rude error messages there are out there.

Here's an example of one I came across recently.

The very fact they are suggesting you would willingly enter a date in the future and then a rather facetious response, well, it isn't very nice.

Again put yourself in the place of the user, how would you feel seeing this error? Annoyed? Maybe even worse. Being nice is easy.

I've produced a downloadable crib/cheat sheet to help you design better forms. It includes many more best practise ways to design better forms.

16 comments

Comment: 1

I agree with what you have said except for point 1. Yes it isn't ideal because as you say it is a learned concept. BUT it is one that has widely been accepted and adopted by the USER aswell as the designer. I have found that users automatically associate any features next to input types in a form as a required field by default. By switching the meaning of any input signifier to the opposite meaning will cause confusion to the users who have already learnt the standard required concept.

Comment: 2

Weeks start on a Sunday in the UK too.

Comment: 3

Hi Joe, I saw you talk at Bath Camp a few months ago about form design and both that talk and this article were really informative, but since then through my own user testing I would not completely agree with your first point.

After testing out both methods, I've noticed that when using the 'optional' method most users choose 'not' to fill in those 'optional' fields, whereas when using the 'required' method, most users fill out the entire form (even the non-required sections). That might be due to user conditioning, but if you want to gather as much data from the form as possible, the required method returned better results for me!

Comment: 4

Very interesting information worth keeping this when creating a web form from all point as I read the comments so far, thanks!

Comment: 5

@liamjay66

I totally agree. The "Optional" field with all my testing and even my own personal experience (the way I use the web), optional means to me just that "optional". I never fill out optional fields because I don't have to.

I feel that the little red asterisk has been used so much now, that is muscle memory. To the point where they don't need to read why the red asterisk is red but know that is just a required field that must be filled in or an error will occur.

Other than that, I don't fully agree on the whole of your article, but I do agree on the vast majority of it. Great tips and a few things I haven't thought about in the past.

Thanks!

Comment: 6

From a design standpoint I'm a big fan of not using the astricks. I mark my fields that are optional by placing (optional) using the HTML5 placeholder and use a javascript fallback so those IE users aren't left in the dark.

I 100% agree with custom messages. I avoid using crafty messages because I never know if I'm going to offend anyone. I stick the default stuff like " Name is required".

Good read though. It's easy to get into a rut with forms.

Comment: 7

A few more gripes about form design:

When requesting user's country it's not clever to present a drop down list of the entire globe (.net magazine take note) I'm just guessing here but a UK based mag will probably have more subscribers in UK than in Tokelau (wherever that may be) - either have a stab at detecting the user's location from their IP or list the most common at the top. And while I'm on the case of .net mag - take shift-lock off, I want to read Tokelau not TOKELAU.

You discuss required fields, .net does it again. The registration page for this forum doesn't indicate required fields but when I left *Personal link: http://* blank I got an error. I don't want to give you my web address, why do you want it? Which of my several should I give anyway? so I registered as example.com you just wasted my time and yours.

When requesting credit card expiry all mine have the format mm/yy like 07/12 so why present the month in a drop-down of month names? Similar applies to any date input field, if you're offering a month dropdown then it could say something like 1:January, 2:February etc

You mention currency fields. My pet annoyance is HSBC where pounds and pence are separate fields. It might help a bit if pence defaulted to 00 or at least could cope with a single 0. There is a confirmation screen so if you accidentally submitted without entering your pence there's a second chance but really I'd prefer to see a field where you enter 123.00, (accepting also instead of stop, colon or hyphen as separator). If user enters just 123 then pop up an alert reading "amount = £123.00 confirm of modify".

A personal preference maybe: I like field validation on field exit rather than wait till I submit the whole form and get a rejection. People seem to think JS validation is an alternative to server side - my vote is for both, largely because the spammers can circumvent the JS but also the form could work with JS disabled.

Enough for now got to google Tokelau ...

Comment: 8

With point 1, I've recently tried to design forms where everything is optional. For me this is more so when its a web service and they ask me to register first.

Its also great to see video feedback of people using forms ( e.g. usertesting.com ), even a handful of testers can tell you a lot - it'll pick up lots of unknown unknowns.

Comment: 9

Really great article, not sure I agree about point 1 though. Surely if most of the forms out there are highlighting the mandatory ones, doing the opposite approach would confuse the user?

Personally, I usually skim through the page, and enter the minimal amount of details I need to. Maybe this is force of habit, but it works, and quite effectively. If this was to change, my workflow would somehow be impeded. How about simply reducing the opacity of the optional items or just use a lighter colour to identify them?

Comment: 10

Great article. For #1, I often try to group required fields and optional fields in group--boxes. I agree with some of your commenters that labeling them "optional" individually may confuse some users.

Also: To register on this site and comment, that form broke most of your rules and was agonizing. Another issue brought forward by that form, the ridiculous requirements for a super secure password. This is not a banking site. Why reject any password? Even banking sites sometimes have such convoluted requirements that it becomes impossible to remember all the variations of passwords made necessary by arbitrary rules. The only choice is to write them down which is defeating the security in another way.

Comment: 11

Hi Joe, thanks for the article.

Interesting that you've seen the red asterisk baffle users many times. I've not seen this much at all in my testing (here in Australia). I've also probably seen about the same number of people say "where's the red asterisks?" when I've tested a form on which every question must be answered, and this has been communicated via an instruction just before the first question.

I tend to agree with some of the other commenters that the red asterisk has — rightly or wrongly — become a bit of a defacto standard for a good proportion of web users. And I don't feel that no offline equivalent = bad idea for web. There are no drop-down (list boxes) in the offline world either, but they're very handy in the electronic world!

My 2 cents: mark whatever there is least of. If a small proportion of questions are optional, mark those with "(Optional)"; if a small proportion of questions are mandatory, mark those with the red asterisk. And always include an instruction at the top of the form explaining what's been done.

Cheers
Jessica

Comment: 12

Great article but I'd take 1 & 5 & 9 and take it a step further - don't make a field required unless the basic interaction that the customer is signing up for really does require it. As a customer I get so sick of being asked for information that is entirely irrelevant to the task at hand. I don't give a stuff if you want it for 'business reasons' - by making it required you are saying to me that you won't transact with me unless I give you that information. Make it optional.

Comment: 14

hey guys,

Thanks for the comments.

@jjmu15 The asterisk is a construct we should move away from. Let's be more human in our interactions.

@liamjay66 You are right, but don;t forget we have to justify why we want the information rather than hoping they fill it in because they think they have to. Be honest and open and people will leave data.

@rob1951thanks Rob.

@Jessica/Formulate You point: 'My 2 cents: mark whatever there is least of. If a small proportion of questions are optional, mark those with "(Optional)"; if a small proportion of questions are mandatory, mark those with the red asterisk. And always include an instruction at the top of the form explaining what's been done.' makes a lot of sense.

I don't hear the asterisk thing as much as I used to (been testing for 10 years now). People are more used to it but it doesn't mean it's right.

The red asterisk is not a friendly helpful interaction pattern. Even the term required/mandatory are strong. Forms are conversations. I'd never tell you what I expect you to say but would give you the choice as to what you (optionally) chose to say.

@hindins agreed!

Keep the comments coming,

joe

Comment: 15

@mrjoe

I agree that just because people are used to something doesn't mean it's right. But I don't agree with your implied argument that just because something is symbolic, it's not human. A play button (the shaded triangle pointing to the right) is just as abstract, but does that mean it doesn't work and we should come up with something else?

Having said that, I'm sure we agree that a form should have as few optional questions as possible, or none (if we don't /need/ the data, why add to the user's burden by asking for it?) in which case my rule and yours coincide, and optional fields are marked. Win!
July issue on sale now!

The Week in Web Design

Sign up to our 'Week in Web Design' newsletter!

Hosting Directory
.net digital edition
Treat yourself to our geeky merchandise!
site stat collection