交互设计是从得到需求开始的(以产品为主导的公司，交互设计师会参与产品需求与定位，不在本文的讨论范围之内)，一般会在获得需求文档以后，进行一次需求沟通（需求评审）。
需求评审会是交互稿完成之前，最为重要、参与成员最多的一次会议。由产品经理介绍相应的产品功能背景，与交互设计、视觉设计、前后端开发探讨产品功能的实现逻辑与可行性方案，从中选出一个在整体效果上最优的方案。同时，与会人员给出产品在各阶段的开发时间节点，便于项目经理对产品开发进度的把控。
需求评审是交互设计师通盘了解产品需求、确定功能交互方案的最佳时机。虽然后续还可以进行沟通，但是，在效率以及需求的全面性上都大打折扣，更多的是单个功能逻辑的沟通。因此，面对需求评审会，一定要做好准备，带上脑袋去参加需求评审会，得到自己想要的东西。
首先 会前准备
一般情况下，需求评审会之前都会将需求发出来，作为接下来各阶段工作的依据与目标。作为交互设计师，在拿到需求以后，工作已经开始，而不是等到需求评审以后，时间节点确定以后。在需求评审之前，有几点工作要完成：
充分的需求理解分析
产品经理提供的产品需求说明文档，是交互设计师开展交互设计的主要依据。最终，交互设计师设计方案要满文档中关于界面交互的所有功能需求。产品需求说明文档应该包括如下内容（后期对产品需求说明文档详细阐述）：
对于交互设计师，主要关注的是需求详细描述中的功能需求部分，对于功能需求的理解关键在于对功能的整体流程的了解与梳理。每一个产品都有若干功能组成，设计师要模拟用户的使用场景，在使用该功能时，思考页面应该给出的反馈与提示，来保障功能交互的顺利进行，用户目标的顺利实现。
有目的的需求梳理
设计师在需求了解以后，就要对需求进行梳理，梳理的目的在于简化功能流程，将用户与界面之间的交互点提炼出来，梳理出相关功能任务的交互流程，可以参考《不得不懂的交互设计三要素之贰——交互流程设计》。
将文档中出现的与界面有关的功能全部整理出来，并根据功能进行分类，完成功能聚类。然后，使用思维导图工具XMind或者MindManager将其整理出直观的功能列表。
整理出交互设计可用的需求
对于整理出来的功能列表，更多的是构思中的产品架构，是思维上的，对设计师来说，并不能直接使用。因此，交互设计需要对功能列表进一步的加工，打破功能纵向上的联系，完成功能横向上的重构，可参考《不得不懂的交互设计三要素之壹——信息架构》。整理结果如图（请忽略详细功能描述）：
功能列表更多的是纵向上的功能流程，而在这一步要完成业务需求上的横向布局。可以将各个功能分门别类的放置到相应的标签下面，过程中也可以对具体功能进行拆分。有些功能流程会横跨多个界面分类，将其分到不同的标签下面，更多的考虑产品横向的界面的关系。比如，很多Web产品的首页是一个产品的功能概要展示，或者有一些业务目标的直接入口，用户可以从首页直接跳转到其他页面，但在功能流程上是完整流畅的。
在完成这一步以后，一个产品的具体页面布局已经呼之欲出了。如果时间允许，或者这个列表还不够具体，交互设计是可以将各个标签转换成标签页面，并对相应的功能进行占位符表现，这就可以称得上交互设计初稿。
其次 会上提问
在需求评审会上，首先，产品经理会对主要功能需求与特殊功能需求进行阐述，这个过程中，交互设计师就要对自己理解的需求进行检测，是否符合产品经理的功能预期。对于有疑问的地方，可以进行询问探讨，直到明确为止。
需求评审会不仅仅是对产品功能，业务流程的通盘了解，也是交互设计师确认功能需求向交互界面转化的契机。交互设计师要在会议上阐述自己的交互界面构思，解决功能疑惑，确认交互设计方向。
接下来就需要交互设计师将整理出来的、可视化的功能需求列表或者交互设计初稿展示给大家，征求其他成员的意见，这种功能分类与页面布局是否符合业务逻辑，可以进行适当的功能布局调整，满产品需求。
总的来说，交互设计师要在会议上确认交互界面设计方向，尽可能详细的了解功能与业务逻辑，解答需求梳理过程中的出现的问题。
最后 会议纪要
评审会结束以后，要尽快将会上得到的内容总结出来，并以邮件形式发给参会人员，特别是产品经理。一方面，防止会上确认的内容被遗忘，也便于后期在制作交互稿的时候，进行参考；另一方面，立字为证，防止需求的随意变更。可参考《你知道交互稿完成过程中的六个要点吗？》，文中对这方面的问题进行了详细的阐述。
愿与你同行！
