当前位置:首页 >  站长 >  交互设计 >  正文

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

  2017-09-14 15:50  来源:人人都是产品经理  我来投稿  我要评论

  开抢了!双11创业者优选服务!

  纸上得来终觉浅,绝知此事要躬行。本文由实践经验总结而来。

  

 

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

  

 

  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.修改迭代

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

  作者:丸子圆,目前大四在读,喜爱交互和心理学,欢迎前来交流指导。

    点赞0 投稿指南 实力品牌 企业会员 责任编辑:西瓜
    作者:

    A5品牌宝

    信息推荐

    扫一扫关注最新创业资讯