Where to place the '< Back' link or button?

Question

I am building a simple transactional site with two step process both on web and mobile (responsive). Target users both male & female age from 30-40 relatively tech savvy.

First page is a selection page, where user selects an option they want. Second page is where the recap of the option and to submit.

On the second page, I have a 'back' text link to go back. But do you think it's necessary? These days a lot of people know how to go back to the previous page using browser back button. My only concern is that people would think that using the browser back button won't retain the selection they made.

If to include 'Back' button, where is a good placement? Top left or bottom left? Below the title or above the title "Step 2. Confirm your selection." and why?

Answer 1

If you're talking about mobile apps, the top left is the standard position for both iOS and Android (technically it's the up button on Android, but that's close enough).

If you're talking about a website, there is no standard placement for a back button, as there is a keyboard back button, and so most sites don't bother with a back button.

That said, I would strongly encourage you to place in on the top left if your site uses a left-to-right language as this is conceptually the direction for back, and where most people will look (based on mobile experience). If you have a good reason to have it on the bottom left, that can also work, but you will need to justify this.

As always, you should test this with your users to be sure.

Answer 2

I would propose having two ways to take a "step back" in your website.

Since it's pretty much a short wizard, I would expect each step (except the first obviously) to give me the option to continue ("submit") or step back and revise an earlier choice ("cancel"). When looking for "can I go back", it's logical to look at the bottom of the screen next to the submit button.

In many smartphone apps it's common to have a back button at the top. As John mentioned it's the logical place for a back button since up and to the left are linked to back, down and to the right to forwards. It makes sense in an app like wizard like you seem to be creating.

Having such buttons available inside the viewport, instead of relying on the browser or hardware buttons, would further support the "app-ness" of your website and allow you to implicitly assure your user that no data will be lost.

Answer 3

Repurposing Visual Metaphors can be confusing

People typically follow habits. If something doesn't work as intended, then it can confuse them or pull them off-track.

Web browsers (with the exception of IE in Windows 8 on a desktop) usually offer an intuitive method of backward navigation. Most of that navigation is pretty consistent between browsers by design. There is no need to reproduce that navigation in-page because you're taking up valuable screen real estate.

If you're designing a web app that works in app mode (mobile devices), typically back is on the left for English and forward is on the right. Most Asian languages in my experience work this way too because their interfaces are largely "Americanized" even though they may read from right to left or down the page. App mode allows the browser to act as a standalone app without providing the standard browser buttons. Designing a standalone app the interface should handle any navigation desired and be highly tested.

If you use "cookie trail" or "bread crumb trail" style navigation home > category > page you should not include a back button in that lock-up for two reasons.

1. If you use a real back button, then the people will return to the referring page (might not be on your site, so it needs to account for the referral).
2. Most people expect the cookie trail to show the hierarchy of the pages. If the site has complex unrelated content then this can be useless.

Additionally most input devices provide a physical back button by design (mice, keyboards, track balls, tablets, and multi-touch pads).

For changing their results I would make the button say something to the effect of Edit or Revise this information intuitively near the content being edited. On larger screens if the interface is scalable then the back button may not indicate the ability to edit. Also some websites do not keep user input when people use the browser's back button by design. By making the previous page expire this causes the information to not be stored in the browser's cache (like using the back button on a banking site).

If you're not dealing with sensitive information I would make the site work in both ways so that they can "edit" and use the built-in navigation for their browser or input device.

Answer 4

The most important thing here is to make sure and use « instead of <

;D