交互设计师的工作中,基础的工具、常识、流程……,这些都能够轻松学习到;最终的产出物,也能够找得到成熟的范本;而只有中间的经验,只能来自积淀,没有速成的方法。

这篇分享,把自己成长中和交流中获得的一些经验略微举例,加上交互相关的一点基础,希望能给对交互设计有兴趣的朋友提供一些帮助。
提纲:

1. 入门

1.1. 工具

1.2. 原则/常识

2. 称职

2.1. 经验

2.2. 经验积累的切入点——模仿并思考

3. 进阶

3.1. 一定程度地违反逻辑

3.2. 扩展相关技能

1.1. 工具:——一切可用于绘制线框,表达交互设计蓝图的工具,甚至可以用很不主流的PPT、或者直接用前端语言来写;用的最多,最适合的当然是Axure,具体的使用教程不讲,可以参考:

AXURE在原型设计中的应用

[2010W13]早读:Axure

Axure的使用中,个人认为对入门比较重要的两点:

栅格——按照栅格系统划分布局,并适当对齐,可以方便下一步UI同事进行设计,需要注意的是:

a)         方案尚未确定的概念设计阶段,不要追求对齐和美观,能把交互设计捋顺,比什么都重要;如果对着软件界面不由自主地想要对齐,而时间又不是很充足,宁可先纸上画草稿,也不要为了对齐而影响设计思路;经验成熟之后当然另说,能够在保证交互清晰的基础上,同时兼顾到界面美观(交互稿与视觉稿之间的间距比例,很可能非常不同,最糟的情况可能因为间距问题,导致交互稿需要推翻重来);

b)         绘制线框图时,大可以画的整齐漂亮一些,但具体设计一定是由更为专业的UI同事进行。

灰度——在同一个界面中,用不同深度的灰色,表示不同区域的权重和相关性

1.2.  原则/常识

这里也不展开讲了,基础的一些教程,比如《 Web可用性设计》《Don’t make me think》,都可以学习到一些最基础的知识。

2.1.  经验

我认为,同任何一门学科或者技能一样,交互设计中,同样存在着工作的对象(流程、控件、控件组)和目标(需求);对这两个方面所包含的内容,分别进行细微区分和掌控,便是交互设计的经验。

实现同一个目标,比如最基础的,我们需要一个入口,点击它,触发新的内容或者功能。
做法有很多:按钮、长短不同的文字链、下拉菜单、tab标签、radio组……
其中又包含不同的色彩、下划线样式……
它们分别对应不同的使用场景,使用的效果有细微区分。

面对目标需求,可以将其抽象化,在内容不影响形式的时候(或者说大多数时候,我们都尽量达到这样一个效果:面对不同的内容,我们所使用的这个形式都能够兼容),可以抛开需求的具体内容,而是去考虑它要实现的是一种怎样的交互形式。

比如这样一个例子:

原始需求:要有两个头图轮播,一个是活动公告,一个是产品推荐,但我又担心两个都会动,变得很奇怪……但又都想放……
抽象需求:有两个模块,模块的内容是复数入口,图片方式,避免相互干扰;
分析:
1. 首屏区域出现两个自动轮播的内容,显然会相互干扰;
2. 自动轮播的目的是获得更多展现;
2.1. 需要不自动轮播,仍然能够展示出其中部分信息的做法

于是这是线上的效果,右下是一个比较少见的推广入口设计,非当前状态的图片,标题能够得到展现。

交互稿:

如果交互设计师的经验,只是在具体的任务中积累具体的经验,这个过程无疑过于漫长且事倍功半;掌握抽象统一的一般规律,并掌握细微区别,这个方式,能够使经验的积累和设计工作更为有效。

2.2. 经验积累的切入点——模仿并思考

有一个快速存储这类经验的方法,就是自己动手,把现成的网站抄成交互稿。

直接看成品的交互稿,可能并不容易理解,而在自己动手画的时候,可以伴随着思考:
为什么模块是这样摆放,
为什么使用这样的流程,
为什么是这种层级,
面包屑vs导航条,
强按钮vs弱按钮vs功能链
……
捎带学习了Axure的玩法

如果觉得有错误……别怀疑自己,很可能就是他错了;或者,是平衡协调后的产物。

之前的一个用于可用性测试的例子,有点像是这个情形:

当时需要评估这个产品规划中的部分新功能的可用性与易用性,并为了测试任务的流畅,模仿了大量的现有功能,甚至用Axure模拟了从硬盘上传图片。

在这个任务里,比较有印象的收获是,用axure的Frame工具,可以模拟“回到页首”或者底部导航条这种与浏览器位置相对固定的模块。

3.1. 多种方案的权衡

实现同一个目的,有多种不同的方案,每个方案,都可能在这个方面强一些,在另一个方面弱一些;实际使用上,它们的效果通常并没有非常明显的区别。
这是交互设计的另一项经验:如何设计不完美的作品

又要易用流畅,又要屏蔽干扰项,又要方便用户随时切换,又要充实又要简洁……这种设计方案是不可能存在的,而为了产品和运营的目标,为了用户看似不合逻辑但切实存在的操作流程, 我们通常面临的需求正是这种复杂需求,同时往往伴随着名为“快速迭代小步快跑”之类的短工期。

这时,对不同方案的细节区分,各自有什么样的优劣,熟练于心,可以方便我们快速地决定一个或是另一个方案,而不是陷入长时间的纠结。(pm非要纠结则另当别论……)

如同这个机票查询的例子,各家的使用方法不同,效果也各有倾向(或者说,由于需要偏重的方向不同,而使用了不同的设计):

大多数机票查询的入口,都是这样,单程/往返使用两个radio,放在最前面;选择单程时禁用往返,或者隐藏返程时间输入框。
逻辑是这样的:用户最先决定自己是单程还是往返,然后再选择起降地点及时间……这显然是产品逻辑,实际上绝大多数用户都不是一去不回,而是必须回来的。用户随时可能从买单程变成想买往返,而这时候再把注意力返回到页面最上方,又离的很远成为了负担。
不禁用返程,又担心用户被这个框干扰,影响任务往下走。

于是淘宝的版本是这样的,返程时间不禁用,只是视觉相对弱化;返程时间输入框获得焦点时,上方radio自动切换到往返。
同时,要回到单程状态……仍然只能手动通过radio切换。

这个控件组的作用,抽象地说,就是二选一的入口,分别对应不同的内容展示:两个radio/下拉列表/tab,都能起到二选一的作用。下拉列表鼠标操作次数太多,适用于更多选项的情形;tab带有两者平行且无交集的意味,所以这儿也不适用。

一种特殊的二选一,就是是否,是否需要返程,于是可以用复选框:

这时,用户在往返与否之间切换的成本最低。

这并不是说使用radio的方案不正确,只是在只有这两种情形的产品,使用复选框会更好一些,如果考虑扩展的情形:

还是应该使用radio的。

3.2. 扩展相关技能

视觉:栅格、用色、间距……

前端:代码逻辑、可实现性

产品:功能设计

用研:可用性测试

BI:数据挖掘……

同样也不展开说了,这些内容,对交互设计工作都会有相当的帮助,但也不需要精通,基本了解就可以。

个人经验和理解啰嗦完毕……欢迎共同讨论。