手游UI交互动作设计研究：点击、滑动与拖拽

好的交互设计方案究竟应该是怎样的？

交互动作的直觉形成于『人与实物』的互动中。

在物理世界：接触物体一定有感觉。

在游戏里：与物体交互一定可以看到变化。

本文从交互动作入手探讨移动游戏中关于交互设计方案和理念。

一 点击


首先确认这篇文章的大前提：我们设计游戏里的交互动作，无论是否强调沉浸感，都并没有在故意给用户提高难度（QTE、射击瞄准这一类操作难度是来源于关卡而不是交互）。那么，如何选出不属于hard模式的交互动作？

重要但基础的事情说一遍就可以了——

不能反直觉。

那么下一个问题，怎么做才能『不反直觉』？

狸花绝不抄书，简单直接地写出来，用户的直觉是哪里来的——

交互动作的直觉形成于『人与实物』的互动中。

重要喵？基础喵？需要三遍喵？

/*不按顺序*/一个一个来，首先是点击动作，接下来是滑动……


最基础最经典的动作，来源于触摸真实物体的本能行为。

……诶好像发现了猫玩Fruit Ninja的理论支持。


这里暂时只写关于触摸屏的点击，PC端的鼠标单双击晚点再说。

在我们真实的物理世界中，想『打开』一个物体，首先要接触到它，所以我们对于UI中的『按钮』——那些看起来像是可以『打开新页面』的物体，第一反应也会是摸它一下。点击是个不需要教学的动作，即使是在新手引导环节，我们也只需要告诉用户『点哪里』，以及把按钮做得有够像是一个按钮。

吹一波触摸屏技术的划时代意义，它实现了点击与物体最直接的映射。

建立了『点击按钮=触摸物体』的认知之后，我们可以看到这会带给用户什么样的预期——

在物理世界：摸到物体一定有感觉。

在游戏里：点击按钮一定可以看到变化。

于是出现了『按钮状态』这个概念，就是常见的Normal、Hover、Pressed、Disable四种状态。

交互视角下，以这个规则响应点击的都是按钮～

卡牌、道具、你们的美少女立绘都是一样的喵！


有的版本里，取代Hover的是Highlight，但狸花认为Highlight是用于吸引用户注意力的视觉表现，不属于按钮状态。/*再说PC端也可以有Highlight，数量是不可能对齐的强迫症退散*/

这里面Normal没什么歧义，Hover在触摸屏不存在（如果我讲到PC端会写它的），Pressed是手指点下去的那个瞬间，通常会做色彩变化或者缩放动画。

这个动画存在感微妙/*世间事物大抵如此*/，它很少被注意到，但没有就觉得哪里都不对。

游戏界面有时候物体比较多，就会出现一些很小的按钮，点击瞬间完全被手指遮挡，这个有必要时可以稍微延长动画到点击过后（手指离开按钮）才结束，来提醒用户『你点的是这里！』

于是狸花想说的重点是Disable状态，通常翻译为不可点击/禁止——

讲真我们做得到禁止用户点击它么？

准确地说，Disable实际表达的是『点击也不会有反应』状态。

这个状态的存在可以减少用户点击按钮却得不到理想反应的次数。我们来喵一眼最经典的禁止状态应用场景：


再喵一眼游戏里常见的一种情景：


前者是线性的，填完上一条、看向下一条、填完最后一条、看到按钮——点它，完美。

而后者呢？

现在是几点——去看看系统时间，有组队吗——看看队伍面板，我多少级——看看人物的等级……用户取得对应信息的位置是分散的。

这就意味着如果我们在这里放了一个禁止状态的按钮，用户不会去点它，而是去一一对照排查我为什么不能点它。

那么不如给它一个Normal的按钮，在被点击以后，告知用户不符合要求的是哪一条。


