敏捷开发下的B端交互设计流程

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

1.需求理解

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

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

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

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

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

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

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

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

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

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

2.需求分析

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

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

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

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

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

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

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

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

B端产品往往信息繁多，架构复杂。所以对信息进行合理分类，设计一个好的信息架构十分重要。其中最重要的一点是——遵循合理的一致的规范，而这个规范也一定是围绕着我们的设计目标来的，我们最想让用户关注到什么，最想产品能解决什么问题。一是方便用户理解产品，在第一眼时就能对产品有简单的认知；二是方便后续有新功能加入时，仍能遵循原来的规范。

先根据流程整理出，完成所有任务需要的信息（并进行优先级划分），再根据遵循合理的规范分类组合（最好在信息架构中标明出）。

例如，我们的设计目标是“帮助用户及时发现发现xx问题，高效解决问题”，那么我们分类的规范则可分为“发现问题”“分析问题”“处理问题”“预防问题”几个维度来对信息进行分类。

3.原型设计

先画草图再画原型，为最终版本设计，始终围绕设计目标做设计，每个设计都应有出处，版本迭代时要注意和之前版本的融合

a.先画草图再画原型

根据流程图中标记需要出的页面，画完草图就可以和内部或产品经理讨论整体思路了。既能快速表达想法，提高效率，也能在方案有偏差时，不至于因为沉没成本高而不愿舍弃。当草图得到认可后，那么之后原型的大框架基本上就没什么问题了，这样即使原型有什么被质疑的地方，也很好缩小范围，知道要改什么具体的地方。

b.为最终版本设计

有的时候，可能因为时间的原因，有些方案就只能实现一半，而一半的效果又往往不是当前时间、资源下的最优解。于是，有些交互便会为当前情况下，做出中间版本的设计。（没错，就是之前的我）可实际上，这样的设计，并没有给未来带来任何好处，反而会徒添之后开发修改的任务量。

正确做法是: 只为最终版本设计，如果开发时间不够，那么标明目前版本的优先级，有些开发难度高且价值不大的，则放在下一版本实现。

c.始终围绕设计目标做设计

设计师进行原型设计时，通常会陷入一个误区: 做着做着，就忘了当初为什么这样做，然后深陷细节，忘记当初的设计目标。实际上，并不需要做这么多。时时反思自己的设计是不是围绕设计目标，可以防止自己做很多不必要的设计。

d.每个设计都应有出处

要理解为什么要有这些步骤，理解后台逻辑究竟能不能实现，不能想当然地做设计。理解了这些步骤的来源，来能更好地结合用户心理做更符合用户心智、更高效的设计; 理解了后台逻辑，才不会做出逻辑上极难实现的设计。

例如，“后台验证用户手机号”，是应该在“用户点击获取验证码”时验证还是在“输入验证码点击确定”后验证呢？从体验角度上，“点击获取验证码”基本上就能确认用户已成功输入了自己的手机号，理应这时验证会节省几个步骤，用户体验会更高效自然一点; 但是如果再多了解一些后台逻辑的话，可能就会发现这还存在着很多问题了。

e.版本迭代时注意和之前版本融合

一个产品是一个整体，版本迭代有新增模块时，要考虑这个模块与之前的其他模块有什么联系（做好信息架构，也可提前帮助解决这个问题）; 之前产品的惯有交互形式是怎样的; 相同类型的功能有什么联系，能不能整合; 有哪些地方是需要和之前产品保持一致的，等等。

4.多方评审

最终评审前分阶段找相关人员进行评审，陈述方案时注意自上而下表达，明确会议主题，记好会议纪要

a.最终评审前，分阶段找相关人员进行评审

在需求分析阶段，找主对接的产品经理来确认自己产出的设计思路，整体流程等大方向有没有什么问题; 在设计阶段，也要保持和内部人员以及产品经理的沟通，确认主要的原型页面，在接着细化细节，再与主对接的产品经理沟通。在这个过程中，还应积极向视觉、开发同步传递需求及设计理念。

这样与相关人员经常保持沟通，信息同步，既可以减少自己因闭门造车而在最终评审时的大返工，又可以让团队人员提前了解提前做好准备，从而提升团队效率。

b.陈述方案时注意自上而下表达

先讲大场景，再讲小分支。先简单叙述下我们的产品目标和设计目标，再说我们主要解决了哪几个场景下发生的问题。接着讲流程，先主线任务，如有时间再讲支线任务。讲页面之前，要先讲页面是怎么来的；讲页面时，不要细讲里面的内容，要在具体的详情页面中对照着讲，这样参会人更容易理解。在详述每个页面的过程中，分别描述清楚what？why？how？几点即可。

在阐述时有主次之分，重点或大的改变最开始讲，有的内容则不需要细讲，有人提出疑问或质疑时再详细解释。

c.明确会议主题

明确会议主题，是提高会议效率的首要指标。在会议前明确主题，尽量讨论具象化（有初步想法后再开会），即最好有实际的图表现出来，不然大家讨论全凭脑袋空想，且就算达成一致大家想的还不一定一样，这样开会会非常浪费时间且没有意义。

当遇到分歧或疑问时，如果是会议主题内的，能当场解决的当场解决，无法当场解决，先记录下来，会下继续讨论。如果是会议主题外的，则做好记录，会下与疑问提出人讨论。另外，在会议中看交互稿时，参会人员很容易提出细节和视觉层面的问题，此时要讲清楚这不是视觉稿，而是交互稿，主要是过内容和逻辑，不要纠结细节，具体风格、样式等内容在视觉阶段再提出。

d.记好会议纪要

现实中，一次性交付交互稿显然是不可能的，再加上需求方不时的需求变动、各职责人员站在自己角度看待问题的差异，会议上难免会产生一些分歧，导致需要改稿。所以会议上需要记好详细的会议纪要，以便对已确定的改动，交互设计师改稿后，与相关人员会下（或下次会议）再次确认；对提出的尚不明确的需求，会下及时与相关人员沟通，尽快确定。

另外，在会议上，产品经理“突发奇想”得出的新需求或要变动的需求，在未确认价值前，一定不要当场答应。可以先将内容做详细记录，在会下经过仔细评估是否合理，价值多大，与提出人再次确定后，再决定是否要改。并且所有的需求还需要产品经理们协调一致后，再做决定；若产品经理内部迟迟未确定，那可交互先行，一是从交互角度判断可不可行，可行的话先画出草图，出初步思路，再去找产品经理讨论；二是占据主动性，更有话语权。

5.项目跟进

即使已经定稿交付开发，也会有很多或细节、或实现难度、或时间资源方面的问题，所以不能一交付完就万事大吉了。毕竟最终的开发效果，根本性地决定着用户体验。实际项目中，经常有这样的情况：开发遇到问题却没有询问交互，而是自己用“自己的方式”解决。这显然是最糟糕的情况，所以为了保证最终体验，交互应主动进行项目跟进。

在这过程中，主动询问相关人员有没有遇到什么问题：交互文档中有没有什么没看明白的地方或还未考虑到的地方；设计的实现难度；如果时间紧张，那么设计的优先级是怎样……

6.修改迭代

若设计需要有小的改动，则应先找相关人员讨论，多方明确且达成一致后，再做变更，并在交互文档中最好对应的变更纪要和具体说明。最后，将相关事项发邮件给所有项目成员。如有必要，则还需集中对相关人员再进行一次会上的讲解说明。若改动较大，则放到下一版本。