交互设计个人经验和理解:交互设计的经验总结(3)

3.1. 多种方案的权衡

实现同一个目的，有多种不同的方案，每个方案，都可能在这个方面强一些，在另一个方面弱一些；实际使用上，它们的效果通常并没有非常明显的区别。

这是交互设计的另一项经验：如何设计不完美的作品。

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

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

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

大多数机票查询的入口，都是这样，单程/往返使用两个radio，放在最前面；选择单程时禁用往返，或者隐藏返程时间输入框。

逻辑是这样的：用户最先决定自己是单程还是往返，然后再选择起降地点及时间……这显然是产品逻辑，实际上绝大多数用户都不是一去不回，而是必须回来的。用户随时可能从买单程变成想买往返，而这时候再把注意力返回到页面最上方，又离的很远成为了负担。

不禁用返程，又担心用户被这个框干扰，影响任务往下走。

于是淘宝的版本是这样的，返程时间不禁用，只是视觉相对弱化；返程时间输入框获得焦点时，上方radio自动切换到往返。

同时，要回到单程状态……仍然只能手动通过radio切换。

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

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

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

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

还是应该使用radio的。

3.2. 扩展相关技能

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

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

产品：功能设计

用研：可用性测试

BI：数据挖掘……

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

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

作者：yimin