交互设计师在这整个流程中，需要主动推动项目的进展，积极沟通，充分协作。在需求阶段充分了解需求，设计阶段不断与产品经理(需求方)及相关人员(视觉、开发等)沟通，开发阶段积极传递设计目标及效果，有变更及时通知。尽量保证整个团队的信息同步，才有可能高品质地实现敏捷开发。

　　1.需求理解

　　多问为什么，充分理解需求，发现不合理处及时沟通

　　a.多问为什么——验证需求真伪及价值

　　由于B端产品的需求通常来源于产品经理或销售访谈客户或用户时获取，交互很少有机会参与，所以需求多由产品经理向交互传递。而在这传递的过程中，往往夹杂着一些表面需求或个体需求，或是产品经理自己也不太明确的需求，因此，“多问为什么”则显得至关重要。一是避免大方向错误导致的返工，二是有助于深入了解需求背景。

　　为什么需要这个功能?这个需求基于怎样的场景?需求的来源及数量是怎样?当前想解决的最主要的问题是什么?预计以后的方向是什么?当前问题和以后方向冲突吗?等等，当解决了这一系列问题，即验证完需求的真伪及价值后，便可展开下一步了。

　　b.充分理解需求——挖掘深层需求

　　B端产品涉及到繁杂的业务，做设计时，对于业务逻辑的要求非常高;在设计前充分理解需求，理清本阶段的设计目标，有助于设计阶段能更全面地看待问题，而不是针对一小点一小点的设计，同时避免因理解误差导致的方案不理想。

　　实际工作过程中，产品经理提供需求时常常是不完整的，只简单阐述背景和这样做的原因，而一些隐含的更深层次的(或说更原始的)背景原因和条件，则需要交互设计师不断去思考、不断与需求方沟通才得知。如果没有充分理解需求，仅仅知道用户的操作步骤是由这到那，而不清楚他进行步骤的背景和原因，不仅会导致对需求有理解偏差，无法挖掘到深层次的需求，更别谈做出最优解的设计了。

　　c.发现不合理处及时沟通

　　在整个需求传递的过程中，产品经理提出的需求不一定是原始需求，有些则是经过加工或推测得来。当发现需求有不合理的地方时，应及时向相关人员询问沟通。不要等到设计时，才发现一大堆由“假问题”引发出来的“真问题”。当然，如果这阶段交互发现了什么好的/可改进的需求点，也可以提出与产品经理讨论。

　　有的时候，产品经理通常会以“ 市场就是这样的 ”/ “这个地方不需要你理解”等等理由来回避一些可能有缺陷的需求，这个时候仍然不要放弃，要继续了解原因，最大化地避免前期失误导致的后期更大工作量的浪费。

　　2.需求分析

　　理清设计目标，梳理业务流程，对信息进行合理分类

　　a.理清设计目标——支撑你整个设计的最重要的元素

　　从基于场景的需求中，分析用户最本质的需求是什么，结合现有资源，再总结我们这个版本的设计目标。

　　例如，需求是“可视化业务之间的访问情况(可视化风险)”，那么分析用户心理后，本质需求应该是“能够及时发现异常访问，及时处理”，但结合现有资源，在处理安全问题上仍有陷缺，故最后得出我们的设计目标就是“帮助用户及时发现发现安全问题，并营造安全感”。

　　b.梳理业务流程——流程设计

　　梳理业务流程时，代入同理心，分析用户为什么要进行这个任务，有哪些触点可以促使他进行这个任务，任务进行中可能会经过哪些步骤。设计流程时，先设计主线，再设计支线，使逻辑完整，标出需要设计的页面(画草图，防止后续画原型时页面缺失)。

　　在画流程图时，仅写对象到触点，到各任务步骤，再到任务结束点 ; 而不要将解决方案(具体交互形式)放入流程中，例如，“用户拖动子对象到母对象中”是含有解决方案的，应改为“用户添加子对象到母对象内”，至于“添加”这一行为，究竟是用“鼠标点击拖动”还是“点击添加按钮选择对象”，又或者是“选择子对象，再选择母对象，自动移动”等等，这些应该在草图设计中呈现，而不是在流程中叙述，防止在页面设计时被拘束。

　　c.对信息进行合理分类——信息架构设计