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

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

00221HF2-0

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

返回到列表时,列表不应刷新、页面不应回到顶端,应该是返回原地,回到刚才离开的那个位置。

对于PC的网页,这个问题并不典型,因为,新链接是在原窗口打开还是在新窗口中打开,这都还没个定论,如果是在新窗口中打开,也就不存在返回列表页的情况了。

现在移动设备上,尤其是手机这么小的屏幕上,无节制的打开新窗口肯定不是什么好事儿,是得在同一个窗口里打开详情页了,那么,从详情页返回列表后的问题也就更明显了。

PC网页、移动设备APP、软件…应该说,在所有数字产品中几乎都会遇到这个问题。

像是这个客户端:

00221H091-1

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

应该返回原地,因为…

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

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

00221Kb4-2

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

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

00221HD8-3

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

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

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

返回原地要面对的问题:

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

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

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

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

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

配套设施

配套设施一、展示导航

00221JG0-4

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

00221I627-5

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

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

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

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

00221K504-6

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

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

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

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

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

00221M053-7

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

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

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

00221G403-8

 

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

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

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

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

00221I449-9

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

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

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

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

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

1. 描述当前状况;

2. 提供可行的操作。

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

“返回原地”的适用范围

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

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

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

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

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

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

扯远了…

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

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

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

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

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

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

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

 

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

您的赞赏,是对我创作的最大鼓励。

评论( 1

登录后参与评论
  1. 文章的尾部说了这个方法跟我的想法一致,我觉得其实做产品就是讲故事,怎么样把一个故事讲得好听就得看讲故事的人水平怎么样了。

    回复
加载中