做交互设计师已经一年多了，在项目开发过程中，自己踩过不少坑，也向前辈们学过不少方法论。现在想基于自己的项目经历，拆解一下交互设计师的日常工作流程和注意事项。希望能给刚刚入行的设计师小萌新们一点点来自过来人的启发。
一、需求获取
1. 需求分为几类？
需求一般由产品经理提出，产品经理会根据产品现阶段发展策略，结合市场调研、用户反馈等相关信息，制定项目需求，并输出需求文档。
需求一般分为三类：全新产品，新功能，已有功能优化。全新产品一般会交给有一定经验的中、高级设计师完成。新人交互设计师遇到的更多的会是新功能和对已有功能的优化。
这两类需求，往往团队内部对用户、业务有一定共识。产品给出的需求文档也相对详细（即使不详细，团队内部的信息资源也相对充分）。
新人交互设计师更多的需要了解需求的相关背景，明确需求的“业务目标”、“用户目标”，在和产品经理达成共识以后，提出更适合、更具投入产出比的方案。
2. 需求文档是什么？
对于新人交互设计师，读懂产品的需求文档是第一件要事。其实说人话，产品的需求文档的核心就是三个点：为什么要做这件事，怎么做这件事，做了之后会有什么效果。
一份需求文档通常由以下六个部分构成：
1）功能背景
产品经理会描述相关使用场景，结合真实的用户数据，反应用户现在遇到了什么问题。并从用户和业务两个角度，说明目前为什么要解决这个问题，以及解决之后会带来什么好处。
2）需求列表
产品经理会描述怎么解决这个问题，具体要做哪些功能，各功能的优先级是怎样的，是否要分阶段开发？
3）数据定义（选填）
如后台类的数据型产品往往需要由产品定义相关数据规则。
4）原型图（选填）
为了让相关方更好的了解需求，产品经理有时会给出原型图。
但对于新人交互设计师来说，这类原型图往往具有迷惑性，不能解决用户实际问题。一定要透过原型看本质，发现产品想解决的核心问题。
5）考核指标
通常由一到两个核心指标构成，用于功能上线后，验证实际的收益。这类考核指标其实也可以辅助新人设计师制定设计目标，衡量自己设计正确与否。
6）变更项记录
在输出需求文档后，会因为各种原因导致需求变更，产品经理或会及时通知相关方，同时将变更项记录在需求文档上，方便后期回溯。
3. 怎么做需求分析？
不同的产品经理写出的需求文档风格迥异（qianqibaiguai）。做好需求分析，有助于交互设计师找到核心问题，一次把事情做对。同时明确设计定位和思路，让一切设计都有据可依。
通常拿到一个需求，可以按照业务需求、用户需求、用户体验路径三个层次进行分析，最后的设计定位和设计策略就是需求分析的结论。
二、交互初稿
做完需求分析以后，可以带着问题和结论找产品经理沟通，跟产品做一次目标对齐，这种有的放矢的讨论往往更有效率，也会增加产品经理对你的信任感。
在确定了设计目标之后，就可以开始定框架了。需要构建用户的使用流程，设计用户如何一步一步完成任务。不用具体到交互细节，但是需要把整个任务中涉及到的页面串起来。输入页面流程图。之后就可以找开发负责人，确定技术的可行性。
交互设计师很容易遇到的问题就是不懂开发逻辑，设计了一些开发难以实现的方案，然后反复改稿。跟开发负责人对接的目的就是：帮助你了解相关技术实现，并让相关方从技术的层面上提前帮你过滤重大问题。
当确认技术可行性之后，再去补充交互细节，之后及时还会有技术问题，都不会涉及大框架的改动，对于交互稿的修改程度也能降到最低。
在内审之前，交互设计师需要提前输出交互方案，交互方案包括 ：需求分析、信息架构、流程图、交互逻辑。然后就可以提前通知相关方参加内审。
三、交互内审
交互内审的评审团成员由项目对应的产品经理、视觉设计师，以及团队内其他交互设计师构成。
1. 为什么要交互内审
交互内审的目的是内部过滤与需求不符、用户体验问题：
- 从个人来看，有助于把控设计输出质量。
- 从团队来看，有利于提升整个设计团队的设计质量，提升产品竞争力。
- 对于新人设计师来说，无论是自己还是其他人的交互内审，都是一个很好的学习和验证的机会。
2.交互内审流程
1）评审前
需要提前通知评审团成员，评审团成员需要提前阅读交互稿，记录问题。
2）评审中
评审人要先告知评审范围，有逻辑的展示功能，同时在现场控场，收拢意见，定夺分歧。评审团需要保持专注，检查用户需求、业务逻辑的合理性以及用户体验。同时给出优化方向。
3）评审后
评审人将本次评审中遇到的问题进行整理，公示，然后根据优化意见对交互稿进行修改。改动大时有必要发起二次评审，修改完成后，需要再次同步给评审团。
内审完成后，就可以组织一波交互外审了。
四、 交互外审
1. 交互外审目的
交互外审的评审团成员由对应开发、视觉、产品、测试构成。
交互外审的目的是敲定最终方案。
2. 交互外审流程
1）外审前
找对应开发人员提前过稿，过滤技术问题。
提前 1 天，发送邮件给相关方负责人
2）外审中
- 产品进行需求背景同步；
- 交互先讲解主流程；
- 交互再讲解具体交互细节；
- 相关方提问，讨论；
- 交互记录会上问题：有结论的，当场达成共识；没有结论的，会后相关方再讨论。
3）外审后
整理评审建议，处理争议问题，最终输出交互文档，同步相关方。
3. 交互外审注意事项
1）提案形式
本次评审面向的核心对象是开发人员。
为了帮助开发人员快速带入场景，除了完整的交互文档以外，可以使用PPT、axure、墨刀等工具快速搭建一个可交互的产品简单原型。先演示完整流程，再讲交互细节，可以极大的提升评审效率，增强相关方信任度。
2）提案心态
外审过程中，一定要注意控制心态，因为开发是利益相关方，为了更好的完成工作。他们可能会尽可能选择简单好实现的交互方案，并对实现复杂的交互功能产生质疑。此时，你需要对自己的交互方案有充分理解，实现复杂的交互功能一定要有不得不做的理由。
同时，在评审前，自己也要给交互方案中的各个功能制定优先级，抓大放小；充分考虑投入产出比，用最优的方式实现产品目标。
五、 交互输出
在输出交互文档的时候，需要注意以下问题：
1. 正确性
交互内审和外审都是在短时间内完成的，评审团对交互方案的了解程度有限，交互设计师本身应该有一张自查表。对照检查，再次发现问题。自查表的参考维度可以参照尼尔森用户体验法则。
2. 完整度
交互文档对于开发和测试的同学来说，都是理解业务的主要途径。因此，文档需要包括主流程和分支流程、异常流程。其中分支流程和异常流程容易被遗漏，因此在输出前应该尽量补全。
对于一些极为边界的场景（只有开发和测试过程中才被发现），后期可以通过变更项的形式补充在交互文档里。
3. 可读性
除了功能上线后面对的真实用户之外，相关方其实也是我们的用户。因此使用统一的设计语言，遵循统一的标注规范，可以极大程度的提升相关方的阅读效率。
六、 跟进
当交互文档输出之后，在视觉、开发实现过程中，可能因为需求变更、技术问题、方案优化等原因，导致交互方案需要调整。
交互设计师要在交互文档中页记录变更项并同步给产品、视觉、开发、测试。变更项纪录包括以下几个项目：变更时间、变更前，变更后、变更人、相关方、备注。
七、验收
开发完成后，开发人员会根据交互稿进行一轮自测。之后，会在项目送测前，会组织交互、视觉、产品进行验收。
交互设计师需按照交互稿仔细检查开发的实现是否与交互稿一致，及时记录验收问题，区分优先级，并同步给相关开发。
验收问题分为3个等级：
- P0 功能主流程问题，直接影响用户完成核心任务。A1送测之前必须解决。
- P1 功能非主流程问题，A2送测前必须解决。
- P2 视觉样式，交互优化问题，可以考虑下期优化。
八、上线跟踪
上线后，交互设计师需要整理本次项目中未解决的问题，纳入需求池。
通过 Friday 、用户反馈等多种渠道研究用户数据，针对核心问题建立转化率漏斗，进而验证自己设计方案的正确与否。
一些日常心得
作为一个交互设计师，每天面临这样的难题：要在规定时间内，用最优的方式达成目标。
在我的认知里，一个好的交互设计师，核心能力主要有3个：结构化思考、同理心、解决问题的积极心态。
结构化思考是基于分析能力，面对复杂的需求环境，迅速归纳整理信息，找出核心问题和解决方案。
同理心是基于业务能力，能够站在用户的角度上，发现用户体验路径中的核心问题，为用户创造动机、排除担忧，解决障碍。
同理心和结构化思考力，都需要时间和经验的积累。而解决问题的积极心态，是一个交互设计师新人一开始就应该养成的职业精神。
由于交互设计涉及的相关方太广泛，新人交互设计师在工作中往往会遭遇来自相关方的各种质疑。
产品会质疑你没有满足需求，视觉会质疑你的方案影响了视觉的发挥，开发会质疑你的方案投入产出比低，测试会质疑你的交互文档不够完整，没有覆盖测试用例的所有场景……
刚入行的设计师有时会有这样的心态，过分绑定自己和自己的作品。在评审过程中，一旦遭受了质疑，就会把这种质疑当做相关方的对自己的不认可，然后心态爆炸，大家各持己见，使评审一度僵持。
作为评审的发起人，交互设计师在评审过程中，应该保持第三者的客观态度。把交互文档看成是其他人的输出，而自己和相关方都是评审团，评审的目的是为了找到应该投入产品比更高的解决方案。
抱持这样的态度，新人设计师能够获得更宽广的视野，快速成长，同时也有利于培养与相关方之间的信任感，这种信任感能帮助设计师快速融入团队，方便日后工作的开展。