交互设计的经验积累 来自积淀没有速成方法

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

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

　　提纲：

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

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

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

　　作者：yimin

　　文章来源：网易用户设计体验中心