6

I'm designing a kiosk app, we have 2 navigation elements; 1 button for the main menu and 1 for 'back'.

So my question is: When should we show the back button?

For example, after selecting a menu option form the main menu, should the 1st screen have a back button? as we already have a persistent Main menu button that will take them back.

I feel like we should have the back button be ALMOST persistent and suppress only on confirmation pages and the like, where the user cant go back. Displaying it as much as possible will let the user use it like a back button in their browser (Even if it takes them to the same place as the menu button)

enter image description here

enter image description here

Improve this question

3 Answers 3

Reset to default
1

In our experience the best UX improvement we ever made to our kiosk software was putting the "back" button in the same place all the time. For us, the main menu lists buttons which each link to a "home screen" for a given module. The home screens don't contain back buttons but they do contain the main menu button. The advantage of that is that the user can advance as far as they like in the UI within the module, and to go back to the home screen from anywhere they can frantically mash at the "Go Back" button. That effectively gives them a way to return at any time to either the main menu or the module home screen.

As an aside: your placement of the Main Menu and Previous buttons are very likely to cause you issues on PCT displays (as are fairly common on kiosks), since display edges are generally poorly calibrated. Many kiosk touch technologies make the edges of a screen problematic (if not because of the actual touch responsiveness as in PCT displays, then due to obtrusive bezels as in many dual-point infrared panels).

Improve this answer
2

I agree with you that you should have a back button available at all times because without a doubt users will make mistakes. If you plan on not having a back button on your confirm page, I would have a button available to go back to the form or whatever they are filling out. Here's an example why you would want that:

User fills out the form
User then moves on to confirmation page
"Wait I never wanted to order that item! I need to go back and change that."
"Why can't I go back?!?"
User then cancels the form and walks away frustrated

That would be the worst case scenario but it will happen.

If I am misinterpreting your question let me know, because a "confirm" page is something that could mean a lot of different things.

Improve this answer
2
  • So the kiosk is kind of transaction based, so you wont be able to go back and correct it afterwards
    – user15564
    Jun 15, 2012 at 14:48
  • 1
    So will the confirm page be a summary of what your transaction was? Or will it be a summary of everything you have just done and then you can submit it? If it's the first one then I agree with not having a "back button", but if it is the second one then I would still incorporate a "back" option.
    – PL3X
    Jun 15, 2012 at 15:06
1

I would have the back button. It establishes the navigation pattern. It is a familiar term and would also be easy to find quickly in that location. i.e. Not too far away from where their focus would have been when making the original interaction.

The Main menu button is slightly different in that it will return you to the main menu from anywhere.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.