cover

本文将讨论如何通过流程化的交互实现用户目标,并处理好任务相关角色之间的互动方式。

当我们在制定设计方案的时候,可能会经历下面这些:

挖掘需求(正在渴望未被满足的地方)->界定目标(解构需求,定义重度、范围以及可行性)->设计功能(实现目标的方法)->结构化流程(定义控件,布局,页面逻辑)->测试可用性->优化视觉

从设计功能到结构化流程这一部分,是交互过程中主要的产出阶段,我们该如何让生硬的功能,转化为用户可以实现的操作,并最终落地呢? 思考阶段需要清楚的三个内容:

特征

设计最终都是为了人而服务,了解你的目标用户,这类人群的爱好,年龄,性别,教育背景,使用环境都会在设计过程中作为参考。例如搜索功能,老人与小孩可能会更适合语音搜索,而年轻人偏向于关键字,那么更多地优化在搜索联想上。

目标

用户想要做什么?用户的目标不一定是表达出来的,但是表达所传递的内容却会映射出真实的目标。 比如一天室友找你借钥匙,得到钥匙可能并不是室友的最真实的目标,它映射的或许是室友希望能够打开寝室的门,又大概他可能只是想取走落在寝室的某样东西,而他拿东西可能是为了完成另外一件事情。 这种动机和目标可以追溯到很长,那么我们如何确立一个正确的目标?可以依据如果确立的目标完成后,是否能够很好的抚平当前迫切的需求,同时需考虑自己当前所处的角色;如果角色是“我”,那么我借出钥匙就能缓解室友的焦虑,而如果我是一位隔壁室友,帮助他去联系有钥匙的人也能缓解焦虑。 因为深入地了解用户的目标,所以快播的单手模式广受美誉。

方式

当目标被确立了之后,应该思考的是用户该通过哪些操作来实现设计的功能,达到目标。 在流程上,清晰,高效,继承习惯,是个人认为比较重要的三点。

  • 清晰

清晰的设计能够避免元素间的干扰,每一个元素都应该与它在行为中的重要程度匹配,包括视觉上的主次和以及信息呈现的先后顺序。让用户能够直观的找到入口,并执行操作。

  • 高效

整个操作过程都是一个过渡态,用户不是来把玩这些控件的,通过更少的操作,更加快速的完成任务并从操作中脱离出去是尽量去达到的目标。现在的模式中提供了许多了方法。 归类:将复杂的表单中相近的内容归类 切割:对过长的流程切割分步骤进行 隐藏:次要信息的隐藏 默认选择:以及为用户提供默认的选项,从第三方获取公开数据等 但是不应该盲目,保持清晰,脱节的高效“一键完成”并不适用于所有的场景,如果用户不能给了解到自己会得到什么样的结果,留下的困惑会失去对产品本身的信任。

  • 继承习惯

我们总是会通过以往的经验来对事物作出行动,对新事物的认识也是基于先前的认知习惯。就像带圆角的Button来源于工业界的实体键,纸质表单中的Check Box和Radio Button,在数字界面的表单中同样得到了继承,更自然的交互方式扩散性和习得性更好,像是手势和语音交互,就是继承了生活中对实体的行为方式。 而离构建产品更近的,是尊重平台,OS,以及同类产品的交互习惯。像是在PC和Mobile上,横向滑动浏览的模式比较少见,但是在TV上,这种浏览模式被广泛使用。(参考阅读:Designing for the Apple TV)同样的Android和iOS在设计语言上也有很多的差异,在对不同平台设计时,必然要考虑到用户操作习惯上的差异。例如“menu”和“pop”这两个控件上的定义和使用方法。最后要说的是同类产品的交互习惯,可能会产生一些争议,因为这多少会被人诟病为抄袭。当下规模前几的电商网站,导航框架和信息结构也相似很多,但是要去理解背后的动机和成因,和几种可能性方案之间的比较差异。拍照应用多会在拍完后选择滤镜;视频网站也会在播放完成后提供相关视频的入口(说到这,就有很多小广告在右上角加一个假的关闭icon,用户点击后并没有关闭广告,而是点进了广告,这也算是继承了一种习惯,但是糟糕透了);同样是语音搜索的功能,浏览器的激活方式是tap,独立搜索应用多是long press,为什么存在这种差异?分别继承了哪些习惯?将认知上的习惯延伸向更广的区域,更自然,更易于理解。比如QQ在发送图片的时候,可以将图片上滑发送出去,这一个交互方式就点选图片更加流畅。

