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:
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