用我这个交互流程管理工具，让你的工作变得井然有序！

由于性格和习惯，我在工作中时常处于内敛闭塞的状态。但作为专职交互设计师，除了完善功能细节和发挥创意外，整合各方资源、监测用户体验风险、提升团队的用户意识，是同样重要的工作职责，而这些均需要在项目开发中和其他岗位一起推进。如何克服思维局限、避免怠惰心理、充分调动内部资源，做到项目结束不留遗憾，一直是困扰我的问题。也一直在思考一种简单易行的方法论，能通过外在规范来约束和督促自己。于是便有了被我称为「四三二一」的交互设计流程管理工具。

四、三、二、一分别对应了产品开发流程中的需求、设计、开发、总结四个阶段中应该采取的行动步骤，由前期到后期，由策划到执行，均需要对应岗位的合作。从数字上可以看出，越是早期，应该要求越高、越多，以防止后期的偏差疏漏。下面从「四」开始说起。

「四」是who、why、when、where

「四」分别指who、why、when、where，这是需要和产品经理共同阐明的四个问题。

1. who，功能的用户群是谁

也许有人会说，产品的用户群不应在迭代中确认，而是产品最初应该定义好的，比如30～40岁之间的城市白领。这里要谈的其实是更加细分、明确的身份特征。比如产品经理想要添加一个笔记功能，那么我们就需要提前想到，什么人喜欢在听音频时记笔记，他有没有在其他地方记过笔记，喜欢什么笔记平台，习惯如何管理笔记等。竞品分析和跨界分析，此时就可以介入了。

2. why，为什么要做这个功能

用户的需求是多种多样甚至无穷无尽的，为什么我们要在当前时间迭代添加这个功能，功能的提出者是谁，验收标准是什么，有没有后续动作。一般情况下，需求提出者是产品经理本人；另一种是运营/内容提给产品经理/设计师的需求，比如要做专题活动或独立的内容模块。后者尤其需要注意，要直接找需求提出者而非转述者讨论功能细节和实现效果。why 和who 一起，共同确定了功能的「范围」层面，整体上把控住不要违背公司的「战略」即可继续执行。

3. when，功能使用场景有哪些

如果要增加搜人功能，放在搜内容后边，那可能就存在一些情况，用户希望首先出来的是人而不是内容。要做下载功能，一种是按照正常的查找对象、逐个或批量下载、等待下载完毕后收听；另一种是情况紧急，马上要出门了，需要地方把我可能想听的东西一键下载，越快越好。还有一些内部场景，如微信绑定，除了常规位置，也可以放在用户导入头像的时候。如昵称修改，除了常规位置，也可以放在需要临时隐藏身份的时候（直播间里）。场景切换可以给交互设计师带来无限的想象力和可能性，也是创意爆发，达到惊喜效果的一个突破点。

4. where，信息结构，即功能的位置和联系

界面和流程设计是交互设计的基本功，也是我们日常的核心工作。如VIP功能下，到期时间应出现在购买前、购买中、购买后的哪些地方；如工具栏上哪些功能需要放出，哪些需要收起。设计依据一般是功能的重要性、紧急性、使用次数、使用频率、界面分区等。

在和产品经理讨论执行的时候，有没有什么容易上手的理论工具可以使用呢？顺此延展一下，根据功能的工具属性和内容属性，我从衡量指标、体验要求、设计结构三个层面对二者进行了对比划分：

用我这个交互流程管理工具，让你的工作变得井然有序！

需要解释的是，「内容属性」和「工具属性」二者看上去处处相对，甚至有种相反的感觉，但其实二者在单个产品内更多是相互配合的关系。这里做成并列表格是为了方便理解，也是为了能利用二者间的张力为产品或功能快速定性。内容型产品中，工具要为内容服务；工具型产品中，内容要为工具服务。前者如我目前正在做的知识付费，后者如一些日历和天气应用。知识付费中关键的导购流程、使用流程和拉新流程，都是围绕内容展开的。能为此三大流程提供更快捷、更个性化、更有获得感的工具支持，是产品经理和交互设计师可以共同促进的地方。

为什么有的功能点击量很高却要收起？如微信朋友圈；为什么有的功能点击量相对不高却要露出？如电商的收藏、客服之类。其重要原因是前者里内容为工具服务；而后者属于应急工具，需要快捷感和效率性，如果做不到这点，它们本身的存在意义就大打折扣了。

