In a backoffice application should I implement and provide to the users a back button or I should let the user to use the browser back button?
The application is not mobile, it's mainly a web application thinked to be used on a desktop environment
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this communityIn a backoffice application should I implement and provide to the users a back button or I should let the user to use the browser back button?
The application is not mobile, it's mainly a web application thinked to be used on a desktop environment
If users often use the browser back button to move back to the previous screen, then you have a case for providing an integrated back button in your application. Put it in an easily accessible and logical location. If they don't, don't bother.
...point is, let user testing decide.
Write a list of common objectives. Round up a few users and ask them to accomplish the objectives. Watch and make notes how they do that, what works, and what they struggle with. Find solutions for what they struggle with. Look for ways to reduce user actions...clicks and such. Further improve what works. Test again...
Question from comment:
...if users often use browser back button, why I should provide them another button with the same behaviour of the original one?
Simply put, you can design it in such a way that it provides an improved user experience.
Yes, the back button works, and is well understood. However it is not part of your application nor its procedural flow. Rather than users focusing on a single tool, a single process, to get the job done, they need two, your application and the browser. Also its labeling, location, size, etc., are generalized, i.e., not specific to the task at hand.
By integrating it into your application you can now customize the mechanism precisely to the exact process—when and where it becomes available, where it goes back to, how it's labeled, colored, sized, provide help options...
By designing the ability to "go back" into your application's procedural flow you are maintaining user focus on the process, on your application.
Know your audience.
Make some interviews or online survey to understand their behaviour. So you will know if your users will use the browser back button or the app back button or if they doing it in the other way.
You can also make user testing with the back button in the interface, define tasks that require to go back and see how they are going backwards.
Generally, in web applications most people use browser back button or backspace to go back. If it is a desktop application (not based on browser) - basically a .exe file that the end user has to download and run in order to access the app, then you might need to add it.
Check out what other apps the clients are using, and whether those apps have a separate back button. Also check out the competitors of the app. What's their IA like? Do any of them have a back button? You'll get an idea. I don't think there's a need for extensive user testing unless this is a pain point for the user or it gets in the way of user tasks. Its better to follow industry standards.
Having said that, putting in breadcrumbs to ease navigation is a good practice.