从详情页返回列表页，应该是回到顶端还是回到原地？

在一个列表页上点击某个项，进入详情页，再从详情页返回列表页，应该是回到顶端还是回到原地?

点击了左侧某个项，右边开始播放，左侧tabs收起，再次打开左侧tabs时，其实也是列表返回后的问题。

应该返回原地，因为…

刚才点进去看某一篇了，现在回来，很可能是想要继续往下看列表。而且，回到原地才最不陌生，在不陌生的页面上继续操作，才最不恐惧。

其实我觉得并不需要太多的说理由，因为原本就该如此。

列表就是一张张文件叠放在一起，每一张露出个标题来，从上往下捋(lǚ)着看，看到哪个标题感兴趣了，就拿出来看看，看完之后，接着往下看列表。

展开、弹出详情使得返回原地看上去更合理

用这些形式展示详情，返回列表后列表保持不动显得更为理所应当。

如果弹出的详情页面更大些，充满整个屏幕，完全挡住列表，要再看到列表，就得点弹出窗口上的叉子，这与跳转到详情页就是一回事儿了。页面内的展开也是类似。这些应该说是更形象的展示方式，比起最原始的跳转页面，更形象了。

这些形式也与普通的跳转到详情页一样，列表保持不动，都要面对一些问题，也正是这些问题才让更多的设计者选择了**新页面，回到页顶。

返回原地要面对的问题：

以前没移动设备，页面主要是PC的网页。返回后把重新载入页面，页面**新了，也置顶了，这样做的好处：

1、可以展示更新了的内容;

2、知道当前位置。页顶的导航展示出了当前是在哪个页面，用户也知道现在是在页面顶端。

如果是返回原地，那这两个好处就没有了，变成需要解决的问题了。

为了这两个好处而**新、置顶，有点儿舍本逐末了。是否返回原地，判断依据应该是：怎么才是用户好理解的，用起来方便的。既然有这样的问题，我们就做出些配套设施直接来解决问题就好了。

配套设施

配套设施一、展示导航

展示出导航，让用户知道返回后回到的是哪个页面。

移动设备上，第一级的页面**用整行的导航，或在屏幕顶端，或在底端。二、三级的页面是有页面标题和返回按钮。移动设备上的产品层级通常不多，又有比较明确的设计规范，基本上，移动设备上的产品，确保返回后的页面展示清楚导航都能做的比较好。

对于PC软件，像上面看到的搜狐影视这样的客户端产品，展示清楚导航基本也没啥问题，内容的列表怎么滚动，导航或在上，或在左侧，不跟着滚动，一直都在。

对于PC网页，就比较悲催了。由于古代网页的技术局限，形成了现在网页的传统，所有内容都是在一整个页面里的，页面往下滚动，导航就滚出去了。不过现 在也越来越多的网页产品不再拘泥于这个局限了，当导航要滚出屏幕时，让导航浮动起来，卡在页面最顶端，比如，淘宝的详情页。这虽然也不见得是最好的形式， 但至少这是个有益的尝试。这个页面需要有导航，而不仅仅是这个页面的首屏需要有导航。

配套设施二、用滚动条展示当前所在位置

设施一是为了展示当前页面在整个产品中的位置，设施二是为了展示清楚当前屏所显示的是此页面中的哪个部分，是页面内的导航。

其实并不需要强调要“用滚动条”，这是具体的表现形式了，要的是展示清楚当前屏在整个页中的位置。不过，貌似除了滚动条似乎也没有什么更好的方式了。

现在移动设备操作系统中，右边的那个条，相比起传统意义上的滚动条，变窄了，也不能操作了，纯粹是为展示当前位置用的了。

IOS上的窄滚动条只在用户滚动列表时才出现，意思是说，你要滚动页面时才**需要了解当前位置，在阅读页面上内容时，并不需要窄滚动条。这个思路挺好 的，对于小屏幕的移动设备，“适时出现”这个设计思路尤其有用。但是在返回列表这个时候，我觉得也还是应该忽现一下子。窄滚动条出现的原则应该是：需要的 时候出现，而不是滚动屏幕时出现。

配套设施三、提供“返回顶端”操作

回到了原地，这原地可能已经是列表很靠下的位置了，要回到顶端，触屏上连续向下翻动也好，pc上连续滚鼠标滚轮也好，都是体力活儿，而且是浪费体力的活儿。所以需要有个返回顶端功能，不过形式倒不必拘泥。

pc上有越来越多的网站给自己的长列表右下角加上“top”按钮了。移动设备上，如果总是在屏幕上贴个“top”按钮就太讨人嫌了，IOS提供了很隐 蔽的top功能：点列表最上面分割线的区域。这也是个很智慧的方式。因为，操作系统是个针对熟手的产品，功能隐晦些，需要些学习成本是可以接受的，学**了 以后，用起来效率很高。

配套设施四、“新信息”提示

以前网页上返回直接就**新页面，更新的内容就**出来了。如果是返回原地，那么，有了新消息，就给及时告诉用户。

