专栏名称: 从零到零
重拾黑客精神,重构心智代码,升级创作工具。自黑党欢迎你!
目录
相关文章推荐
51好读  ›  专栏  ›  从零到零

数字产品设计与心理学24 - 别让我运动

从零到零  · 公众号  ·  · 2021-03-23 19:42

正文

请到「今天看啥」查看全文


路径偏好和设备惯性

在厨房里,一个人正在做饭。他抓起放在案板上的勺子搅拌鸡蛋,然后用同一把勺子在锅中翻炒。你可能会觉得奇怪,明明挂在墙上的锅铲是更好的工具,但他为什么还要继续用勺子呢?🍳

在花园里,一个园丁正在种花。他用小铲子挖好洞,看到四周有一些杂草,就顺便一起清理掉。但是他没有去拿除草专用的锄头,而是继续用手上那把小铲子。⛏

你大概也有类似的经历,比如正在看一本书,这时快递在敲门了,你想也没想,把手边的充电器塞到书页中当做书签,然后起身去开门。

这些现象反映了人们偏好熟悉的路径,总是倾向于选择最省力的方式。这些「力」既包括会产生认知负荷的心理操作,也包括需要执行实际动作的物理操作。如果人们已经形成了一定的操作习惯和路径,这时候出现一个新的方式,即便它效果更优,人们也会高估它的使用成本,最后还是维持原样。更何况,很多时候可能根本没有发现或看不见替代方法。

探索新路径时,注意力和短时记忆要承受很大的压力。人们知道自己的精力有限,尤其是在有时间压力的情况下,会采用熟悉的路径,减少意外发生的可能。就像在一次可用性测试中,一位测试者在完成任务时对研究人员说 [1]

我赶时间,所以我走了远路。

他知道多半有更高效的方法来做一件事,但他也清楚找到捷径需要花时间和动脑子,这些成本他并不愿意承担。

在使用数字产品尤其是多个设备的时候,也容易产生路径依赖:即使其他设备可能更适合手头的工作,人们仍会继续使用当前的设备,我们可以把这种现象称为设备惯性。

比如,我坐在上沙发上看书的时候,想起之前做过的一些研究,现在需要查找更多资料并做一些笔记。这些事情听起来更适合在电脑上完成,但是我并不想起身走到电脑前,打开电脑,找到之前的资料,然后打开浏览器搜索,再把笔记用键盘敲下来。这一连串的动作只是模糊而快速地在头脑中一闪而过,我已经觉得很费力了,心想还是算了吧——就用放在旁边的手机简单记一下要点就好。

产生设备惯性的主要原因,是 感知到的成本比感知到的收益更高 。吝啬的大脑可不会随便做亏本的买卖。一旦我们学会了用某种方法做某事,就很可能会继续这么做,而不再去找更有效的方法。就算知道有更好的方法时,也还是会用老方法,因为它熟悉而顺手,而且最重要的是:不需要动脑子。使用数字产品时,不用动脑很重要,人们甚至愿意为了少动脑而多做一些操作。

让选择和拖动更轻松

在使用电脑和手机界面时,选中目标对象(例如播放按钮、图片、设置中的选项)是最常见的动作。如何让这些高频的操作更轻松,是设计师一直在努力做的事情。而费茨定律揭示了这背后的规律。

费茨定律由心理学家 Paul Fitts 提出 [2] ,目的是为在电脑屏幕上点击目标对象的行为建立模型,它描述了从当前位置移动到目标位置所需要的时间。

- MT:移动时间 Movement Time
- a:常数
- b:斜率,受使用设备等因素影响
- D:与目标之间的距离
- W:目标对象的宽度

根据费茨定律,运动时间与距离成正比,与目标对象的宽度成反比。为了保持准确,运动时间会随着两个因素而增加:运动距离的增加,或目标宽度的减少。费茨定律在许多情况下可以准确预测运动时间。我们也可以据此优化界面的设计。

在电脑中点击鼠标右键,右键菜单就出现在鼠标所在的位置,这样可以减少鼠标移动的距离 D。

在手机上输入文字时,想要改变光标的位置,是非常痛苦的操作。因为这个时候的目标操作对象,是文字之间的空隙,它的宽度 W 特别小。豆瓣 App 编辑笔记的界面是这样做的:移动光标位置时,光标会放大,一定程度上弥补了目标对象宽度太小造成的操作困难。

在界面上拖动和释放对象,也是一个比较费力的操作。这时候可以人为扩大目标区域的宽度 W 来减少运动时间。比如往 Gmail 写信界面拖动文件上传附件时,会出现占满整个正文区域的虚线框,可以在这个区域内释放鼠标,结束拖动操作。

救救菜单

数字产品现在能做的事情越来越多,但是功能多了,菜单也就变得复杂。一级菜单下面有二级菜单,二级菜单下面有三级和四级……多级菜单是交互设计的噩梦之一。为什么这么说呢?下面介绍的转向定律会告诉你答案。

转向定律(Steering law)是费茨定律的一个延展,它可以预测引导指针(如鼠标光标)通过有边界的路径(如菜单、滚动条或滑块)所需要的时间 [3]