小结：如果上面案例只有时间和等级两个限制，用户满足了等级之后，只看按钮状态就能意识到是否在开放时间，灰色的按钮+提示语当然也是可以的。不过，灰色按钮给用户的普遍认知是不用去点，提示语被触发的概率也会下降。

二 滑动


滑动屏幕，对应的物理世界的行为是挪移物体。此处是指推拉平移，『拿起来搬到别的地方去』的更接近拖拽。

2.1滑动的方向

动作本身有横竖两种，细分就是上下左右四个方向。按照物理世界里，推拉物体的习惯来说，如果我想看到一屏以下的内容，那就要把页面向上滚，手指也就要向上滑动。


鼠标和手指在用户看来是明确地两个物体，适用不同的心智模型，一般不会搞错——但狸花曾经有一个支持触摸板手势的笔记本电脑，截止它被刷系统之后手势失效，狸花都记不住它的滚动是按照手指还是鼠标方向来的……（鉴于不同的心智模型，如果是狸花来做，会选择同步触摸屏手指的动作习惯）

2.2滑动区域的数量

从前，有一只策划，想加多部分系统邮件的奖励物品。原稿长这样：


然后狸花认为一个弹窗（邮件页面是一个点击外围可以关闭的层）出现两个滑动区域，并且一横一竖，用户需要识别区域并改变动作。同时，横屏小范围的左右滑动不太适合单手控制。邮件系统的功能性大于沉浸感，动作最好简化——于是做了这样：


如果页面是全屏的，上文的改动可以不必做，因为我们通常会把整个屏幕的滑动视作不需要关注『区域』的全局手势，内心计数自动-1。如果是上下滚屏，内嵌左右滑动区域也足够容易识别——而内嵌上下滑动就比较微妙。这取决于我们对于无形边界的脑补。


此外，由于多数用户习惯右手单手持机，并且我们的阅读顺序是左到右上到下，使用向上和向左的滑动，稍微优于向下和向右。

2.3稍微有点奇葩的分类讨论——连续/断开的动作和页面。

连续的滑动页面就像是在拉开的抽屉里翻东西，或者扯卷纸（破案了，狸花真的是猫）。手指的动作当然还是有次数的，但物体的移动带有惯性，不会立刻停止。手指滑动的速度和距离会影响物体，可以不用动很多次就飞快地滑过大段，中间的物体可能看不清楚。适合粗略地翻动列表获取信息，或者找足够明显的物体。


面对正在移动的物体，我们通常会在屏幕上按住（或者是反向短暂地滑动一下）来让它停下来。这也是源于物理世界里让实物停止运动的那个反方向的力。


手机游戏里使用物品为什么要多一步，而端游不用？（原因有很多，比如手机上没有悬停显示物品描述的功能）……这里狸花想说的是，需要预防的『误触』不只是点错位置，也有像『用来停止滑动的点击动作』这样动机上的。


同理，kindle 的手机APP不支持上下滚屏，和它点击有字的任意位置都会退出阅读，会不会有联系？/*事实上，点击书页退出阅读本身就容易误触，用户体验一言难尽……*/

断开的滑动行为映射物理世界的翻页，是清晰的『手指动一下、页面动一下』的动作。不会因为惯性而一下翻过多页，手指滑动的距离也不影响物体移动的距离。动作的速度会影响物体移动的速度，不过仅限于两页之间。

适用于我们希望用户看清楚每页内容的滑动区域（比如轮播宣传图什么的）。以及新页面的进入/退出。

用于新页面进退场时请保持方向一致……左滑打开对应右滑关闭这样……我们翻书页也是向左翻过来就向右翻回去的对吧。


小结：不处于列表的顶端或者底端时，用户没有截然分明的『当前这个、上/下一个』的意识。如果是循环列表并且没有提示，可能狸花会在很多圈之后才发现并停下动作。


三 拖拽


拖拽对应的真实动作就是拖拽，就是『把物体从这里拿到那里』。

多么简单直接的心智模型……

