阅读 752

微交互 (第三章 - 规则) 上

仅仅为了不同而不同很少能做好,

而做的更好通常才会让人觉得不同。

Things which are different in order simply to be different are seldom better,

but that which is made to be better is almost always different.

- Dieter Rams


辽北第一狠人范德彪说过,万事要按套路来,要不然就会被套路。

《微交互》第三章,开篇就把苹果OS系统曾经的一个微交互规则拿出来遛了一圈。

当年苹果的OS X Lion版本,把“另存为”的功能给删掉了,因为苹果觉得自己的“自动保存”已经很完美了。

后来迫于舆论压力,又偷偷给加上了,因为用户不适用这个规则。

但是,作为科技创新领域的带头大哥,他怎么可能就这么原封不动的恢复这个功能。他家这个“另存为”保存的时候,顺带着连原始文件也帮你更新保存了。

而此刻,被苹果彻底整懵圈的用户,只能受伤的说出这句话:




规则,是你跟用户之间的君子协定。

这里提到一个技巧:在设计时,你设计师自己先写出或画出这套规则,如果你都整不明白,用户就更难建立它的思维模型了。(我觉得这里应该指的是心理模型(mental model))

比如说,使用微信/支付宝付款,需要输入密码时,弹出的键盘是纯数字键盘。


设计规则

想象一个场景:你要用手机给老王转账,手机需要你输入支付密码。

这个场景有设计规则时必要的两个阶段

  1. 确定目标(完成转账)
  2. 设计具体规则(输入支付密码)
在设计时怎么确定目标呢?首先,这个目标容易理解(你要给老王转账)。其次,目标能够完成(你知道账户有钱,知道密码就可以转账)。


那如具体规则应该如何设计,要考虑很多种情况,比如:

  • 如何响应被激活的触发器(点击图标时,会发生什么?)
  • 交互的时候可以进行什么操作(下载的过程中,可以取消下载)
  • 结束时会发生什么(下载完成时,会发出声音)
……


知道了设计规则的流程,那么接着就是设计规则的方法论了:


生成规则

就像画画一样,先框架后细节。

设计规则也是一样,一开始把你想到的规则大体记下来。

举个例子:

设想一个音乐播放器的例子,我们需要一个清晰可完成的目标:成功播放喜欢的音乐

在草图1阶段(左图),做一个规则判断:用户来到页面是否要继续上次的音乐?就这么简单,然后针对规则做出解决方案,最后的目标是“用户成功播放喜欢的音乐”。

在草图2阶段(右图),在之前1的基础上,细化设计,规则也变得越来越多,越来越复杂。当然,这个草图中有很缺失,也有错误,需要修缮、增删。这些设计会让用户越来越接近最终的目标。


动词与名词

目前为止,规则也只是恰巧写在纸上,不够清晰。书中在这时献出一技,觉得很有用:

动词=用户行动=交互目标,名词=操作对象=解决方案。

比如:从我的歌单可以播放喜爱的音乐。动词=播放喜爱的音乐,名词=我的歌单。

再来:通过Siri订一张机票。动词=订一张机票,名词=Siri。

不要想太多,先把规则化繁为简的写下来,然后看着这句话,有动词目标吗?有名词对象吗?都有?好的,可以下一步了。


哦,不要想得太多,

噢,不要想得太多。

姑娘我能让你快乐

—— 杭天 《不要想得太多》


让姑娘快乐不仅仅是找到动词和名词,姑娘最高兴的是你这个交互规则里有很多个动词和很少的名词。比如:通过小众点评订一个密西西比刘哥土味餐厅,选择范围不超过富豪酒店50米,8:00开始用餐。你看看这动词多到能让姑娘乐的飞起。


屏幕与状态

朋友们,还记得第一章提到的那个地铁售卡机吗?那个一屏只问一个问题的超牛逼售卡机。

“一屏一个问题”,这种引导式交互非常特殊,对于那些只需要走一遍的流程,它应该是最佳方案。但是,大多数交互流程,还是避免使用这种方案,一旦页面上有“状态变化”,那么不用加载新页面,用户就可以马上了解目前状态,并作出相应操作。

我最喜欢的手机照片处理应用Snapseed,它将后期处理的最基本工具打包在一个屏幕中,仅仅通过左右滑动和上下滑动,就可以快速的对照片进行基本调整,而相比大部分照片处理应用,这些基本功能都被拆分成很多块,放在不同的入口中,使用起来实在麻烦。




那么,独立屏幕的交互要注意的就是“状态”,用户和对象之间的三种状态:

  • 邀请/默认状态
Snapseed打开照片的默认状态——显示照片和提供一些效果预设(它还把你处理上一张照片的数值打包成预设,放在第一位供选择,精妙啊!)
  • 活动状态
Snapseed在你处理照片时会显示菜单、数值和直观的照片修改效果。
  • 更新后的状态
Snapseed在你做完操作后,回到默认状态。


约束条件

这条没什么好说的,设计每时每刻都需要平衡各种因素,微交互也一样。

包括:

物理性的——键盘输入?语音输入?影像输入?

强制性的——微博输入140字?用户名只能用英文?

经济上的——服务器的负担如何?10万够不够做出一个奇幻的效果?

数据上的——可以用哪些现有的数据?可以收集哪些数据?


不要从零开始

什么叫不要从零开始?就是在开始设计时,你手上可能已经有了数据

就像抖音的视频推荐,它会根据通讯录判断哪些人你可能认识。

就像打开摩拜单车的扫码框,它会根据时间和环境来判断是否需要开启手电筒。

需要注意,数据是一个非常好的东西,但是不能乱用,更像路边的野花那样不能乱采。所以如果这些数据涉及到让用户感到不适的状况,就停止收集的想法吧。


理解复杂性

Larry Tesler,对,就是第一章那个牛逼的Tesler。他有一个称为特斯勒复杂性守恒定律观点,非常适合设计规则,大致意思是:所有活动都有内在的复杂性,超过了某个临界点,简化是不可能的。

目前为止,全世界勤劳勇敢的交互设计师总结出了十八条交互定律,特斯勒定律是其中一条。


via: https://lawsofux.com/teslers-law


既然定律已经说了,有时候化繁为简是不可能的,这辈子都不可能的。那我们怎么办?好办,要不让系统来搞定,要不就让用户来搞定。

  1. 找出最核心的复杂性出现在什么地方。
  2. 确定用户掌握哪一部分。
  3. 用户何时介入。

听起来好像感觉非常牛逼,非常高深莫测。其实很简单,我解读一下:

  1. 什么地方最容易出错
  2. 用户可以控制哪些内容
  3. 用户在什么时候可以去修改这些内容

还是举例子,我爱举例子:比如,线上开通股票账户,最核心,最容易出错的地方是身份证号码,用户掌握着身份证号码的输入权限,同时也可以拍照让系统自动识别并填写身份证号,一旦识别错误,用户可以进行手动修改。

懂了吗?朋友?这就是复杂性,我的朋友。

那么,什么时候可以让系统去处理复杂性交互问题呢?

快速计算、多任务执行、大量记忆、监测复杂模式和从大数据中搜索。

简单点说:人觉得干起来非常耗时耗力的事儿,都特么让机器人去干吧。当然,永远要给用户提供可以手动控制的入口,不然机器人闹事你可兜不住。


愚蠢的人类。

—— T1000


关注下面的标签,发现更多相似文章
评论