实践总结敏捷开发下的端交互设计流程

　　纸上得来终觉浅，绝知此事要躬行。本文由实践经验总结而来。
　　交互设计师在这整个流程中，需要主动推动项目的进展，积极沟通，充分协作。在需求阶段充分了解需求，设计阶段不断与产品经理（需求方）及相关人员（视觉、开发等）沟通，开发阶段积极传递设计目标及效果，有变更及时通知。尽量保证整个团队的信息同步，才有可能高品质地实现敏捷开发。
　　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。修改迭代
　　若设计需要有小的改动，则应先找相关人员讨论，多方明确且达成一致后，再做变更，并在交互文档中最好对应的变更纪要和具体说明。最后，将相关事项发邮件给所有项目成员。如有必要，则还需集中对相关人员再进行一次会上的讲解说明。若改动较大，则放到下一版本。