3 Answers
3

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.

I think this is the correct answer here. Back and Previous are not the same thing, you've illustrated this perfectly.
–
JonW♦Feb 29 '12 at 11:39

Changed the accepted answer since this truly is the better answer overall.
–
JamesEggersFeb 29 '12 at 15:56

THIS THIS THIS! I've gotten very frustrated trying to purchase an item where shipping/billing address was in step 2, and get to step 4 (confirmation) and realize I made a mistake, but the back button erases all the info I put in during step 3 because it called the browser back button!
–
aslumFeb 29 '12 at 20:02

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.

You're right about the Previous and Next buttons. But are you really proposing to change the Back button so it works like the Previous button?
–
Bennett McElweeFeb 29 '12 at 3:49

2

I think I have to disagree with this accepted answer, or at least the phrasing of the first line. Previous is not the same as Back in history, as @BennettMcElwee detailed in his answer.
–
JonW♦Feb 29 '12 at 11:38

1

In my situation where I have a truly linear process, having a previous button replicate the behavior of the back button would work; however, I'm changing the answer since Bennett's is better in terms of general advice beyond my scenario.
–
JamesEggersFeb 29 '12 at 15:56

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:

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.

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).

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.