Relation between a Wizard's Previous button and history's Back button

Question

I have a web form split across 3 screens/pages. A user can move between forward and backward between the screens via Next and Previous labeled buttons respectively.

When the user presses a previous button, should it act like the history's back button, or should it "move forward in history" by navigating to the previous page?

To clarify the second scenario:

• User A fills out the first two pages of the wizard (History: page 1 > page 2 > page 3).
• User A hits the previous button to return to page 1 (History: page 1 > page 2 > page 3 > page 2 > page 1).
• When the user hits the browser's back button, it returns them to page 2 (in this scenario).

I believe that the previous button should act like the history's back button; however, I am seeking confirmation.

Answer 1

The Previous button should not act like the Back button. The Previous button means "go to the next-lowest numbered step"; the Back button means "go to the screen you were on before this one". In any given context they may have the same effect or different effects.

So here are two paths the user could take.

Step 1 Next→ Step 2 Next→ Step 3 Previous→ Step 2 Back→ Step 3

Step 1 Next→ Step 2 Next→ Step 3 Previous→ Step 2 Previous→ Step 1

This is how Next and Previous buttons, and Back and Forward buttons, have always worked. Don't change them unless you have a really, really, really good reason.

Answer 2

Short answer: the previous button should not act as the history's back button (if I understand your term correctly). Next and previous should navigate up and down the numerical sequence of steps.

In scenarios like this, you should generally try maintain consistency in the user's expectation for how the system will work. In the case of a linear series of steps within a wizard, the user will be led to expect that the "next" button navigates to the next step in the sequence, while the "previous" button navigates to the previous step in the sequence, regardless of where the user starts.

Answer 3

I understand your idea of the previous button basically doing the same thing as the browser's back button (it makes logical sense from a navigation standpoint), but be careful with how you're handling the programming side of things: if you fill out a form on a page, and then hit the back button, the default behaviour of the browser would be to abandon whatever was filled out on the page that was just left (e.g., filling out Page 3, and hitting back to Page 2, might lose form data from Page 3). It depends how you're implementing the navigation functions of course, but I think a loss of data has a bigger UX impact than any navigation scheme I can think of.

I can imagine a few methods of handling this:

1. The form is really all one single page, and javascript/css can be used to turn the different steps (page sections) on and off as if they were tabs and finally the whole form is submitted to the server all at once.

2. Your server saves a record of the referring page and upon hitting previous actually saves whatever data was already filled out (temporarily) so that it isn't lost, and the user can bounce back and forth between steps without frustration (however now the actual back button will behave slightly differently than the previous button in that pressing back will not save temporary data).

3. Don't use a wizard pattern. I personally find it much easier to navigate, understand, and use a long single page that only requires me moving my scroll-wheel (but I don't know how big your form is as this does have some practical limits). Single page vertical scroll is the easiest possible thing for a user to interact with and should be seriously considered. Practically speaking, the user can navigate sections by touch and without looking, while clicking on button elements requires fine-motor control and precise cursor movement and clicking (which anyone can obviously do, but it is harder than simply scrolling).

Finally, validation is one more consideration. Does validation occur on the client side and at each step (each time a user clicks next) or does it happen only at the very end on the server side? I'd be frustrated if I went through every step of a long form only to discover that something I did way back on step #1 was incorrectly formatted the whole time. I think in this day and age of super fast javascript engines, all forms should provide instant feedback if there's a problem on the client side.