从敏捷宣言理解敏捷交互设计(2)

发表于:2014-02-21来源:酷勤网作者:不详点击数: 标签:敏捷测试
图3 逐步细化的原型,不停进行用户测试 当然,这样的过程必然需要多模块(这里的模块指技能的差别)之间的融合,实现全团队的运作。 你会问我,这是否

  图3 逐步细化的原型,不停进行用户测试

  当然,这样的过程必然需要多模块(这里的模块指技能的差别)之间的融合,实现全团队的运作。

  你会问我,这是否意味着我们的交互设计师需要学会使用IIlustrtor进行视觉设计?或者视觉设计师需要学会HTML+CSS+jQuery制作高保真原型?

  是的,在很多情况下,敏捷交互设计团队中的设计师确实需要具备多种功能的T型人才──他们有专业的技能,也可以在其他方面有足够的贡献。

  分工的结果只能导致能力的停滞不前、产品视角的缺失、职能不可替代的风险、协作软的低效、沟通的浪费等等,而唯一的好处在于,可以更快和“更不被抱怨(如德鲁克说过程文档的价值在于管理抱怨)”产生一堆堆相互分裂且无法让客户挑错的文档。

  客户协作胜过合同谈判

  让我们举例说明在传统交互设计阶段出现的场景:一份标书、一份功能列表、一份到处使用的所谓用户体验调查问卷,在交互设计的开始阶段,我们和客户在一起进行“需求调研”,其实这些不重要,我们只需要对比我们之前的产品都有哪些功能可能有重复,类似产品有哪些可以借鉴,调研往往只是形式,关键还是未来的二至四周;

  然后最后一次见客户也许就是最终文档提交的那天,给客户看一套精美的PSD文档,一般我们会做出A和B方案,其中不乏我们臆想出来的需求,有时只为让那个区域看起来不那么空,客户高兴地选择了其中的一套方案后,交付正式开始。

  这就是基于合同进行设计的典型场景,谁也不知道合同中的功能列表意味着什么,而对于客户来说,它确实是购物单,真正交付时已忘记为什么需要。

  但这不妨碍交互设计师进行设计,大部分时候他们并没有仔细思考这个功能真正的使用场景,而是把它“画”出来,让它看起来很美,却不管它如何实现和如何被用户使用。

  这是基于合同进行设计自然而然的结果,在每个功能上,设计师都希望当成对自己的挑战,他们绞尽脑汁收集类似产品类似功能,尽可能取悦客户,说服他们采用更炫更丰富的交互方式,而作为不对交付负责的人他们毋须承担责任。

  而敏捷交互设计希望打破这种基于合同或者换言之,基于功能列表的设计模式。它希望在设计的全过程将客户参与进来,让客户了解某个标书上的功能也许没有意义,或者不是当下应该解决的问题──一个交付项目范围的最好确定时机就是在交互设计过程中客户的全程参与。客户参与的优势有以下几点:

  过程的透明化提升客户的安全感,随时保持对设计进度的了解;

  最好的反馈模式就是让客户亲身参与设计过程;

  了解最终用户和业务模式的是客户,客户是不可多得的资源;

  当设计结果是功能列表的重新确认,对于合同中的内容便达成了新的共识;

  客户参与的过程是建立信任的最佳机会,良好的信任关系应该在最开始就建立;

  在产品设计方向上和客户达成一致,而不是仅靠标书或者访谈结果的支言片语;

  提升参与感有助于培养更负责的客户,在交付阶段,之前的努力将会获得巨大的回报;

  有效控制设计的变化,当客户亲身参与设计决定过程时,很多盲目的设计变化会减少很多;

  图4 和客户一起进行设计

  拥抱变化胜过遵循计划

  当你的设计不能和客户一起进行,你只是个标书需求列表的简单执行者,需求的变化便是理所当然的事情。

  在有些传统交互设计流程里甚至出现“需求冻结”这样的流程──如果你已经对某个环节的文档进行进行签收,就不能在“需求冻结”后改变主意。这样的结果无非两个:一尽量不要签收那个环节的文档;二在需求没有冻结的时候抓紧机会改变主意。

  从敏捷宣言的角度来看,之前的三句话是最后一句话的基础,如果不能做到对个体和交互的尊重,把可用软件当作产生核心价值的东西,并且努力和客户进行协作,谈拥抱变化只是空话。在敏捷交互设计中,遵循同样的道理:

  对个体和交互的尊重──当需求发生变化时,因为在新的流程中对产品视角的重视,可首先对需求变化的价值进行判断,即它是不是匹配达成一致的产品视角;真正需求变化时,因为分工的模糊以及流程的简化,可更灵活地调配资源进行处理;再者因为大量使用轻量级的工具,修改成本大大降低;

  关注可工作的软件──因为我们把可进行的端到端场景测试作为敏捷交互设计过程中最重要的目标,当出现需求变化时,可通过审视变化本身“是否包含在端到端场景中?如果不产生这样的变化,用户因此有何种损失”来判断需求变化本身的价值;同时,因为能够尽早的得到端到端场景原型设计,需求本身往往来自于用户测试的结果,这样的需求变化往往是有价值的,有理可依的;

  客户协作的重要性──需求变化往往来自于客户的不确定性,很多情况下这种不确定又来自于一个新产品背后业务模式的不确定,客户协作帮助在设计过程中及早发现和解决这种来自业务方面的不确定,同时,客户协作对客户责任感的培养也大大减少了来自于客户不负责任的需求摆动。

  这就是敏捷交互设计可以很好的管理用户需求的根本原因。

  从敏捷推行到现在,在交付领域已经走向成熟,越来越多的团队开始采用敏捷方法进入开发,但从软件交付的全流程来看,早于交付的交互设计环节目前依然以传统设计方式为主。

  随着消费型软件大行其道,用户对软件使用体验的要求越来越高,同时新产品的推陈出新对快速产品设计提出新的要求,这样的背景使得传统交互设计流程不得不做出一些新的调整以拥抱更加频繁的变化,这也是为什么很多交互设计团队开始努力尝试具有敏捷价值观的敏捷交互设计进行产品设计的主要原因。

最后,让我们来比较一下传统交互设计方法和敏捷交互设计方法的区别:

传统交互设计

敏捷交互设计

没有交付团队的参与;客户参与度低;设计团队中各职能分工明确;

交互设计师、用户研究者、视觉设计师、前端开发者、客户代表、以及开发团队代表都完整参与整个交互设计的过程,并只有能力区分而弱化职责分工;

客户需求文档中的功能列表是贯穿设计过程的主线;

基于终端使用者期待体验的设计过程,往往客户功能列表只作为参考;

各自有各自对产品的理解,无法达成共识;

对产品设计方向的形成共识是贯穿整个交互设计阶段;

使用大型的交互设计软件;

鼓励使用白板、海报、贴纸、手绘等轻量级的工具;

客户只在开始和结束参与项目;

客户全程参与设计活动;

主要以文档制作为主;

主要以Workshop工作坊活动为主,高互动过程;

设计师单独和封闭工作;

设计师合作式的工作,随时把工作的产出物展示,接受反馈;

设计师能力专一;

鼓励T型人才;

缺少用户测试;

在不同精细度的原型上快速进行用户测试,迭代式演进设计;

大而全的设计;

只设计足够的交互;

远离客户以避免变化;

和客户在一起鼓励变化;

不对交付负责,肆意发挥;

对交付负责,在成本接受的范围内创新;

原文转自:http://www.kuqin.com/software-engineer/20111014/312841.html