听蛙居 – 帅青蛙的工作与生活

序：这篇博文是整理出来要发到公司部门博客上的，但是那边的博客一直没有发出来，所以转一份到这里，算是这段时间的一个比较重大的工作总结吧。

==============好吧，我是万恶的分隔线==============

随着项目管理过程的不断改进，曾经的流程已不能很好的满足大部分的工作需求，交互工作也慢慢的显现出各种问题，面对种种问题，交互工作就需要重新考虑下如何改进流程以适应目前项目流程，今天我们来探讨一下交互在项目流程中存在的一些问题及改进方向。

在探讨之前，我们先用一张图来看一下之前的交互工作，或许这个流程会有人感同身受。

从图上不难看出，这个项目的工作流程很简单，一目了然，没有什么分支线，也没有什么特殊的工作点，光流水线了。但每个工作点其实几乎一个都在处理差不多的内容，甚至是重复的。以至于整个项目在进行的过程中，可能会经常出现各种返工，因为交互的想法随着经验的积累会改变，那这每个阶段的交互工作基本就成为项目的风险点了。

如果再仔细分析一下这个过程，发现交互的沟通工作其实是很少的，而沟通是交互正常进行的有效手段；如果原型阶段被裁剪的话，基本没有沟通，仅剩纯粹的各种检查跟测试，这对项目其实是很不利的，咱分几个小点来讨论：

首先，交互在需求前期没有足够的深入，那就说在之后的工作中，对需求的理解就存在一定的误差，如果再缺少沟通，那是很杯具的，这会对后期工作的开展埋下了一个重磅炸弹。

其次，交互在设计阶段有一个切入点，虽然设计部分需要有交互的支持，但验证的环节本不应当由交互来验证，除非需求跟易用性；否则也会在某种程度上影响了设计师的发挥，甚至交互可能会变成“指手划脚”的角色。

相信这张图，可以引起广大的设计师同胞们的强烈反响……其实交互不是这样的人。

再次，在页面检查阶段，最有说话权的是设计师，交互在这一阶段的工作其实是多余的。

最后的功能/系统测试阶段，交互只是把之前做的工作再重新翻出来再做一次，这一阶段的工作前期其实都做得很多，这里再涉及一次，相当于之前的工作几乎可以不用做了；而且，如果在这个阶段把之前可以发现的问题再翻出来，那这个修改成本就高好多。

从以上几点不难看出，整个交互的工作基本等于低效状态，无法在关键位置提出关键问题，然后很好的解决，反倒是会把项目的风险暴露出来，有可能会造成整个项目的延期。

我们再来看一下新流程。

新流程借鉴了敏捷的一些方法，引入迭代及阶段性成果展示的目标点，如果再走以前的流程，那结果是可想而知的。所以经过研究，我们决定使用这样的工作流：将需求提前，把交互的工作与其他关键点的工作做并行开展，增加沟通时间，从而减少实现过程中的风险；当然，对关键点中人员的技能提出了比较高的要求。

换成流程图，大致如下：

光从图上来看，流程似乎变复杂了，事实上真正操作起来也的确复杂。

如上图所示，用户需求发出来评审的时候，交互工程师就需要介入需求的优化，力争在需求修改的阶段把可能存在的易用性问题都提前修改完成，这样就可以以最少的修改次数确定用户需求。

需求评审完成之后，产品经理把用户需求做成原型发给开发工程师；交互工程师把对需求的理解，及需求中涉及的页面画成线框图，然后将线框图发给设计师。设计师基于这个线框图将界面设计出来，包括风格、配色等相关元素；而在这一阶段，全由设计师处理，交互工程师与产品经理不再参与，直至设计完成发出来评审。而评审阶段，交互会与产品对该设计稿进行检验，验证是否符合需求，是否实现交互的思想。

这样在需求阶段，交互的思想就已经可以跟需求融合并体现在产品界面里了。

前端将设计稿实现之后的检查就是属于界面细节的检查。

由于设计师是最清楚界面细节，此时的验证交给设计师去验证，可以最大程度上的减少前端实现不细致的问题；虽然在功能测试的时候，交互工程师也会对这方面进行检查，但此时的检查，目的同样也是把前端制作的界面问题发现在最前期，降低后期修改的成本。

另外，前期设计人员检查，后期测试阶段的交互工程师的检查，实现了“双重保证”，某种程度上来说也提高了产品质量。

前面我们说过，我们的新流程引入敏捷的一些方法，有阶段性的成果展示，基于这样的阶段，交互的流程增加了两个功能内容，这两个内容是交互工作改动比较大的地方：需要出阶段性易用性问题列表及最后的易用性改进方案。

易用性问题列表，是把该阶段发现的易用性问题列成清单，然后在成果演示会上，会把这份清单在会上进行评审，确定是否修改，接受修改的问题，在下一个迭代的工作成果中会体现（修改）出来，而不接受修改的问题，在以后的迭代中会比较少涉及，减少重复问题出现的机率。

易用性改进方案，是整个项目结项的时候才出。它的作用就是把项目在开发的过程中发现的，但不是属于需求阶段确定的易用性问题列出来，并提供相应的改进方案。这个节点的增加，可以保证项目在进行的过程中不会因为各种想法的临时产生而造成重复返工，同时也对下一版本的需求改进提供参考依据。

对于这次的流程变更，很大程度上是因为项目走短平快方式，而不得不跟着改进。虽然目前还处在试行阶段，但相信这样的改进，会对整个项目的流程起到一定的作用，也可以提高产品的质量。当然，不同的公司有不同的情况，这里仅讨论以我们公司为基础的流程改进方案。

仅一家之言，或许还有更好的方法？欢迎探讨。

帅青蛙
2012年01月09日

分享给其他朋友看看

关键字：交互, 使用方法, 总结, 沟通, 流程