- T:整体移动时间
- a 和 b:常数
- A:路径的长度
- W:路径的宽度

即,移动时间取决于有边界路径的长度和宽度。路径越长、越窄,所需要时间就越多。

转向定律一个典型应用是分层下拉菜单。用鼠标指向菜单中的项目,子菜单会在悬停时打开。如果用户将光标移动到菜单区域外,菜单就会消失。为了避免误操作,一般要让路径宽一些。比如,在下图 macOS 应用的菜单中,从选项 Find 移动到子菜单的路径很狭窄,这个操作颇有难度。

打开子菜单时,你可能会尝试往对角线移动,毕竟两点之间直线最短。但这样做时,鼠标会越过 Spelling and Grammar 的区域,Find 的子菜单不见了,你不小心打开了 Spelling and Grammar 的子菜单。一切又要重头来过。这个过程令人倍感挫折。

除了下拉分层菜单,常见的引导指针类的交互 UI 元素还包括:带参数的滑块、滚动条、视频进度条、可以拖动的游戏元素等等。在移动这类 UI 元素时,很容易超出边界,需要在设计时考虑如何处理这些错误,避免出现指针移出区域时操作就中断的情况。YouTube 视频底部的进度条设计很好遵从了转向法则。

如果鼠标没有移入进度条区域,进度条的高度很小。鼠标移入后,进度条高度增大,当前位置的圆形手柄也变大,这样鼠标可以在更宽松的边界路径中拖动,操作会显得容易一些。不过,也只是容易一些,我敢打赌,当你想要拖动进度条到某个具体位置时,你会下意识地脑袋和脖子都往前伸,好让眼睛更集中地聚焦在进度条手柄上面,以提高鼠标操作的准确度。

为什么人们难以沿一条直线控制光标呢?这与人的生理特征有关:手肘和手腕带动手部的运动时,划出的轨迹更接近一条弧线,而不是直线。让手沿着一条长长的直线移动很困难,动作越长,出错的机会就越大。这些操作还会受到操作设备和操作环境的影响,例如移动用户在户外使用设备时,容易会受到颠簸和抖动的影响,手不稳的老年人和残疾人更是如此。

用转向定律改进菜单和滑块设计

下拉菜单应尽量简短,这样可以减少在狭窄路径中运动的时间和难度,同时也减少了视觉搜索的时间。最好不要使用分层菜单,尤其是深度超过两层的分层菜单。如果必须使用,可以在鼠标悬停时,等待一定时间延迟再显示子菜单,并且增大菜单项的高度,这样用户操作时就有一些回旋的空间,不至于因为一点偏差就弹出了不想要的子菜单。更重要的是,要好好权衡垂直和水平路径的宽度:

  • 垂直路径要短,但这意味着每一个选项的高度都会减小,这会让水平路径变得狭窄。
  • 垂直路径也必须宽,但这会导致从主菜单到相应子菜单的水平路径较长。

三维软件 Blender 的操作菜单选项非常多。如果一级菜单宽度较大,那么向下移动和选择时会比较容易。但是会增加水平路径的长度,进入子菜单时就会出现更多错误。如果菜单选项的高度较大,水平路径就比较宽松,但是菜单就需要占用更多显示空间,在菜单中垂直移动时也需要花费更多时间。所以 Blender 提供了强大的右键菜单、快捷键和命令搜索,来弥补功能菜单的不足。

另外,要尽可能避免菜单层级断裂的情况,这样容易误操作。

下拉菜单的问题很多,现在的网站导航设计,尤其是项目层级多而复杂的导航,都使用整幅菜单来替代下拉(多级)菜单。这种菜单的特点是展示区域固定,鼠标可以自由移动而不会出错。这个时候,转向定律就不再是问题,而是要重新考虑费茨定律,让目标选项足够大,容易选择。

阿里云网站的导航菜单

其他涉及路径转向任务的 UI 元素,如滑块、滚动条和视频进度条等,用户也很难精确控制,需要额外的辅助控件来提高操作准确性。例如,使用滑块来选择参数值时,先用滑块确定大概的范围,然后提供一个精细控件(例如带有步进按钮的数字输入框)来选择更精确的数值。同时,允许用户点击滑块上的任意位置,而不是必需点击然后拖动。

总结一下,转向法则指出, 狭长的边界路径比短而宽的路径更难操作 。下拉式菜单、分层菜单、滑块和其他沿路径操作的 UI 元素,应尽可能设计得宽而短。当然,最好是不要出现这些操作,可以用整幅菜单或其他控件来替代。


参考资料

[1]

Johnson, J. (2013). *Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Guidelines.: Elsevier.

[2]

Fitts, P. M. (1954). The information capacity of the human motor system in controlling the amplitude of movement.: Journal_of_Experimental_Psychology,47(6),381–391.

[3]

Accot, J., & Zhai, S. (1997). Beyond Fitts’ law: Models for trajectory-based HCI tasks.: Proceedings_of_the_ACM_SIGCHI_Conference_on_Human_Factors_in_Computing_Systems,295–302.








请到「今天看啥」查看全文