所以狸花有一个未解之谜……为什么拖拽动作在游戏交互里至今没有普遍使用。用来换卡牌、调整编队、拼字拼图……很多场景都是合适的，尤其在需要按顺序的情况下，拖拽效果拔群。有人说因为完成拖拽需要的手指移动时间长过点击，相比点击更麻烦，说得也对。但是在表达『互换』行为的时候，使用拖拽比点击更贴合直觉，比如这个——


在PC端有一种做法，鼠标点一下拿起物体，物体跟随鼠标移动，再点一下放下物体。这就是一个被简化的，不需要保持按下状态的拖拽。然而触摸屏没有悬停。


只使用点击要这样做，涉及到的状态变化多过拖拽，狸花不认为它更好用。

3.1拖拽的方向

拖拽不一定是上下左右移动的，我们把它分类为有终点的拖拽和向外拖拽就可以了。


有终点的拖拽可以用于表达挑选、取回，或者『多个物体合成一个』的情景，拖拽终点有重要的意义。同时，拖拽的距离和方向是被限定的。

PS：不建议这种拖拽支持双向操作……

向外拖拽可以用于丢弃物品，经典案例即『拖拽删除』——尤其是『拖拽到面板之外删除』。这里的拖拽终点是一个范围，没有明确的落点，拖拽距离会成为一个取值范围（面板外到屏幕的极限），方向也不是一定的。


小结：想知道为什么现在通用的是『长按-拖拽删除』……拖拽到删除区域在手机屏幕上并不容易误触，即使删除属于重要操作，二次确认也足够反悔了？毕竟长按本身比拖拽还要不常见……

3.2拖拽的距离

一般游戏用户遇到需要拖拽的界面，会是一手持机一手拖拽的。也有少数竖屏游戏里，用户会单手拖拽。但无论哪种都是距离越长，物体意外脱手的概率越大。


所以请尽量减短拖拽的距离/*也不要矫枉过正到几乎相连，拖拽终点会被手指挡住的*/，尤其是不要让起点和终点不在同一屏……拖拽滚屏的体验可以在手机上拖动app模拟一下，手指在设备边缘真的很容易滑脱。

拖拽终点的实际区域最好略大于视觉效果，在物体进入终点区域后自动放到正确的位置……幼年狸花就是用这个标准来筛选可以玩的拼图游戏的……

最后，拖拽路径尽量一一对应，画出来呈现平行线段组，或者收于一点。不要在起终点的路径上放别的终点。


综上所述L形界面就别拖拽了！

3.3拖拽衍生物：模拟摇杆

模拟摇杆真是个伟大的发明……虽然它长得完全不像方向键但是意外地很好懂！……关于它的心智模型来源于手柄这一点狸花存疑，用过手柄的人数至今还少于玩手游的吧……

我们与模拟摇杆交互的动作是一种连续的拖拽。与之前的所有拖拽相比，区别在于物体的位置和手指的位置不同步，这个映射关系可以大概描述为，拖拽的方向=物体移动的方向，拖拽的时间×物体速度=物体移动的距离。

然后狸花发现，拖拽的距离在这里消失了。没有用上。

通过狸花对自己和其他用户的观察，在需要人物快速逃离某个地点时，大家的动作都很相似——用力拖拽摇杆，甚至连手机一起向目标方向倾斜。此时都会拖出远大于以往的距离。摇杆的中心点相对四个方向边缘的距离，是有极限取值范围的，也就是说用户能够拖拽的距离，在现有的动作习惯下是一个范围。


那么摇杆的拖拽距离有无可能作为系数加入物体移动的映射？狸花期待答案。

小结：模拟摇杆可以支持360度的方向变化，我们也习惯了用它控制人物转向，那如果用它来控制建筑物旋转，会否优于常见的90度转向按钮？

下篇将介绍缩放、书写、旋转等交互动作设计方案。


作者：狸花踏雪
专栏地址：https://zhuanlan.zhihu.com/p/89879263