UIEtips: Previous and Next Actions in Web Forms

Jared Spool

January 27th, 2009

Most online design requires the designer to focus on two separate but equal elements. The content of the design and the chrome that supports it. (Do you think I’ve watched too much Law and Order over the years?)

Take a multi-step dialog sequence, such as, say, signing up for a new account. Each step will have the content — the fields the user will fill in, including their name, address, and billing information. Yet, each step also requires some user interface chrome — those design elements that move the user to the next step (or back to the previous one, when something needs revisiting).

What I find interesting is, often in the design process, we focus more on the chrome than on the content. Yet, it’s the content that is most important to the user — the part of the UI they need to focus on most. The chrome, when it’s working well, should seem invisible and natural.

In today’s UIEtips article, Previous and Next Actions in Web Forms, Luke Wroblewski shows us what we need to know to make an important part of that chrome invisible: the Previous and Next actions. He’s done a fabulous job of dissecting the problem and talking about exactly what needs to happen to make the interface seem natural to the user, which, in turn, lets them focus on the content.

Luke, of course, is *the man* to talk to when thinking about these things. His brilliant book, Web Form Design: Filling In The Blanks, is chock-full of great insights. We’re pleased he’ll be repeating his full-day seminar, Web Application Form Design, at our upcoming Web App Summit.

What’s been your experience with the sticky problem of Previous and Next actions? Do you have a solution that works well with your audience? We’d love to hear your experiences and questions. Leave a comment below.

7 Responses to “UIEtips: Previous and Next Actions in Web Forms”

  1. Clerkendweller Says:

    I’m pleased to see this discussion and explanation.

    The use of multi-part forms increases complexity behind the scenes too. A well-designed form can reduce the back-end coding complexity, and thus reduce the likelihood of faults and vulnerabilities being introduced to the code. Every time a user moves forward or backward, the data needs to be re-validated and re-displayed. Like the chrome, the code when it’s working well, should also seem invisible and natural.

  2. Elise van Looij Says:

    Very nice article by Luke Wroblewski, I’m bookmarking it. The ‘previous’ or ‘go back’ button is necessary, but I think the frequency of its use is also an indicator of the effectiveness of a design. Speaking from my own experience, the only time I ever use the ‘previous’ button is when the information on the preceding screen or page was unclear or incomplete. Example: do you want priority shipping (2-3) days or normal delivery (4-6 weeks)?
    Of course I want the priority shipping, but if it’s going to cost me a lot of money, I probably can wait. So, I’ll probably choose the priority shipping, keep on filling in information until I finally get a price (when you don’t live in the US that can take a lot of screens) then go back and do the same for normal delivery and make a choice — which might involve going back again.
    So I would say that if your statistics show a lot of use of back buttons, you might consider ways to provide more information upfront.

  3. Jeff Geurts Says:

    Elise makes a really good point. All too often when filling out web forms I find myself asking questions that I know I won’t have answers to until I reach the end of the process.

    In Luke’s article, he described a different approach whereby the form provides only a “Continue” function, in which case the user is provided with a confirmation of the information entered, and the opportunity to make changes. I think that is a fantastic approach in many cases, but it’s important to let the user know that the confirmation page is coming, or they can become frustrated (feeling that they have to start over, or to continue to the end just to find out they can’t correct their choices).

    I’ve seen this done well with progress bars, etc, but I’m wondering how you would take an approach like that if the users’ choices are able to branching in the process, which make it difficult or impossible to forecast the steps between the current one and the confirmation / changes page? Any suggestions out there?

  4. Charles Wyke-Smith Says:

    Jared’s comment above: “The chrome, when it’s working well, should seem invisible and natural.” jumped out at me, and reading Luke’s article only confirms what I think about this.

    I believe that there’s a lot more to the content/chrome relationship than this frequently-stated ‘chrome should seem invisible’ mantra – and here, of course, invisible implies non-distracting, as it’s not actually invisible. However, the notion of invisible chrome only makes sense when the user’s focus is on the content.

    While generally giving focus to the content over the chrome is a worthy goal – visitors come to your site for its content, not those groovy animated buttons you slaved over – it’s only part of this design issue. While chrome often disparagingly refers to visual clutter, if we define chrome as the essential but non-content elements of the page, then the more important objective is to ensure that the chrome elements are ‘instantly available’. When the user’s focus is on the content, they don’t fight for attention, but when the user’s focus moves to them, they become very present.

    Achieving this balance primarily means ensuring that the chrome elements are where the user expects them to be. The assumption that a site identifier such as a logo will be in the top left of the page is a common example of this “anticipation of location”.

    But to be more specific, “instantly available” means: immediately and unambiguously identifiable as the sought element when needed.

    So in this Next/Previous button example, as Luke clearly illustrates, not only the location of the button, but also its styling and the wording of its label, and the positioning, styling and labeling of other buttons need to be considered.

    You can quick-test for ‘instant availability’ through observation during testing – if, after the user completes each content interaction, the mouse immediately goes: move, click! in a smooth, confident action, you can yourself be confident that you got it right.

    The continual transfer of attention between content and chrome is central to the user’s interaction with our design, and user fatigue sets in quickly if we don’t design and test to ensure that both are “instantly available” as needed. Often, because the user’s past experiences play heavily into the anticipation of where specific elements will be located, this can simply mean following the well-evolved and thoroughly-tested design patterns of large, successful sites.

  5. Anton Andreasson Says:

    My question is: How do you tackle wizards with needs both a “previous step” and a “cancel” action? What goes where?

  6. LukeW Says:

    Hi Anton, If you are working in a “typical” wizard structure, you can offer ways out within the context of the wizard’s frame. Top-right placement is pretty common for closing out of dialog-based wizards, if you working with a full page wizard you may consider a top or bottom header to manage such actions.

    I’m going on the assumption that once you put people into a wizard their primary purpose is completion hence cancel, etc. are really “bail outs” vs. core to the task at hand -thanks~

  7. christianbeck Says:

    Hi Everybody
    Can some one let me know if NEXT / PREV is commonly an infinite concept when visiting a catalog content?
    Supposing that you reach an element in the middle of the catalog (but you don’t know).. Is it logical for everybody that succesively clicking NEXT / PREVIOUS would allows to see further elements(images) in one or in the other direction… up to the time the first visited element is reached again?
    Oppositely, in an NOT infinite NEXT/PREVIOUS “navigation” the cycling visit would not be possible: (from a middle element, you should go to an end…then eventually guessing that you should go back to the first point and continue to the other end)…
    Thanks for your help!

Add a Comment