关联与边界

在刚开始做项目的早期,我常犯的错误就是在做割裂式交互,认为给上原型图,控件布局,标注下button的来源去向,填充内容的规范,就完事了。 单看这一个也没毛病,可用户并不是盯着一个内容转的。他会在整个应用中来回的跳转,犯错,反复操作,成功或失败。过于单薄的交互如果没有覆盖到足够多的场景,会让产品显得乏力,体验欠佳。 注重行为的整体性,交互行为是连续的操作,信息的接收与反馈。当前用户与平台的交换,与其他用户的交换。从发起动作到完成离开的每一步都构想好,才算是比较完整的交互流程。

举一个例子:如果在游戏中,A玩家想要组队,他的流程应该是怎么样的? 可能他会看看周围有没有合适的:

查看附近队伍->申请加入队伍

如果附近没有合适的,可能会不组队,或选择自己发起:

发起组队->邀请玩家

发起组队->接收其他玩家申请

这是A玩家可能需要执行的动作,但在设计的过程中,你需要考虑更多的场景边界,和关联信息的互动。

如果附近队伍很多,是翻页还是滚动加载?

如果附近没有队伍,该不该引导用户去创建队伍?

让用户对列表主动刷新?还是按固定时间刷新?

申请成功了该怎么提示?

申请被拒绝了该怎么提示?允不允许再次申请?加不加限制?

怎么提示有人申请加入队伍?提示呈现的方式是什么样的?

队伍成员已满时该不该自动拒绝?

邀请列表怎么排序?列表中显示哪些内容?

有人邀请了该如何提示?

有人申请了该如何提示?

有人加入后如何提示?

成员离开后的提示?

与队伍相关的其他操作会不会出现干扰?

上面这些列举了很多“提示”相关的问题,给予用户一个正确及时的反馈是一件重要的事情,是希望在设计的时候能够关注到这些场景下,是使用toast,dialog,亦或者action sheet等组件类型都有商榷的地方。将场景尽量的丰富,邀请和被邀的关联角色状态,才可能构建一个清晰的交互。

场景的边界,用户可能会在产品中漫无目的的操作,使用方式可能并不全会按着预想的那样做,虽然这可能会诞生一些有趣的事情,但还是希望产品能够明确自身的作用,做什么与该怎么做。

边界场景是为了让用户处在一个可控,并且可知的环境中。就像当我滑动到了文章列表的末端,显示一条“没有更多了”可以让用户明白继续滑动是无效的,不会有新的文章加载。如果没有这条边界,用户该怎么去辨别是自己滑动位移过小未加载,还是正在加载更多内容呢?

可能边界场景不太容易去体验,但是双11的时候,有朋友特意去观察淘宝天猫京东这些电商的崩溃页和崩溃提示,这也是操作失败的一个边界。边界会将我们弹回到一个可控的地方,比如返回上一页,或者回到首页,确保我们仍在一个安全的环境中。

极限是很多边界场景所处的状态,比如长按发送语音超时。还有全局场景,失去网络连接,未获得权限,操作失败,程序异常(程序异常不算是一个很好的提示,因为用户只会觉得你这个产品真糟糕)等等。

拓展阅读:UX Patterns of the Future: Anticipatory Design

当你考虑的越多,用户就会思考的考少。

(码字到最后自己都晕了,233)

:)

扫描二维码,分享此文章

ShuSQ's Picture
ShuSQ