How does your web form flow?
Posted February 22nd, 2010 by David Hamill
When designing web forms, you should always consider the flow. By flow I mean the sequence of thoughts and interactions that takes place when your user is completing the form.
In this post I’m going to tell you about a time when I got it wrong because I didn’t consider the flow properly.
Once upon a time…
Several years ago I was testing a web form for an event management system. Employees would use the form to confirm their attendance and notify the organisers of any dietary requirements they had and stuff like that.
There were many problems with the form but one of them was to do with reference numbers. An optional field for a reference number (referred to as the invite number I think) was causing some problems. I can’t remember the exact details, but the question was something like the one I’ve mocked up below.
People who didn’t have an invite stalled here. Without an invite, they didn’t yet have an invite number. They could have left the field blank but many people felt uncomfortable doing so. It seemed that because the question was being asked, they thought they should have a number.
The solution
The solution the team arrived at was to put a checkbox directly below the field as shown below. It’s wasn’t my suggested approach, but it worked well in usability testing. The proximity of the checkbox to the textbox created an association that resolved the problem. Users felt happy to leave the textbox blank because they’d checked the box. They were typically delayed for less than a second while they worked this out.
I was impressed with how well this solution worked and have remembered it ever since. What I didn’t really consider was how it flowed. I just remembered that its presence gave the user permission to leave the textbox blank.
Until a few months ago…
I remembered this approach when I was advising a client a few months ago and suggested they incorporate it into one of their forms. They had two mandatory fields on one of their form. One for daytime phone number and one for an evening number (see below).
I was concerned that some people wouldn’t realise that they could put the same number in twice. So I suggested adding a check box under the evening phone number, in order to give them permission to do so. (see below).
As well as allowing permission to use the same number twice, the checkbox was supposed to save the effort of typing it a second time. If they checked the box, it would populate the evening number field with the daytime number.
In testing, nobody had a problem entering the same number twice. But everyone who did so, typed the number twice (or copied and pasted it) before noticing the check box. The form didn’t flow properly. The check box became noticeable only after it would have been useful. It didn’t cause a major problem but people realised they could’ve saved themselves some effort.
How are the two solutions different?
So why did the solution work so well for invite reference numbers, but not for phone numbers? It’s to do with the way the forms flow.
People complete forms one question at a time and their gaze doesn’t stray far from the questions and the left-hand side of the text box.
When the answer to a question is easy, they’ll just type in the answer without considering anything else on the form. This is what was happening with the field for evening phone number. They are only likely to notice things underneath the text box after they’ve finished typing a response.
But when the form asks a difficult question, they need to stop and think. The smooth flow is interrupted and they are more likely to notice things that are placed after the text box. This is what happened when people were asked for an invite number they didn’t have.
Improving both examples
Invite number
The original solution for the invite number worked very well in usability testing. So in practice I wouldn’t change it (If it ain’t broke…). However in theory the flow can be improved by adding to the question. You probably realised this yourself.
In this example, the fact that not everyone needs and invite number is communicated alongside the field label. There’s no need to interrupt the flow. People without an invite number will simply leave it blank and go to the next question.
Evening phone number
The pictured example below shows how the user can be given ‘permission’ to enter the same number twice whilst only typing it once. Instead of placing a checkbox underneath the field for evening number, it is placed underneath the one for daytime phone number. The label on the checkbox has changed to ‘This is also my evening number’. Checking the box pre-populates the field for the evening number.
The checkbox now works in harmony with the flow of the form. Users type their daytime phone number before they see the checkbox. If their daytime number is also their evening number, then they simply check it in order to prepopulate the following textbox.
Conversation
The flow of your form is part of what Caroline Jarrett refers to as the ‘conversation’ your form has with the user. When you have a conversation with someone, that conversation has a flow. When you ask someone a question you tend to pause and wait for an answer. Think of a form field as that pause in the conversation.
When you ask someone an easy question, they will probably start answering before you’ve even finished asking. But when the question is more difficult, you can follow the question up with clarification if it’s needed.
Was this blog post useful?
If you found this useful, here’s a few things you can do:
24 Responses to “How does your web form flow?”
February 22nd, 2010 at 10:20 am
David, this is so valuable! Thanks for pointing out the obvious. So often we’re presented with lists of information that the client wants to gather and we put it in place.
This reminds us yet again that we need to stop and think about the form elements of a site as carefully as we do about navigation and getting the user through a call to action in the first place. Keep ‘em coming!
February 22nd, 2010 at 10:26 am
Thanks Dan. I was worried that the issues I was describing were a little too obvious. But without usability testing, these issues often sneak past and make it onto the live site. Usability testing findings are often swamped with issues that appear obvious when explained with the benefit of hindsight.
February 22nd, 2010 at 10:48 am
Excellent examples here David! The explanations were very helpful for explaining what each specific problem was, and why there even needed to be a new solution.
Spending time putting though into how a form flows is incredibly important to keep your conversion high – after all, the ideal form would supply no reason for a user to bail before completion.
Thanks for the article, will spread it around Digital Results!
February 22nd, 2010 at 12:01 pm
[...] the rest here: Good Usability » How does your web form flow? Posted in Form | Tags: and-stuff, attendance, attendance-and, confirm-their, event-management, [...]
February 22nd, 2010 at 12:25 pm
David, your solution to the evening phone number problem is not only better for general usability, but also for accessibility. In the “old” version, (assuming the source code order follows the visual display) a screen reader user tabbing through the form would hear the checkbox details after the text input field, by which time it may be too late to be useful: exactly analogous to a sighted user not seeing it until after filling in the input field.
A similar solution would be useful for the invite number example too.
February 22nd, 2010 at 12:32 pm
Hi Keith. I see your point but you’re describing issues that can easily be avoided with the right code. So you need to jump to the conclusion that bad coding has been used in order to decide that there is a problem with it.
February 22nd, 2010 at 1:11 pm
Good article
But how about entering small text under the second number saying “Leave blank if the same as day number”…
February 22nd, 2010 at 1:21 pm
Hi Nikola, thanks for the comment. In the scenario I discussed, this approach would be the same as the checkbox. Many people would notice after they’d typed in their number that they could have left it blank. Then there is the question of what to do after that. Do they leave the number in twice or does the form want them to delete the 2nd instance of the number?
February 22nd, 2010 at 5:54 pm
I couldn’t agree with Dan Frydman more. Great post and it forces you to re-evaluate the little things on your website. Things that you never thought about *thumbs-up*.
February 22nd, 2010 at 6:20 pm
Thank you David, you reminded me that forms are a type of writing. They also require thoughtful sequencing and proofing. I think I’ll try out my own forms from now.
February 22nd, 2010 at 6:53 pm
This case study is as valuable as it is simple. I’ll be sure my forms are designed from a “top down” approach
February 22nd, 2010 at 6:54 pm
I think a little bit of common sense is everything that is needed here, in this overly simple example. It’s not really rocket science. Now, a more complicated case study – that would be interesting to see, David.
February 22nd, 2010 at 7:24 pm
Hi Artem. The example is very simple I agree. That’s why I chose it. I try to choose examples that illustrate a principle. In this one I’m talking about how people behave differently when dealing with questions of varying difficulty. Hopefully a simple example helps to communicate the point.
February 22nd, 2010 at 8:14 pm
Your last point about treating the form as a conversational piece seems to be the new trend of form design. I’m noticing more and more of informal conversational tone in form labels.
This reminds me of this particular sign up form at Huffduffer where the entire form is a dialog.
http://huffduffer.com/signup/
I’m not certain this will test well in terms of completion speed or ease of scanning.
February 22nd, 2010 at 9:50 pm
Today I have found what I have been looking for and that is a very big day for me! Thank you for this blog and this post (del.icio.us poetry)and I hope you will publish my comment as this is a great site and worthy of congratulations. Lizzie Soul
February 22nd, 2010 at 9:51 pm
Hi Lizzie, thanks I did publish your comment despite it being picked up as spam. I just took out the keywords out and replaced it with the name you provided.
February 23rd, 2010 at 8:49 am
Great article indeed.
I didn’t understand something: why not simply remove the “mandatory” asterisk from the evening phone? As a user filling many forms in my past – I encountered many cases where only one of the phones were mandatory and the other weren’t – meaning only the first one is the one to be used.
February 23rd, 2010 at 8:59 am
Hi Yoav. There are many ways that the problem could be resolved. Your method would work if the labels were changed from daytime and evening to preferred and alternative numbers. However clients aren’t always able to be so flexible. Having made such a change would have apparently cost a lot of money. What seems like a simple change to a website can actually be quite difficult for some large businesses.
February 23rd, 2010 at 11:11 pm
Why not do the same thing as you suggested for the invite number? Just add an explanation to the label:
Evening phone (if different from daytime phone)
This flows perfectly, without the repetition.
My suggestion is not original, of course. It’s been used in order forms (paper and online) for years. They ask for your billing address, and “Delivery address (if different)”.
February 24th, 2010 at 9:22 am
Hi Bennet, thanks for the comment. As I said in the comment above yours, there are a number of ways it could be resolved. I didn’t want to include a thesis on the client’s situation in order to make the point. Your example would work well too.
February 26th, 2010 at 9:33 pm
Very good article, Dave. Flow is very important. I like how you tackle and differentiate between the considered and immediate response and how that impacts flow.
The rest of the solutions posted by readers are valid too. I love how there is flexibility in usability…well, sometimes.
We had a similar issue in a recent test. The form was a typical credit card detail thing – name on card, expirations date, etc.
However, the boxes were out of order. The credit card number box was last and at the bottom of the page. The format of the credit card number was displayed below the box but most people missed it. They saw the input box at the end of the field an immediately entered the details without looking at the example below. Wonky flow.
Great article, sir.
March 18th, 2010 at 2:14 pm
Although this will obviously vary from site to site, and form to form, would it be helpful to assume a few things about the user’s input to help them along? For example, if most people ended up checking the box so the same phone number was entered in both fields, perhaps have it checked by default. As Bennett said, forms have been using the “if different” setup for quite some time. Taking that a step further, do you think it would be helpful/usable to allow the user to uncheck that box to reveal another field for Evening Phone?
October 21st, 2010 at 2:38 pm
Very nice solution David. Web form design is too often just glanced over as a ‘technical task’ that the web developer implements, when infact every field, the form as a whole, and as you’ve shown, smaller sections of the form all need careful consideration as to how they work together.
September 15th, 2011 at 1:19 am
Great post! I work with pharma companies collecting data in clinical trials, and while the folks completing the forms don’t have the choice of abandoning them, we do have issues around timeliness and quality of completion. Your tips will be very helpful!
Comment on this article