当交互设计师完成一份自以为详尽的交互输出物,前端的开发结果总是不那么另人满意。交互会抱怨:为什么会做成这样呢,很多常识性的东西也会做错。显然因为领域不同,对“常识”的理解不尽相同,我们不能把希望寄托在前端工程师的可用性觉悟上。所以交互设计师必须站在对方的角度,在提交输出物前补充交互细节,以免日后不必要的迭代。
1.列表项目为空时的显示效果。比如“购物车”里没有东西时,该如何显示。否则开发会让屏幕空白。
2.当页面或应用会向后台下载数据较慢时,载入过程的提示。如果我们不说,技术不会考虑载入时的信息反馈,会让页面呈现假死的状态。
3.当按钮、图标、链接等不可用时,怎样呈现给用户(a.消失 b.disable+文案改变c.disable+tip d.非模态或嵌入式提示 e.点击后出现模态对话框)。如果我们不说,技术会采用最简单且一般来说体验最差的方式—模态对话框,甚至什么提示都没有。
4.应用或者一些偏操作的网络产品,对话框内的按钮,如“确定”“取消”。需要有一个默认选中,支持键盘enter操作。
5.每个图标都要加上tip,尤其是用户可能不明白的拖动操作。
6.在文档中规定系统出错的提示该如何呈现,提示的文案中不能带有技术性描述(如错误类型:XXX)。如果我们不规定,技术会自己添加一些出错的模态浮层,使用技术性的语言。
7.文本长度超过标准被截断时,该如何显示。
8.鼠标的响应范围,如列表项目,radioBtn ,checkbox等。一般来说,响应范围大点好。如果我们不说,技术只会使用默认设置,如radioBtn的响应范围就只是前面那个点。
9.修改文本框内容,在获取焦点时,是全选还是将插入点放在文本末尾。
如果用户很可能会重新输入整个值,则应在获取输入焦点时选择全部文本。如果用户更有可能进行编辑,则应将插入点放在文本末尾。
10.下拉框,列表框的默认定位,比如生日。如果我们不说,技术会默认在“1900”年。
11.如果是客户端,或是流式网页布局,要提供多种分辨率下的展示。
12.在移动客户端,多点触摸,手势的操作和动画过程,显得尤其重要。
13.用户操作成功或失败的反馈,超时的反馈,系统崩溃的反馈等等。
14.移动客客户端横竖屏的不同显示方式,网络状况差时的交互反馈。