谈交互设计的经验积累

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

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

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：数据挖掘……

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