“Three point five pages.” It’s my usual answer when someone asks me “how long should my web form be?” And believe it or not, many people ask. It may be the most common web form design question I get asked. So I’m not exactly ecstatic that my tongue–in–cheek answer mostly draws blank stares and very few laughs. You see, it turns out this is a topic that many people take quite seriously.
And take it seriously they should. Web forms are the linchpins of most online businesses and applications. Whether they are responsible for checkout on e-commerce sites, communication on social applications, or any kind of data entry on the web, forms allow people to complete important tasks. And web form design details can have a big influence on how successful, efficient, and happy people feel about the process. Especially details like form length.
I often get asked how long web forms should be because web designers and developers want to know:
- Do one–page forms convert better than multiple page forms?
- Will breaking up a long form across several pages simplify the process of completing a form?
- What about rich interactions that manage multiple sections of a form on a single page?
Let me level with you up front. There is no magic number like “three point five” that will work in all cases. Your audience, their intentions, your systems, your policies, and more, will ultimately define the solution that’s right for your product. But you can arm yourself with informed design solutions so that when the time comes, you can pick the right answer for your specific situation.
One such solution is accordion forms.
Accordion forms#section2
Accordion forms use dynamic interactions on a single web page to hide and reveal sections of related questions as people go through the process of completing a form. This allows people to focus their attention on one set of questions at a time without requiring them to navigate between different web pages.
Accordion forms have the potential to be really effective because, in general, hiding irrelevant form controls from people until they need them results in forms that are easy on the eyes (i.e., less distracting) and they can be completed quickly. Couple that with the time saved on page reloads and getting people orientated on new pages, and accordion forms begin to look like an interesting solution for helping people complete lengthy forms on a single page.
To illustrate the difference between a typical multi–page form and an accordion form, we need look no further than the Apple store’s recent checkout redesign. Apple’s previous checkout process used several different web pages to capture customer, shipping, payment, and account information.
Figure 1: The Apple store’s previous checkout process spanned several web pages.
Apple’s redesigned checkout process dropped multiple pages in favor of a single accordion form that reveals one set of questions to customers at a time. As you can see in the video below, people are first asked about their shipping information. Once complete, this section slides up revealing questions about payment options. Once payment details are entered, the account information questions are revealed, and so on, until the form is complete.
Video 1: This sped up video of the Apple store checkout process illustrates an accordion form in action. So, Apple’s using accordion forms; should you?
Putting it to the test#section3
To better understand how accordion forms influence conversion and usability, I worked with Etre, a London–based usability firm, to test 24 average users (ranging in age from 19 to 48) on four variations of a typical e-commerce checkout form. We asked people to complete a purchase by entering information about themselves, their shipping address, and their payment information. This is essentially the same information that Apple’s checkout process requires, without the additional step of creating an account.
Figure 2: The four variations of a typical e-commerce checkout form we tested: a) multiple pages, b) single page, c) accordion with headers, d) accordion with buttons.
The control version of our four forms separated the questions people had to answer across multiple pages. We also tested a version with all the questions on a single web page, and two versions of an accordion form that revealed additional sets of questions as people completed the prior set. One of our accordion forms required people to click on section headers to expand each set of questions on the form. The other made use of a continue button within each section that, when clicked, automatically expanded the next section and collapsed the previous one.
For each variation, we measured success rates, error rates, completion times, satisfaction ratings, and standard eye–tracking metrics. We presented each form randomly to minimize familiarity bias.
But enough setup—what did we learn?
Constant conversion#section4
Let me give you the good news up front. Each of the forms we tested had a 100% pass rate. That’s not all that surprising when you consider the task we gave our participants was familiar to them since each participant we tested had been using the internet regularly for more than three years.
This tells us that simply porting the same questions you have on one long web page or across several web pages into an accordion form isn’t likely to increase conversion—at least, not for common tasks like e-commerce checkout.
The flip side of this, of course, is that accordion forms aren’t likely to negatively influence conversion either. When you consider that most innovative user interface solutions typically have an adverse influence on conversion rates until people get used to them, this is an important finding. Accordion forms don’t seem to have this effect. They might not move the needle dramatically upward but they aren’t likely to tank your conversion rates either.
At this point, I should pause and remind you that we tested 24 people on our generic e-commerce forms. To really test conversion, nothing beats testing your actual audience on your actual site.
Need for speed#section5
Where we did see a noticeable difference between accordion forms and the single page and multiple page forms we tested was in completion speed. People were fastest with the button–based accordion form we tested (option D in Figure 2 above). Surprisingly, about ten seconds faster than even the single page form (option B).
While completion speed may not be paramount for e-commerce, there are plenty of other situations online where quickness matters. Online auctions or exchanges come to mind, where the failure to act quickly could result in a lost opportunity. Accordion forms just might fit the bill in these situations.
Accordion around#section6
The primary difference between the two accordion forms we tested was in how people made their way between the different sections. Version C (Figure 3) required people to click on the header of each new section to expand the content within it. In this layout, a final action to complete the entire form was always visible.
Figure 3: In this accordion form (version C), people needed to select each header to reveal the next set of questions.
Version D (Figure 4) instead required people to click on a primary action button within each section of the form. Selecting this action would collapse the currently open set of questions and expand the next set (which also contained a primary action within it that moved people forward).
Figure 4: In this accordion form (version D), people needed to select a primary action button to reveal the next set of questions.
In our testing, very few people thought to interact with the headers as they made their way through our forms. The vast majority of our participants quickly gravitated to the primary action buttons and clicked them to move on. Even our explicit labeling of the form’s final action (in Figure 3) button as “Make payment and complete order” didn’t help. People selected this action to move forward even though they had not yet entered any payment information. This, of course, resulted in some unintended errors.
The lesson here is that even when innovating, you should try to embrace conventions. Though accordion forms may be new to many people, clicking on a visually prominent button to complete a web form is not. The form design in Figure 4 builds on this existing behavior by expanding the next section when someone clicks on the primary action on the form.
The form design in Figure 3 breaks with this behavior by forcing people to interact with non–standard form controls like section headers. This requirement made accordion forms feel foreign and complex to people instead of familiar and easy.
Being accessible#section7
While our user testing didn’t specifically target people with disabilities, access for everyone is an important design consideration. Single and multiple page forms, when properly implemented, are familiar models that keyboard–only and assistive technology users can usually handle. Accordion forms, however, may be different story. Luckily support for WAI-ARIA, which allows complex controls such as accordions to be properly expressed, is growing quickly (it is being baked into HTML5) and may ultimately make accordion forms more accessible.
More to learn#section8
Our quick test seems to indicate that accordion forms may have an interesting future online. They can bring multiple page forms together into a single set of dynamic interactions that—when designed well—don’t negatively influence conversion rates but do reduce time to completion. Of course, there’s a lot more to explore about where, when, and how we should use accordion forms. But consider this design solution a quiver in your bow—ready to use when the right situation arises.
Thanks#section9
I’d like to thank Etre for all their work scripting, running, and reporting on this study.
Surely it’s about accordi*o*n forms instead of accordi*a*n forms?
“”Three point five pages.” It’s my usual answer when someone asks me “how long should my web form be?””
I appreciate where you’re coming from, Luke, but *you* are the expert and the people asking the question obviously are not. Derision is hardly an appropriate response.
Helping them understand what is involved in designing the form might be a more optimal – and professional – response.
Overall I thought this was a very well written and informative article.
I wanted to bring out 1 point about ARIA. New screen readers, I’m sure, do support ARIA. But the problem with most readers is that they are crazy-expensive to not only buy, but upgrade as well.
JAWS, the most popular screen reader, costs around $900 and that’s just for the standard version.
I guess my point is that we can’t really rely on disabled people having up to date screen readers, like we do for people who can upgrade a Web browser for free. So be cautious in fully relying on cutting edge accessibility techniques.
I’m not sure where that leaves us in regards to accordion menus (I would love to test one in a screen reader), but I think it should speak to the importance of using proper markup while creating these forms.
Very good read, thanks for putting it together.
@gef05 -it’s a joke. Sorry if you’re upset.
To your request: “Helping them understand what is involved in designing the form might be a more optimal — and professional”
That’s what the rest of this article is all about. Hope you find it useful.
@Tim Wright -if you get a chance to test one -let us know what you find!
thanks.
Interesting article, but with a 100% pass rate I think “accordion forms aren’t likely to negatively influence conversion” is inaccurate. The right conclusion is that the test doesn’t accurately model conversion rates, so those shouldn’t be predicted here.
Right now I’m looking at split testing data from a live test, pitting a long form vs a form broken into steps on a single page (almost identical to an ‘accordion’ form) The test has a sample size of several thousand users, and so far both pages are converting exactly the same.
I’m not saying that accordion forms don’t have the potential to help conversions – I just wanted to illustrate how important testing can be, and how dangerous it can be to make assumptions about user interaction.
A proper accordion form could be made accessible without using ARIA tags. As long as you are hiding the sections in a way that doesn’t cause the screen readers to not see the sections (position:absolute;left:-9000px; or height:0;overflow:hidden; vs display:none;) screen readers will simply see the form as one long form.
If you set it up properly it would be even better for screen readers than the long form because you are breaking the form up logically instead into clearly labeled sections/fieldsets rather than one long form. This should be done anyway but this display model forces it.
ARIA tags are fine and dandy but they are more important for non-standard interactions rather than something like forms, which screen readers typically handle very well.
I think that 100% pass rate of only 24 users isn’t really meaningful result, but increase in speed of completion is very important if it’s impossible to shorten a form.
As I can see, accordion forms is a great idea. Thanks for the article!
@monty -thanks for letting us know about the data. Any chance you can share the details?
@n80 -this is qualitative/small sample stuff that illustrates the same thing i’ve seen on larger quant analysis like those mentioned by @monty above.
@gef05 -it’s a joke. Sorry if you’re upset.
To your request: “Helping them understand what is involved in designing the form might be a more optimal — and professional”
That’s what the rest of this article is all about. Hope you find it useful.
@Tim Wright -if you get a chance to test one -let us know what you find!
thanks.
@mdarnell -thanks for the added info. I’m not an accessibility expert but was asked to include some info on accessibility considerations. So thanks for putting in a more informed opinion! appreciate it.
@Luke Wroblewski, Great article. Very helpful information.
@monty, Would be great to see any conclusions from your test.
@luke, Thanks for this article which —like any good story— leaves many questions unanswered: Did people feel different about the different forms? Were people able to freely navigate between the different sections and choose their own order for filling out the form? How about designing the headers of the accordion sections more like buttons?
@kevin I think you just drew my daughter’s all time favorite straw. Nice.
@editor: figure 2 should be: c) accordion with buttons d) accordion with headers.
Great article.
I think you missed talking about one of the best parts of the Apple form, which was the summarised information from the previous section. The fact that it gives you all the information as text in a new, cleaner format, gives you a chance to quickly look back and confirm that you didn’t make a mistake in a previous section.
@editor Sorry my fault. the figure caption is just fine.
Great article.
What about validation errors indications, both server client side and client side?
I guess client side validation might be done on acordion slide change, but what about sever side, when erros might be for fields in several slides?
Shmulik
First, let me say that I found the article to be interesting and well-written. however, one rather jarring note was “But consider this design solution a quiver in your bow”.
my weird brain kept trying (and failing) to make sense of that.
a quiver is a container to hold a number of arrows, usually carried on the back. “another arrow in your quiver” makes sense,
esp. since a archer would carry a number of different types of arrows in his quiver, so he could choose the one most suited to the current task :o)
Great study and article.
Do you by chance have the means and standard deviations of the task times between both forms? I was unable to determine if the same 24 users interacted with all forms (within-subjects) or whether you randomly assigned people to only one form type (between-subjects).
@skilldrick -“summarised information from the previous section” -we didn’t find that people interacted with these summaries in the study. could be that is was familiar data to them. I specifically looked into this as, like you, I thought this was a nice feature.
@ shmulik you can do validation on section change (see the apple video) or inline see: http://www.alistapart.com/articles/inline-validation-in-web-forms
@ rhammack another arrow in your quiver is correct thanks 🙂
@luke – I love the answer ‘three point five.’ I often receive the question of how long a web video should be, and often respond, “Never more than 54 seconds,” or “Exactly 4 minutes,” when the answer obviously depends on the content, the audience, the campaign, among other factors.
Great post.
iCITA (Illinois Center for Information Technology and Web Accessibility) has a few examples of using ARIA tabpanels, one of which is “an accordion form”:http://test.cita.illinois.edu/aria/tabpanel/tabpanel2.php. It’s worth looking at if you’re interested in upping the accessibility ante.
The thing that interests me with this and similar design patterns (e.g. forms in tabs) is how you relate validation errors to the user once they hit the bit ‘Continue’ button that actually does the form submit to the server.
You can, of course, expand the section that has the error in by default (all other sections contracted). But what if there are multiple errors in different sections.
There are ways of marking the section headings and such forth, but as you say about the ‘click the heading’ approach, they start to drift away from what your average user knows about filling in a form on the web.
Apologies, only noticed your response to @shmulik having submitted my comment (hadn’t noticed the pagination for comments section).
Still, does doing server side validation negate the impact of an accordion form? I presume your tests used JavaScript to expand/collapse the sections (which is fine), but if you have to server round trip instead does the user get frustrated by the delay?
And what if the user decides to go back – do you validate what they have input on current section and not let them go back until fixed? Throw what they have input away? Or keep dirty data until they come back to this section (if indeed they actually bother to).
All interesting dilemmas and, as you say, not a “one size fits all” approach.
@bugrain -best to do client side validation dynamically as people complete each section rather than at once when you submit the entire form. Since you are dynamically displaying the panels -you are already in bed with Javascript. Might as well go the extra step and do client side validation -no?
thanks for the comment!
I don’t agree with some commenters who say a 100% pass rate is useless. To know that accordion worked as well as other approaches is, in my book, very useful indeed!
I am puzzled, however, by the speed result which showed the accordion faster than the single page form. Luke, do you have any idea why that would be the case?
Also, is the approach to navigation that you used in “D”—i.e. “continue” and “back” allowing movement between sections—your recommendation? If so, do you suggest:
* triggering client-side validation upon each submission of the continue button?
* not having any other mechanism (e.g. + and – icons in section headers) to change the display and location in the form?
I enjoyed the article, Luke. It’s good to see some numbers behind the different methods, so thanks for that.
One comment though, I’m not convinced about your conclusion on the clickable headers vs. continue buttons because I think that:
a. To suggest clicking, the headers need to be designed as such – either using some button design conventions or by using the (pretty much standard) arrow/triangle that’s usually used to indicate a collapsible section.
b. The form submission button should be inside the last section. In it’s current position and with the current section header display, it’s more prominent and easily identified as a call to action, so it’s no wonder really that people clicked on it first.
Hey mate,
Great article, very well written up. I think the sample for the testing might have been an issue though. If they all had 3+ years of experience, they may not be an accurate reflection of people buying things online (think about 14 year old kids buying things with their parents’ credit cards!)
J C
Designing forms is always a headache and it is great to see what actually works.
However, I have been wondering if an AJAX submit vs a page refresh or new page has any impact on user experience?
Thank you for the article Luke, it certainly was a very interesting read. I get the joke about the 3 point 5 pages per form, however in my opinion there is only one valid answer to the question “how long should my web form be?”: as short as possible.
I think that accordions can be very useful to speed up the form completion process in cases where the multi-page form already has very high pass rates – like the old Apple checkout form.
On the subject of validating form data, what’s your opinion on validating each field directly or validating entire sections?
I often have to design forms that have to accept a variety of phone number and zip code formats that need to be saved in a certain pattern to allow automatic processing of the entered data.
Do you think it might be more useful to point out errors immediately after the user has entered the data or is it better to let him correct all the possible errors at once after he has tried to submit the form?
Thanks for your answer.