The context is a single page webapp with a section that allows users to vote on content. The votable content is loaded via ajax.

The webapp itself implements the back button using the HTML5 history api. But since it is preferable to not have people vote multiple times on the same item, the back functionality is not implemented for the content voting part. To explain better, clicking the back button while on a voting page will not take the user back to the previous votable content, but rather to whatever other page (like contact/submit/profile/etc.) the user was on before coming to the voting part.

Does this seem reasonable? Is there a better way of going about this?

Edit: clarification with example flow.

Suppose the user views the webapp's pages in the following sequence: Home > About > Contact us > Voting page (item 1) > Voting page (item 2) > Voting page (item 3)

Now when the user clicks on Back while they're on Voting page (item 3) will take the user back to the Contact us page, and not to Voting page (item 2).

My dilemma is that whether the back button should take back to the last votable item (Voting page (item 2)), or to the last item before the user got on to the voting screen (Contact us).

  • 3
    A general tip that I have learnt throughout the years is that as soon as you change standards that people are really used to (like having the back button going back to previous page) leads to lots of user experience issues. What if the user, for example, accidentally ends up on the voting page and wants to return to the previous page? It sounds like you should have something on the voting page that detects if the user has voted before, instead of turning off the back button... May 16, 2018 at 7:45
  • Hi Henrik, actually that is what it does presently - clicking back will take the user to the previous "page" (e.g. about/contact/profile/etc.) but NOT to the previous voting item. So it is exactly as you say: if someone lands on the voting page by mistake, they can just click back. But one cannot click back to the previous voting item.. Is this still suboptimal?
    – ahron
    May 16, 2018 at 17:01
  • @HenrikEkblom Just edited the question with a sample flow for sake of clarity.
    – ahron
    May 16, 2018 at 17:11
  • How can you change your mind and modify a vote? I assume this is not supported May 16, 2018 at 17:31
  • Of course not. So, in case it is designed such that the back button takes back to the previous votable item, the voting buttons would have to be deactivated via javascript. My dilemma is that whether the back button should take back to the last votable item, or to the last item before the user got on to the voting screen. What do you think?
    – ahron
    May 17, 2018 at 2:53

4 Answers 4


What you ask about is a really great question.

My guess would be to take the user back to the thing they were on before they started the voting process.

The only real way to know is to perform a quick usability test.

Alternatively, you could try providing two links and let the users decide.

  1. “Back to ______” <—- where they were before the voting process
  2. “Go to Home”

Or even, if it’s of interest and available:

“See a list of all things you’ve voted on”


You could use a Progress Tracker for the voting page. This way, the user wouldn't feel like each vote is on a different page, and the back button could still have the current behaviour. Also, you could show the user what items he already voted for.


You should consider integrating databases in your application to capture the fact that the user has voted. The database record will initially say that this user has not yet voted. Then they vote and it should check that they have not voted yet. Once you know the user has voted and you store this information in a database table, they are always allowed to go back to the previous page but if they try to vote again your application should be smart enough to check the database first and see that they have already voted and tell them this fact.

Writing good software is as much about checking things first and designing the software correctly as anything else.

  1. Bad UX. Sending users to any page other than previously displayed is a bad UX.

  2. Not a solution. Suppose you display something different on the "history back". This will not prevent users from voting many times. If smb. wants to, he will to to the beginning of the voting via "Home > About > Contact us" and will vote again, as man time as he wants. Manipulating the history does not prevent from multiple voting.

  3. Semi solution. Use Cookies to indicate if this user has voted. Many users are not aware of the web basics, they don't clean up cookies for days. Such users will not search for a particular cookie to delete it and to vote again. Such approach does not prevent a little more experienced users from cleaning up cookies and voting again. But still it is better than manipulating the history.

  4. Reliable solution. Allow voting only for users that are logged in. On your server store the indicator if the particular user has voted. Some users may have more than a single account. But creating each account (and first creating a new email account at some email provider) consumes normally much time and can hardly be automated. So you can consider the amount of users with multiple accounts as very small and not important.

Your Answer

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

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