在我们浏览很多网站时使用“返回”按钮经常会感到困惑和沮丧，这种不好的体验严重影响了网站的质量，为了设计出更好的返回体验，我们在做
网页设计时就需要考虑这些问题。
可用性测试中没有多少东西会一遍又一遍地出现。其中之一是人们在必须返回上一页时所经历的焦虑。用户通常不太信任浏览器的“返回”按钮，这是有充分理由的。我们都遇到过浏览器的“后退”按钮没有按预期工作的情况，这使我们远离目标，而不是朝着目标前进。例如如果您碰巧处于结帐等多步骤流程中，“返回”按钮通常会将您带到流程的最开始，而不是上一页，您的所有数据都将化为乌有. 有时，我们必须多次重新输入敏感数据，例如信用卡号码，因为出于安全原因无法存储这些数据。更不用说单页应用程序中的路由并不总是按预期工作。
乍一看，“返回”按钮似乎不是什么大问题，是吗？果然，用户广泛依赖浏览器的“返回”按钮。然而，用户在实际按下该按钮之前似乎常常三思而后行。大多数情况下，他们只是害怕丢失他们的数据或他们当前所在页面的状态——这是可以理解的，因为有时并不清楚浏览器会将他们带到哪里。这就是为什么看到人们截取当前页面的屏幕截图或在另一个选项卡中打开同一页面以确保他们的数据（至少对于当前页面）在浏览器中仍然可用以进行复制粘贴的情况并不少见。
当我们在界面中引入叠加层、锚链接、图像库和动态视图时，就会出现严重的问题。例如，如果用户单击文章中的轮播，更改仪表板中的视图或切换定价页面中的状态。“返回”按钮应该将用户带到上一个状态还是上一页？这个问题没有明确的答案，但有一些设计模式比其他设计模式更有效。
研究表明，新视图在视觉上越不同，用户就越有可能将其视为单独的页面。随之而来的是“返回”按钮将用户带到上一个“页面”的期望，即使从技术上讲，它可能并不是一个单独的页面。这适用于过滤和排序后出现的产品列表，用于手风琴式结帐，但也可能有助于锚链接以及扩展和截断的内容- 特别是如果这些部分很长。在这些情况下，将浏览器的“后退”按钮行为与用户的期望相匹配是合理的 - 与History API。
当然我们不想用不必要的状态或页面污染用户的历史记录。当用户点击文章中的图片库时，我们可能不应该将每张图片都添加到用户的历史记录中，因为这会使访问“实际”上一页变得更加困难。最重要的是，轮播的状态很少被视为“不同的页面”。只要页面没有显着变化，我们就应该避免将状态添加到用户的历史堆栈中。这适用于复选框、下拉菜单、视图切换器、切换和动态注入部分，以及它们修改同一页面上的内容。最后当用户可能通过“返回”而丢失数据时，例如从覆盖返回，提示用户确认他们的操作并通知他们可能会丢失一些数据绝对是一个好主意。
即使我们已经调整了对“返回”按钮行为的预期，一些用户仍然会担心“返回”按钮是否真的按预期工作。解决此问题的一个好方法是在您的界面中添加一个自定义的、特定于表单的“返回”组件。
用户如何看待浏览器的本机按钮和很好地隐藏在界面某处的自定义“后退”按钮存在重大差异。虽然浏览器按钮的行为并不总是很明显，但用户确实希望网站或应用程序中的专用自定义按钮能够提供“正确的行为” 。因此，用户也更加信任自定义按钮，并且使用它们时的疑虑更少。