敏感的读者也许已经发现，where 和when 有重叠的地方，因为使用场景也是信息结构设计的重要参考因素，甚至是整个策划和沟通流程的重要节点。它的作用，有些类似「用户故事」在迭代开发中发挥的作用。以上四点，是需要在迭代初期与产品经理深度沟通同步的地方。

「三」是交互说明、demo、自检表

「三」分别指交互说明、demo、自检表。需要的配合资源是交互设计师、（GUI）设计师、测试工程师等。

1. 交互说明

使用 axure 制作的线框图结合文字说明，包括功能需要的全部界面，方便设计师和测试进行对照设计与规划测试用例。

与产品经理配合，尽量把产品文档中的规则和规格部分兼容进来。

在样式上与其他交互设计师和GUI设计师确认有没有违反既定规范的地方，在颜色、透明度、间距、大小、形状上为设计师提供专业建议。例如在重要的地方使用高亮，使用频繁的地方放大面积。

以交互设计师制定的文案规范为基础，与运营、产品经理和设计师商定元数据。注意系统平台的用语习惯和审核要求。

2. 演示用的demo

使用axure、keynote或墨刀制作，展示关键流程和动画效果。

与动效设计师明确，如果需要添加动效，预期是什么，并为其提供对应参考目标。包括为交互增强操作反馈，让流程更顺畅；为信息传达增强获得感或鼓励感；为功能增强仪式感或趣味性。如弹窗动画、金币掉落动画、开红包动画。

与开发工程师协调，流程需要解决什么问题，即用户故事。这样可以激发开发人员自带的创造性和积极性，灵活积极地应对开发难题，甚至超预期实现目标。例如某个交互动作经过调研难度较大，则可以在明确要求后，允许其根据经验自由发挥，交互设计师从旁协助。

向测试工程师说明，demo演示的只是关键部分，或静态画面和语言难以形容确切的部分，「交互说明」内会涉及到其他测试用例。

3. 简易的交互设计自检表

在交互设计师单人作战，独立决策，快速制图的日常工作中，怎么把疑虑、重点、期待、用户感固定下来，既容易掌握实现，又可以凝结以往的经验和规范，做一张简单的自检表就行了。我认为其中内容不应该拘于交互层面，也应该把产品、开发和测试的突破点写下来。宜精不宜多，方便贯彻。保证每次迭代均有不同，描述范围可大可小，且在上述的讨论过程中逐步确立。以下仅举例：

点击区有及时反馈，不依赖于网络和身份
文字有说服性
用图片增强感染力
高频率功能可以快速到达
新功能有邀请
无法挽回的操作有强制确认
标题显示完整
可以查看具体发布时间
告知用户使用规律或意外情况
有招牌交互

「二」是开发评审、开发走查

「二」分别指开发评审、开发走查。需要的配合资源是开发工程师。

1. 开发评审

依托以上文档向开发讲解功能点，从功能来源开始，第一遍讲创意，结合对现有功能的修改点，对其他产品的参考点。第二遍讲细节，包括用户身份、网络状态、极限情况、跳转和返回对象等。第三遍讨论关键节点和设计顾虑、招牌交互、动画效果等。如果产品经理对相关功能有多次迭代计划，也要同步给大家。以用户体验为理论基点，同时了解开发质疑和困难。

2. 开发走查

开发过程中，也会多向开发和测试宣导本次迭代的设计重点和预期效果。根据这两个岗位的工作节奏，是从基本完整开始测，从整体框架开始搭，而非按照界面顺序逐个实现。所以要注意角落处零碎的细节是否慢慢在添加，不能着急，也不要遗漏。如果发现自己设计上有坑，不要迟疑要立即提出来，再和团队商量是否立即填上，或等下次迭代。立即公开是防止问题在之后被运营、用户或公司领导偶然发现时，相关人员没有做好准备，不能快速响应。

「一」是1个教训

「一」指1个教训，即自我总结不足。

没有完美的项目迭代，对交互设计师尤其如此。我经常是迭代刚开始，自己就有了更好的交互方案，或迭代进行到一半，发现场景不对。不能不说是遗憾。上边谈到的均是如何与其他岗位资源协同，求助于人。而自己要从已结束的迭代中发现问题，总结技巧，分享收获，也把填坑方法说出来，可以让更多人看到你的努力，更加信赖你，方便以后开展工作，和推广用户体验的设计理念。