用户是老板，面对着排成一列的大批文件，正在逐个文件标题的看，其中一些**抽出来仔细看。这时，又来了几分新文件，作为一位称职的秘书，应该怎么做? 不告诉老板肯定不对;把文件放在文件长列的最前面并把老板直接拉过去，这也不好;应该告诉老板一声：“又来几份新的”如果能更体贴，还可以附加一句：“其 中还有一份是特重要的某某项目的文件。”

称职的秘书就是我们的产品，有新消息时，应该提示，而且得让用户看见，目前的微博，移动设备的版本，**在屏幕底部的导航上显示出个数字，而网页版的只是在列表最上面多顶出来一行提示，只要页面滚下去了，就看不到这个提示了。

配套设施五、跳去“新消息”之前的阅读位置，应该mark

这个功能出现在用户去查看新消息之后，是上一个功能：“新信息”提示的补充。

用户点击了“新信息”的提示，去查看新信息了，看过了最新的之后，很有可能是要回到刚才中断的那个位置继续往下看。如果之前已经滚了好几屏了，那个位置就不那么容易找了。

这个功能是一个典型的为任务而设计的功能，完全是为了这种特定的任务情景而设计的，与产品的结构没什么关系。

之所以**想到这么个功能，源于对任务的罗列，我自己甚至将其成为“任务罗列法”，这个方法是这样的：在完成了产品基本架构设计的基础上，无限详尽的描述所有可能的任务，来检验现有的产品，确保重要任务很顺利，次要任务能达成，没有任务完不成。

补充上以上五个配套设施， “返回原地”基本上就比较ok了。提供这五个个配套设施的基本思路是：

1. 描述当前状况;

2. 提供可行的操作。

设施一、导航，设施二、页面内导航，都是在展示当前状况。设施三、回到顶端，对于提供了可以做的操作。设施四、提示有新信息，即是描述状况同时也提供相应操作。设施五、mark之前的阅读位置，描述的是用户点击了新消息之前的状况，同时提供相应操作。

“返回原地”的适用范围

对于PC、移动设备、网页、APP，“返回到原地”这个设计方案都是适用的，但在时间维度上，却不能无限制的扩大。

如果是昨天睡前**过微博，在一个详情页关闭了微博APP，今天早上起来再打开微博APP，还要保证返回到列表页原地不动，恐怕价值就不大了。

“返回原地”隐含的前提是：刚才从这儿离开的，返回来时，用户应该多少还对位置有点儿印象。

“返回原地”目的是：用户继续浏览列表比较方便，如果昨天看过微博，今天早上起来再打开微博，恐怕“继续阅读”的可能性就很小了。

这里讨论的是从列表离开的情况，如果不是列表页呢?如果是从一个首页，或者其他什么页面，进入某个下一级页面，然后再返回来，是不是也应该返回原地呢?

以列表为研究对象，是从比较简单也最常见的情况入手研究问题。搞清楚了之后，对于更复杂的情况，我们也可以依据这些结论来做判断。

扯远了…

关于“描述当前状况，提供可行的操作”，这里设计配套设施用到了。以前关于按钮应该表状态还是表操作曾经讨论过。对于有开/关两种状态的按钮，比如静 音按钮，播放/暂停按钮，按钮上的图标应该表达怎样的含义?是表达“当前是有声状态”?还是表达“按这个按钮可以静音”?最完整的表现就是应该表现 出：1、当前是什么状态;2、还能做什么操作。

在返回列表这个问题上又用到了这个理解。实际上这是一个具有普遍意义的理解方式，对于一个系统，首先应该展示清楚当前是什么状况，比如：正在下载中， 处于编辑状态，系统故障中…然后还需要根据当前状态提供对应的操作：正在下载，那应该提供中断操作;正在编辑状态中，提供编辑的功能;系统故障中，是不是 可以**新?

关于列表这种形式与现实的映射，这个理解，在这儿是为了辅助理解列表的返回，其实这种理解还有更多的价值，比如：列表与详情页之间的切换形式，列表页之间的切换形式，翻页与向下加载更多的取舍…

关于“用户是老板，产品是秘书”，这是一种对产品的定位，在研发产品的过程中，这种角色定位不仅是对产品整体方向的把握这种抽象层面的指导，对于新消息该怎么提示这种具体设计也有价值。

当然，并不见得所有产品都得是秘书，也许你的产品是位专业的顾问，或者是热情洋溢的主持人。

关于“任务罗列法”，无限详尽的去描述用户在使用这个产品时**是什么样子。虽然我们平时也经常在设计完成后这样过一遍，看看能不能走通，但往往是检验的过于简单。我建议将这些任务的描述写下来，像写小说那样，几百字几千字，写着写着就能发现问题了。

有些产品，结构简单，但却**被反复使用，使用情景很多很复杂，比如：一个下载列表，一个邮件收件箱，对于这样的产品，任务罗列往往比较有用。

原文来自：互联网的一些事