什么是服务设计

近几年来,体验设计界有一个热门的名词,叫做“服务设计”。在第一次接触这个名词的时候,我有点摸不着头脑:

  • 它和体验设计有什么不同?
  • 它是一种新的设计方法,抑或只是对旧设计方法的一种包装?
  • 服务二字到底指的是什么?

抱着这样的疑问,我翻阅了很多书籍、文章,看了不少演讲,但非但没有让我对它更多了解,反而让我更疑惑了。似乎每个人都对服务设计有自己的解读,而且它似乎无所不包。

后来,我有一次住酒店的时候走楼梯下楼,看到坐在楼梯间休息的清洁师傅,突然明白了服务设计的意义。这次,我就跟大家谈谈什么是服务设计。

从一个用户到多个用户

作为体验设计师,我们最关注的是用户的体验。在我们看来,用户要使用一个产品,必然要达成某种目标,而我们则需要帮助他们以最快或者最舒适的方式来达成目标。

tumblr_inline_nfpbiki6BW1rxo9iy

:只有针对特定人群的设计才是体验设计

为了达到良好的体验,我们不断对用户群体进行细化,最后剩下了一个用户。我们专门为她来做设计,希望给她最佳的体验。问题在于,工具是一个人用的,但现实生活中的服务常常不止一个人参与。

比如说,“教学”这个服务就至少包括了“老师”和“学生”这样两种人参与。对于一个服务来说,二者都是“用户”,而他们的体验也都是我们关心的对象。除了教学之外,通常IT系统都存在管理员,比如以前论坛的版主,或者内部系统的网管等等。互联网产品也是如此,使用方,管理方,两种角色。

tumblr_inline_nfpc2ft9qP1rxo9iy

:一项服务往往有多个参与方

不过,虽然角色变多,但由于他们属于管理关系,相对独立,所以二者的体验通常不会有太多交集。管理者和使用者一般会使用各自的界面,也可以有针对性地地进行设计。

支撑服务的其他角色

现实生活中,要实现一项服务,参与的角色远远不止两个,而且相互之间常常会造成影响,不像理想中分割得那么清楚。

比如一个网上商城。从我们打开一个网站,找到一个商品,下单,支付,最后快递上门收到货物,其实中间要经历很多步骤,而且有很多人参与:

  • 下单之后,我们需要支付,这里面就涉及到和银行和支付机构的对接
  • 支付的钱要进入财务的系统,财务需要记账,并通知仓库备货和发货
  • 仓库人员收到货物之后,需要找到货物,打包,打印单据,准备发货,并更新库存
  • 物流公司会来取货,留下一个快递单号,仓库人员需要把快递单号和订单号对应,录入系统
  • 货物送到之后,快递状态更新,订单状态随之更新

这还仅仅是正常情况,如果要加上退货、换货的流程,或者加入赠品、套餐、促销、礼品卡等等概念,则整个流程会更加复杂。它的复杂不在于步骤的多少,而在于需要多次和第三方进行合作,用户的行为也不可控。整个流程中出现任何问题,都会对用户——那个我们称之为“最终用户”(end user)的人造成麻烦,导致体验变差。

tumblr_inline_nfpcs54wMZ1rxo9iy

:用户体验是服务最重要的部分,但也只是其中一小部分(粉色 = 用户体验相关;橙色 = 服务运营相关)

如果单从体验设计的角度来看,也许我们的目光会集中在商城的商品列表、展示、支付和搜索等等页面,大不了再加上管理端的设计。这样的设计也许看上去体验很好,但有可能会造成其他部分的麻烦,或者遇到实施方面的问题,又或者根本就无法落实。

所以,我们必须注意角色和需求之间的搭配,平衡,哪些地方该标准化,哪些地方不能标准化,使整个服务能够完善起来。

领域内外专家的配合

也许看到这里,你已经知道当时我是怎么“顿悟”的了。

我因为工作的关系经常都会出差,所以也常常会住酒店。作为一名住客,又是做体验设计的,所以我会对酒店的楼层、房间、装修、设备等等比较敏感。不过,我通常只会看到最后的结果,也就是我亲自会接触和使用的部分。

在楼梯间看到休息的师傅之后,我意识到:每天房间都会有师傅来打扫,但实际上并不是换个床单和洗漱用品那么简单。

tumblr_inline_nfpdc2DoHK1rxo9iy

:酒店房间的清洁这样简单的事情也需要一个服务体系的支撑

换下来的毛巾和床单如果要清洗,那么就必然涉及到一个洗衣房。这个洗衣房如果是内部经营,那么就还会涉及到大型洗涤设备、操作人员、洗涤剂、排污和环卫措施、设备维护保养,等等。除了洗涤,还有晾晒,还有储存,消毒等等一系列的工作需要做。如果是和外部合作,又会涉及到运输,等待时间,质量保障,财务来往,等等。

最后一步,才是给房间换上清洁的毛巾和床单。

洗漱用品也是如此。向哪家供应商订购,如何运输,如何确保质量,如何储存,库存如何清算……有了这些,才有最后师傅来更换的那一步。

所有这些都是整个酒店生态体系中的节点。虽然“客户体验”的重要性不言而喻,但它其实只是这个生态体系中的一个层面。要设计这样一个生态体系,就必须对整个生态体系和流程有比较深入的了解,也就是所谓的领域知识。

领域知识包括了有形和无形的经验。有形的经验,比如对流程的理解,对服务中各方的需要和诉求的理解,对行业标准和现状的理解等等。这些知识容易落成文字和传授,也相对容易学到。还有就是无形的经验,比如对异常状况的处理,对服务中各方“脾性”的了解从而能采取合适的行动,等等。

我们可以用个很简单的例子来理解无形的经验。在使用一款手机之后,我们往往会发现它有一些小问题,比如点击了某个图标之后,会有一秒钟左右的黑屏,但用久了之后就明白了它这个脾性。手机有脾性,同理,服务的参与方也有脾性。对这些细节的了解累积起来,就形成了深厚的隐式知识(tacit knowledge),难以言传,但是遇到之后却能够从容应对。

掌握充分领域知识的人我们称之为领域专家。要设计一个服务,有一个服务所在领域的专家是很有必要的,因为领域专家知道这个领域的基本原则和边界,可以及早发现问题。否则,做出来的设计很可能无法落地或者难以实现。

tumblr_inline_nfpdjnH6xp1rxo9iy

:他可不是专业做音乐播放器的,或者手机的,或者手表的,或者……

不过,由领域专家来牵头做设计也会有很大的局限性。领域专家一般在一个领域扎根,这就有可能导致思维的固化。我们可以看看各个行业的创新者,那些体验好的产品往往是“局外人”提出。没有了原来的既有观念和条条框框,往往能做出好的设计。苹果公司做音乐播放器,踏入了索尼 Walkman 的领域,做手机,又踏入了诺基亚和微软的市场,但都“搅局”成功,就是很好的例子。

总结

tumblr_inline_nfpdwxzCCp1rxo9iy

:服务设计意味着视角的转变和提升

在一开始,我们谈产品或者系统设计,站在产品、系统、服务本身的角度来看设计(“房间干不干净?”)。后来,我们开始谈体验设计,转换成用户视角,站在用户的角度来看设计(“肥皂是不是年轻客人喜欢的品牌?”)。继续发展下去,体验设计都跟上之后,就应该转向做服务设计了——站在上帝视角,俯视和规划整个服务的运转,以满足多方需求,使整个服务体系达到平衡(“酒店能不能持续稳定地兑现口号宣传的承诺?”)。

要设计好的服务,就需要领域专家和体验设计师以及其他非领域专家的合作。我想,这也是为什么我们经常听到平面设计师、互动设计师、体验设计师,却很少听到“服务设计师”——因为这事根本不能成为一个职业,必须由一个团队来做。

tumblr_inline_nfox9rB1561rxo9iy

:1988 年,十二届三中全会的代表参观北京第一家超市——京华超市

虽然服务设计听上去很有意思,真正把服务设计当成一个议题,是最近才开始的事——这也正常,因为服务设计需要成熟的用户体验文化,并需要有很多领域专家。要知道,中国出现真正意义上的现代零售业,是 1984 年的第一家超市。出现现代的快递服务,是 1993 年。也就是说,很多行业都还很新,而且还有很多古老的行业(比如酒店业)正在经历革新。用户体验也是上世纪 90 年代才提出来的理念。

经历了几十年的发展之后,领域专家开始出现。有了互联网和一众互联网公司的强力推动,用户体验的理念也开始铺开。二者结合之下,相信服务设计会逐渐迎来春天,成为接下来设计公司的重要业务。

Share

创业提案的逻辑

最近花了大量时间在自己新的内部创业项目,免不了给各种不同的人(内部或外部)进行商业提案(Business Proposal)的工作,同时也在帮助湾区一些社会企业包装面向投资人的Pitch,结合以往大量商业合作项目的经验,我重新思考了商业提案的逻辑,相信无论提案的规模、内部或者外部、创业或者商业项目,一个合理的逻辑都是必不可少,希望这个总结能给你帮助。

不确定未来的要素

“投资人”(广义上的,可以是侠义上的投资者、也可以是你的客户和高层管理者)真正投资的是“不确定的未来”,在这份“不确定的未来”里实际上只有两个要素:

  1. 创始人:你和你的团队(即创始人)可能不能适应市场的要求快速和持续的成长;
  2. 市场:客户、客户需求、竞争、技术可能不按照当初设想的方式发展。

事实上,我并没有把产品放在其中,是因为,产品是内部团队对外部市场需求的答案,投资人在首次投资并不要求给出完整而详细的答案,在目前这个阶段它只是让投资人:

  1. 对“不确定未来的”创始人更加有信心:产品的方案部分(Solution)代表了创始人团队对市场需求的回应;
  2. 对“不确定未来的”市场更加有信心:产品的需求(Need)部分市场需求进行了具体化和细分。

对于投资人而言,Pitch结束后更好的结果应该是:

  1. 我对你们有信心;
  2. 我对你们所针对的市场有信心;
  3. 对于你们的产品形态,相信一个好的市场和优秀的你们会慢慢寻找到一个稳定成长的方向。

因此,过分强调现有产品可能喧宾夺主(创始人和市场)、完全忽视产品的描述也有可能减分。

完美逻辑

任何一次创业都是将市场、创始人、投资人三者之间关联,它体现着四种核心关系:

  1. 创始人用产品回应市场机会;
  2. 投资人要求创始人设计商业模式;
  3. 市场给予投资人回报;
  4. 为使得创始人能够运行产品、产生商业模式、最终从市场中获得回报,投资人需要投资。

因此对这四种关系的解答就是一个Pitch的精要,它分作以下7个步骤:

  1. 市场:你面对怎样一个市场?趋势、用户、习惯、需求、竞争、技术等;
  2. 产品:你的产品形态如何?目标用户、场景、功能、定位、竞品、模式、技术等;
  3. 创始人:为什么你和你的团队可以规划、创造、运营这个产品?经验、能力、资源、性格等;
  4. 商业模式:凭什么说这个产品可以带来商业价值?公司结构和治理、收入结构、支出结构、财务预测等;
  5. 投资人:为什么我要投你?投资组合、优势、战略、互补等;
  6. 投资:你需要投资多少?投资形式、合作方式、Burn Rate等;
  7. 回报:我可预期的回报是什么?回报形式、时间、风险等。

事实上,一个短时间的Pitch不可能完全完美回答以上所有这些内容,但是一个好的逻辑顺序引领投资人朝你所期待的方向前进,并帮助你或和你共同回答商业模式、投资、和回报三个问题。

一个好的逻辑顺序

一个好的Pitch永远是故事,你的听众是投资人,你的目标是将投资人拉入到你和市场的这个环中:

在这里,“商业模式”、“投资”、和“回报”不是你最擅长的,却是投资人最关系的三个问题:

  1. 怎么赚钱?
  2. 投多少?
  3. 挣多少?

一个好的逻辑顺序让你避开你最不擅长的领域,而把最吸引人的部分放在了前面所提到的“不确定未来的两个要素”:你(即创始人)和市场。这里我使用最多的逻辑是为以下:

  1. 趋势:市场发生了什么样的趋势?
  2. 人:趋势中人们发生了什么变化?产生了什么需求?
  3. 问题:需求和方案之间存在什么问题?
  4. 方案:我们如何解决这个问题?
  5. 独特处:我们方案的独特处是什么?
  6. 我们:我们是谁?
  7. 目标:我们要做什么?
  8. 状态:我们在做什么?
  9. 资源:我们需要什么资源?
  10. 计划:我们将如何使用资源?

通常一次Pitch的时间可能不超过30分钟,为了保证最后还有10分钟的交流时间,建议每点只用一张幻灯片讲2分钟,幻灯片尽可能视觉化和情景化,例如抽象层次的产品使用场景,而不用出现交互图。

再比如高度抽象化、结合图标设计的目标定义:

此外,根据使用场景的不同,例如投资人2分钟的快速沟通,我们还可以将其简略成五个逻辑,即:

  1. 解决什么问题?
  2. 怎么解决?
  3. 有何不同?
  4. 在做了什么?
  5. 还需要什么?

以一个社交性共享餐饮服务的模式做例子,一个两分钟的快速Pitch逻辑可以是:

用搭伙做饭的方式解决都市人中喜欢下厨的人的社交需求,它采用线上到线下的方式撮合和招揽食客,核心特点是基于一个200人的核心厨师群进行拓展,目前核心厨师群正在完成第50次主题家庭餐会,积累超过2000位食客群,需要场地和资金建设线下的旗舰厨房作为概念店。

如果我们只有30秒,我们该如何表达这个逻辑呢?

我们帮爱做饭的人寻找厨友和食客,有200个核心厨师加盟、2000食客、50次餐会,现在找地方找钱建线下概念店。

你看,越简单的逻辑越不出现解决方案,只告诉你我们在帮助谁?帮助什么?我们做了什么?我们要什么?这是不是比那种“我有一个想法”式的表述更加打动人?

最后,作为创始人,Pitch也许是每天在不同场合发生的事情,手上应该有适合2小时、30分钟、2分钟、30秒不同时长进行的口头表达,同时也有从30页PPT、5页PPT、移动端网站、名片等不同介质的平面表达。一个顺畅的逻辑表达(无论是口头还是平面)也让你更加清晰你和你的创始人团队、以及你所面对的市场,它也可以用来帮助招募早期和合伙人。

写在最后

打动投资人的是你展现的一个“有利可图”的不确定未来,里面是一个“有利可图”的团队,加一个“有利可图”的市场,同时在创业初期,我们不可能把市场、创始人团队、以及投资人所相互关联的逻辑关系彻底厘清,我们需要的是一个能够反复练习的逻辑,熟记在心,并在任何时候表达出来,随时接受挑战、并反复打磨。

我做业务分析师的时候,有这么一句话,“讲都讲不明白的需求十有八九是没必要做的”,那么讲都讲不通顺的创业逻辑,意味什么?最后的最后,一千次创业者热血沸腾的说道,也比不过一条从头到尾的逻辑。

Share

架构腐化之谜

前言

新技术层出不穷。过去十年时间里,我们经历了许多激动人心的新技术,包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境,缩短了产品和项目的面世时间。然而作为在软件行业第一线工作多年的从业者,我们却不得不面对一个现实,那就是当初采用新技术的乐趣随着项目周期的增长而迅速减少。无论当初的选择多么光鲜,半年、一年之后,只要这个项目依然活跃,业务在扩张——越来越多的功能需要加入,一些公共的问题就会逐渐显露出来。构建过慢,完成新功能让你痛不欲生,团队成员无法很快融入,文档无法及时更新等等。

在长期运转的项目中,架构的腐化是怎么产生的?为什么常见的面向对象技术无法解决这类问题?如何延缓架构的腐化?

本文将尝试解释这一切,并提出相应的解决方案。读者需要具备相当的开发经验——至少在同一个项目的开发上一年以上;公司负责架构演进、产品演进的角色会从本文找到灵感。

架构

架构这个词在各种场合不断地以各种面目表现出来。从维基百科的词条看来,我们经常听到的有插件架构(Plugin),以数据库为中心的架构(Database Centric),模型-视图-控制器架构(MVC),面向服务的架构(SOA),三层模型(Three-Tier model),模型驱动架构(MDA)等等等等。奇妙的是,这些词越大,实际的开发者就越痛苦。SOA很好——但在它提出的那个年代,带给开发者的只是面向厂商虚无缥缈的“公共数据类型”;MDA甚至都没有机会沦为新一轮令人笑话的CASE工具。

在继续阅读之前,读者不妨问自己一个问题:在长期的项目中,这些大词是否真的切实给你带来过好处?更为功利的问题是:你,作为战斗在一线的开发者,在长期项目中可曾有过美好的体验?

技术的演变与挥之不去的痛

企业应用的发展似乎从十年前开始腾飞。从Microsoft ASP/LAMP(Linux、Apache、MySQL、PHP)年代开始,各种企业应用纷纷向浏览器迁移。经过十年的发展,目前阵营已经百花齐放。与过去不同,现在的技术不仅仅在编程语言方面,常见的编程套路、最佳实践、方法学、社区,都是各种技术独特拥有的。目前占据主流的阵营有:

 

  • Rails
  • Java EE平台。值得一提的是Java VM已经成为一种新的宿主平台,Scala、JRuby更为活跃并引人瞩目
  • LAMP平台。Linux/MySQL/Apache并没有多少变化,PHP社区从Rails社区获得了不少养分,出现了许多更加优秀的开发框架
  • Microsoft .NET平台
  • Django

没有理由对这些新技术不感到振奋。它们解决了许多它们出现之前的问题。在它们的网站上都宣称各种生产效率如何之高的广告语,类似于15分钟创建一个博客应用;2分钟快速教程等等。比起过去21天才能学会XXX,现在它们在上手难度上早已大幅度降低。

需要泼冷水的是,本文开篇提出的问题,在上述任何一种技术下,都如幽灵般挥之不去。采用Ruby on Rails的某高效团队在10人团队工作半年之后,构建时间从当初的2分钟变成2小时;我们之前采用Microsoft .NET 3.5 (C# 3.0)的一个项目,在产生2万行代码的时候,构建时间已经超过半小时;我们的一些客户,工作在10年的Java代码库上——他们竭尽全力,保持技术栈与时俱进:Spring、Hibernate、Struts等,面对的困境是他们需要同时打开72个项目才能在Eclipse中获得编译;由于编译打包时间过长,他们去掉了大部分的单元测试——带来巨大的质量风险。

如果你真的在一个长期的项目工作过,你应该清楚地了解到,这种痛苦,似乎不是任何一种框架能够根本性解决的。这些新时代的框架解决了大部分显而易见的问题,然而在一个长期项目中所面对的问题,它们无能为力。

一步一步:架构是如何腐化的

无论架构师在任何时代以何种绚丽的方式描述架构,开发中的项目不会超出下图所示:

architecture1

基本架构示意

一些基本的准则:

  • 为了降低耦合,系统应当以恰当的方式进行分层。目前最经考验的分层是MVC+Service。
  • 为了提供基础的访问,一些基本的、平台级别的API应该被引入。用Spring之类的框架来做这件事情。
  • 用AOP进行横向切分业务层面共性的操作,例如日志、权限等。
  • 为了保证项目正常构建,你还需要数据库、持续集成服务器,以及对应的与环境无关的构建脚本和数据库迁移脚本。

阶段1

满足这个条件的架构在初期是非常令人愉悦的。上一部分我们描述的框架都符合这种架构。这个阶段开发非常快:IDE打开很快,开发功能完成很快,团队这个时候往往规模较小,交流也没有问题。所有人都很高兴——因为用了新技术,因为这个架构是如此的简单、清晰、有效。

阶段2

好日子不算太长。

很快你的老板(或者客户,随便什么)有一揽子的想法要在这个团队实现。工作有条不紊的展开。更多的功能加入进来,更多的团队成员也加入了进来。新加入的功能也按照之前的架构方式开发着;新加入的团队成员也对清晰的架构表示欣喜,也一丝不苟的遵循着。用不了多久——也许是三个月,或者更短,你会发现代码库变成下面的样子:

architecture2

正常开发之后

你也许很快会意识到这其中有什么问题。但你很难意识到这到底意味着什么。常见的动作往往围绕着重构——将纵向相关的抽取出来,形成一个新的项目;横向相关的抽取出来,形成一个名叫common或者base的项目。

无论你做什么类型的重构,一些变化在悄悄产生(也许只是快慢的不同)。构建过程不可避免的变长。从刚开始的一两分钟变成好几分钟,到十几分钟。通过重构构建脚本,去掉那些不需要的部分,构建时间会降到几分钟,你满意了,于是继续。

阶段3

更多的功能、更多的成员加入了。构建时间又变长了。随着加载代码的增多,IDE也慢了下来;交流也多了起来——不是所有人能够了解所有代码了。在某些时候,一个很有道德的程序员尝试重构一部分重复逻辑,发现牵涉的代码太多了,好多都是他看不懂的业务,于是他放弃了。更多的人这么做了,代码库越来越臃肿,最终没有一个人能够搞清楚系统具体是怎么工作的了。

系统在混乱的状态下继续缓慢地混乱——这个过程远比本文写作的时间要长很多,之间会有反复,但据我观察,在不超过1年的时间内,无论采用何种技术框架,应用何种架构,这个过程似乎是不可抗拒的宿命。

常见的解决方案

我们并非是坐以待毙的。身边优秀的同事们在问题发现之前采取了各种解决方案。常见的解决方案如下:

升级工作环境

没有什么比一台与时俱进的电脑更能激励开发人员了。最多每隔三年,升级一次开发人员的电脑——升级到当时最好的配置,能够大幅度的提升生产效率,激励开发人员。反过来,利用过时的电脑,在慢速的机器上进行开发,带来的不仅仅是客观上开发效率的降低,更大程度上带来的是开发人员心理上的懈怠。

升级的工作环境不仅仅是电脑,还包括工作的空间。良好的,促进沟通的空间(以及工作方式)能够促进问题的发现从而减少问题的产生。隔断不适合开发。

分阶段的构建

一般而言,构建的顺序是:本地构建确保所有的功能运行正常,然后提交等待持续集成工作正常。本地构建超过5分钟的时候就变得难以忍受;大多数情况下你希望这个反馈时间越短越好。项目的初期往往会运行所有的步骤:编译所有代码,运行所有测试。随着项目周期的变长,代码的增多,时间会越来越长。在尝试若干次重构构建脚本再也没办法优化之后,“分阶段构建”成为绝大多数的选择。通过合理的拆分、分层,每次运行特定的步骤,例如只运行特定的测试、只构建必要的部分;然后提交,让持续集成服务器运行所有的步骤。这样开发者能够继续进行后续的工作。

分布式构建

即便本地快了起来,采用分阶段构建的团队很快发现,CI服务器的构建时间也越来越让人不满意。每次提交半小时之后才能得到构建结果太不可接受了。各种各样的分布式技术被创建出来。除了常见的CI服务器本身提供的能力,许多团队也发明了自己的分布式技术,他们往往能够将代码分布到多台机器进行编译和运行测试。这种解决方案能够在比较长的一段时间内生效——当构建变慢的时候,只需要调整分布策略,让构建过程运行在更多的集群机器上,就可以显著的减少构建时间。

采用JRebel或者Spork

一些新的工具能够显著地提速开发人员的工作。JRebel能够将需要编译的Java语言变成修改、保存立即生效,减少了大量的修改、保存、重新编译、部署的时间;Spork能够启动一个Server,将RSpec测试相关的代码缓存于其中,这样在运行RSpec测试的时候就不用重新进行加载,极大提升了效率。

到底是什么问题?

上述的解决方案在特定的时间域内很好地解决了一部分问题。然而,在项目运转一年,两年或者更久,它们最终依然无法避免构建时间变长、开发变慢、代码变得混乱、架构晦涩难懂、新人难以上手等问题。到底问题的症结是什么?

人们喜欢简洁。但这更多的看起来是一个谎言——没有多少团队能够自始至终保持简洁。人们喜欢简洁只是因为这个难以做到。并不是说人们不愿意如此。很多人都知道软件开发不比其他的劳动力密集型的行业——人越多,产量越大。《人月神话》中已经提到,项目增加更多的人,在提升工作产出的同时,也产生了混乱。短期内,这些混乱能够被团队通过各种形式消化;但从长期看来,随着团队人员的变动(新人加入,老人离开),以及人正常自然的遗忘曲线,代码库会逐渐失控,混乱无法被消化,而项目并不会停止,新功能不断的加入,架构就在一天天的过程中被腐蚀。

人的理解总有一个边界,而需求和功能不会——今天的功能总比昨天的多;这个版本的功能总比上个版本的多。而在长时间的开发中,忘记之前的代码是正常的;忘记某些约定也是正常的。形成某些小而不经意的错误是正常的,在巨大的代码库中,这些小错误被忽视也是正常的。这些不断积攒的小小的不一致、错误,随着时间的积累,最终变得难以控制。

很少有人注意到,规模的变大才是导致架构腐化的根源——因果关系在时空上的不连续,使得人们并不能从其中获得经验,只是一再重复这个悲剧的循环。

解决方案

解决方案的终极目标是:在混乱发生之前,在我们的认知出现障碍之前,就将项目的规模控制在一定范围之内。这并不容易。大多数团队都有相当的交付压力。大多数的业务用户并没有意识到,往一个项目/产品毫无节制地增加需求只会导致产品的崩溃。看看Lotus Notes,你就知道产品最终会多么令人费解、难以使用。我们这里主要讨论的是技术方案。业务上你也需要始终对需求的增长保持警惕。

0. 采用新技术

这可能是最廉价的、最容易采用的方案。新技术的产生往往为了解决某些特定的问题,它们往往是经验的集合。学习,理解这些新技术能够极大程度减少过去为了完成某些技术目标而进行的必要的经验积累过程。就像武侠小说中经常有离奇遭遇的主人公突然获得某个世外高人多年的内力一样,这些新技术能够迅速帮助团队从某些特定的痛点中解脱出来。

已经有足够多的例子来证明这一观点。在Spring出现之前,开发者的基本上只能遵循J2EE模式文档中的各种实践,来构建自己的系统。有一些简单的框架能够帮助这一过程,但总体来说,在处理今天看起来很基础的如数据库连接,异常管理,系统分层等等方面,还有很多手工的工作要做。Spring出现之后,你不需要花费很多精力,很快就能得到一个系统分层良好、大部分设施已经准备就绪的基础。这为减少代码库容量以及解决可能出现的低级Bug提供了帮助。

Rails则是另外一个极端的例子。Rails带来的不仅仅是开发的便利,还带来了人们在Linux世界多年的部署经验。数据库Migration, Apache + FastCGI或者nginx+passenger,这些过去看起来复杂异常的技术在Rails中变得无足轻重——稍懂命令行的人即可进行部署。

任何一个组织都无法全部拥有这些新技术。因此作为软件从业者,需要不断地保持对技术社区的关注。闭门造车只能加速架构的腐化——特别是这些自己的发明在开源社区早已有成熟的方案的时候。在那些貌似光鲜的产品背后,实际上有着无数的失败的案例成功的经验在支撑。

我们曾经有一个项目。在意识到需求可能转向类似于key-value的文档数据库之后,团队大胆的尝试采用SQLServer 2008的XML能力,在SQL Server内部实现了类似于No-SQL的数据库。这是一个新的发明,创造者初期很兴奋,终于有机会做不同的事情了。然而随着项目的进行,越来越多的需求出现了:Migration的支持、监控、管理工具的支持、文档、性能等等。随着项目的进展,最终发现这些能力与时下流行的MongoDB是如此的相似 ——MongoDB已经解决了大多数的问题。这个时候,代码库已经有相当的规模了——而这部分的代码,让许多团队成员费解;在一年之后,大约只有2个人能够了解其实现过程。如果在早期采用MongoDB,团队本有机会摒弃大部分相关的工作。

值得一提的是,高傲的开发者往往对新技术不够耐心;或者说对新技术的能力或局限缺乏足够耐心去了解。每一个产品都有其针对的问题域,对于问题域之外,新技术往往没有成熟到能够应对的地步。开发者需要不断地阅读、思考、参与,来验证自己的问题域是否与其匹配。浅尝辄止不是好的态度,也阻碍了新技术在团队内的推广。

新技术的选型往往发生在项目/产品特定的时期,如开始阶段,某个特定的痛点时期。日常阶段,开发者仍然需要保持对代码库的关注。下一条,重构到物理隔离的组件则是对不断增大的代码库另一种解决方案。

1. 重构到物理隔离的组件

显而易见的趋势是,对于同一个产品而言,需求总是不断增多的。去年有100个功能,今年就有200个。去年有10万行代码,今年也许就有20万行。去年2G 内存的机器能够正常开发,今年似乎得加倍才行。去年有15个开发人员,今年就到30个了。去年构建一次最多15–20分钟,今年就得1个小时了,还得整个分布式的。

有人会注意到代码的设计问题,孜孜不倦地进行着重构;有人会注意到构建变慢的问题,不懈地改进着构建时间。然而很少有人注意到代码库的变大才是问题的根源。很多常规的策略往往是针对组织的:例如将代码库按照功能模块划分(例如ABC功能之类)或者按层次划分(例如持久层、表现层),但这些拆分之后的项目依然存在于开发人员的工作空间中。无论项目如何组织,开发者都需要打开所有的项目才能完成编译和运行过程。我曾经见到一个团队需要在Visual Studio中打开120个项目;我自己也经历过需要在Eclipse中打开72个项目才能完成编译。

解决方案是物理隔离这些组件。就像团队在使用Spring/Hibernate/Asp.NET MVC/ActiveRecord这些库的时候,不用将它们对应的源代码放到工作空间进行编译一样,团队也可以将稳定工作的代码单元整理出来形成对应的库,标记版本然后直接引用二进制文件。

在不同的技术平台上有着不同的方案。Java世界有历史悠久的Maven库,能够良好的将不同版本的 JAR以及他们的以来进行管理;.NET比较遗憾,这方面真正成熟的什么也没有——但参考Maven的实现,团队自己造一个也不是难事(可能比较困难的是与MSBuild的集成);Ruby/Rails世界则有著名的gem/bundler系统。将自己整理出来的比较独立的模块不要放到rails/lib /中,整理出来,形成一个新的gem,对其进行依赖引用(团队内需要搭建自己的gems库)。

同时,代码库也需要进行大刀阔斧的整改。之前的代码结构可能如下,(这里以SVN为例,因为SVN有明确的trunk/branches/tags目录结构。git/hg类似)

svn-old1

原来的库结构

改进之后,将会如下图所示:

svn-new1

改进的库结构

每个模块都有属于自己的代码库,拥有自己的独立的升级和发布周期,甚至有自己的文档。

这一方案看起来很容易理解,但在实际操作过程中则困难重重。团队运转很长一段时间之后,很少有人去关心模块之间的依赖。一旦要拆分出来,去分析几十上百个现存项目之间的依赖相当费劲。最简单的处理办法是,检查代码库的提交记录,例如最近3个月之内某个模块就没有人提交过,那么这个模块基本上就可以拿出来形成二进制依赖了。

很多开源产品都是通过这个过程形成的,例如Spring(请参考阅读《J2EE设计开发编程指南》,Rod Johnson基本上阐述了整个Spring的设计思路来源)。一旦团队开始这样去思考,每隔一段时间重新审视代码库,你会发现核心代码库不可能失控,同时也获得了一组设计良好、工作稳定的组件。

2. 将独立的模块放入独立的进程

上面的解决方案核心原则只有一条:始终将核心代码库控制在团队可以理解的范围内。如果运转良好,能够很大程度上解决架构因为代码规模变大而腐化的问题。然而该解决方案只解决了在系统在静态层面的隔离。当隔离出的模块越来越多,系统也因此也需要越来越多的依赖来运行。这部分依赖在运行期分为两类:一类是类似于 Spring/Hibernate/Apache Commons之类的,系统运行的基础,运行期这些必须存在;另外一类是相对独立的业务功能,例如缓存的读取,电子商城的支付模块等。

第二类依赖则可以更进一步:将其放到独立的进程中。现在稍具规模的系统,登录、注销功能已经从应用中脱离而出,要么采用SSO的方案来进行登陆,要么则干脆代理给别的登陆系统。LiveJournal团队在开发过程中,发现缓存的读写实际上可以放到独立的进程中进行(而不是类似EhCache的方案,直接运行于所在的运行环境中),于是发明了现在鼎鼎有名的memcached. 我们之前进行的一个项目中,发现支付模块完全能够独立出来,于是将其进行隔离,形成了一个新的、没有界面的、永远在运行的系统,通过REST处理支付请求。在另外一个出版项目中,我们发现编辑编写报告的过程实际上与报告发行过程虽然存在类级别的重用,但在业务层面是独立的。最终我们将报告发行过程做成了一个常驻服务,系统其他的模块通过MQ消息与其进行交互。

这一解决方案应该不难理解。与解决方案1不同的是,这一方案更多的是要对系统进行面向业务层面的思考。由于系统将会以独立的进程来运行这一模块,在不同的进程中可能存在一定的代码重复。例如Spring同时存在两个不相关的项目中大家觉得没什么大不了的;但如果是自己的某个业务组件同时在同一个项目的两个进程中重复,许多人就有些洁癖不可接受了。(题外话:这种洁癖在OSGi环境中也存在)这里需要提醒的是:当处于不同的进程时,它们在物理上、运行时上已经彻底隔离了。必须以进程的观点去思考整个架构,而不是简单的物理结构。

从单进程模型到多进程模型的架构思维转变也不太容易——需要架构师有意识的加强这方面的练习。流行的.NET和Java世界倾向于把什么都放到一起。而 Linux世界Rails/Django则能更好的平衡优秀产品之间的进程协调。例如memcached的使用。另外,现在多核环境越来越多,与其费尽心思在编程语言层面上不如享受多核的好处,多进程能够简单并且显著地利用多核能力。

3. 形成高度松散耦合的平台+应用

现在将眼光看更远一些。想象一下我们在做一个类似于开心网、Facebook、人人网的系统。它们的共同特点是能够接入几乎无限的第三方应用,无论是买卖朋友这类简单的应用,还是绚丽无比的各种社交游戏。神奇的是,实现这一点并不需要第三方应用的开发者采用跟它们一样的技术平台,也不需要服务端提供无限的运算能力——大部分的架构由开发方来控制。

在企业应用中实现这个并不难。这其中的秘诀在于:当用户通过Facebook访问某个第三方应用的时候,Facebook实际上通过后台去访问了第三方应用,将当前用户的信息(以及好友信息)通过HTTP POST送到第三方应用指定的服务网址,然后将应用的HTML结果渲染到当前页面中。某种意义上说,这种技术本质上是一种服务器端的mashup. (详情参考InfoQ 文章

facebook

Facebook App架构

这种架构的优点在于极度的分布式。从外观上看起来一致的系统,实际由若干个耦合极低、技术架构完全不同的小应用组成。它们不需要被部署在同一台机器上,可以单独地开发、升级、优化。一个应用的瘫痪不影响整个系统的运行;每个应用的自行升级对整个系统也完全没有影响。

这并非是终极的解决方案,只在某些特定的条件下有效。当系统规模上非常庞大,例如由若干个子系统组成;界面基本一致;子系统之间关联较少。针对这个前提,可以考虑采用这种架构。抽象出极少的、真正有效公用的信息,在系统之间通过HTTP POST.。其他的系统完全可以独立开发、部署,甚至针对应用访问的情况进行特定的部署优化。如果不这么做,动辄上百万千万行的代码堆在一个系统中,随着时间的推移,开发者逐渐对代码失控,架构的腐化是迟早的事情。

例如,银行的财务系统,包括了十多个个子系统,包括薪资、资产、报表等等模块,每一部分功能都相对独立并且复杂。整个系统如果按照这种方式拆分,就能够实现单点优化而无需重新启动整个应用。针对每个应用,开发者能够在更小的代码内采用自己熟悉的技术方案,从而减少架构腐化的可能。

结语

没有糟糕的架构,变化使之

我访问过很多团队。在很多项目开始的时候,他们花很多时间在选择用何种技术体系,何种架构,乃至何种IDE。就像小孩子选择自己钟爱的玩具,我相信无论过程如何,团队最终都会欣然选择他们所选择的,并且坚信他们的选择没有错误。事实也确实如此。在项目的开始阶段很难有真正的架构挑战。困难的地方在于,随着时间的增长,人们会忘记;有很多的人加入,他们需要理解旧代码的同时完成新功能;每一次代码量的突破,都会引起架构的不适应;这些不适应包括:新功能引入变得困难,新人难以迅速上手;构建时间变长等等。这些能否引起团队的警觉,并且采取结构性的解决方案而不是临时性的。

关于文档

很多人说敏捷不提倡文档。他们说文档很难写。他们说开发人员写不了文档。于是就没有文档。

奇怪的是我看到的情况却不是这样。程序写得优秀的人,写起文字来也很不错。ThoughtBlogs上绝大多数都是程序员,很多人的文字写得都很赞。

而项目中的文档往往少得可怜。新人来了总是一头雾水。令人奇怪的是,新人能够一天或者两天之内通过阅读RSpec或者JBehave迅速了解这些工具的使用,到了团队里面却没有了文档。

抛开项目持续运转并交付的特性不谈,我认为巨大的、不稳定的代码库是文档迅速失效的根源。如果我们能够按照上述的解决方案,将代码库缩小,那么独立出来的模块或者应用就有机会在更小的范围内具备更独特的价值。想象一下现在的Rails3/Spring框架,他们往往有超过20个第三方依赖,我们却没有觉得理解困难,最重要的原因是依赖隔离之后,这些模块有了独立的文档可以学习。

企业级项目也可以如此。

创建应用程序的生态环境,而非单一的项目

功能总是不断的、不断的加到同一个产品中。这毫不奇怪。然而通过我们前面的分析,我们应当重新思考这个常识。是创建一个日益庞大的、缓慢的、毫无生机的产品,还是将其有机分解,成为一个生机勃勃的具有不同依赖的生态系统?项目的各方人员(包括业务用户、架构师、开发者)应当从短视的眼光中走出来,着眼于创建可持续的应用程序生态系统。

关于作者

陈金洲,Buffalo Ajax Framework作者,ThoughtWorks中国公司首席咨询师,现居西安。目前的工作主要集中在RichClient开发,同时一直对Web可用性进行观察,并对其实现保持兴趣。


本文原文发表于InfoQ:http://www.infoq.com/cn/articles/cjz-architecture-corruption

Share

从敏捷宣言理解敏捷交互设计

本文原文发表于InfoQ:http://www.infoq.com/cn/articles/xzc-agile-interaction-design

敏捷交互设计是敏捷方法论向交互设计领域的延伸,它提倡让所有相关人参与到设计过程中,迭代演进式地进行交互设计。从2010年开始,已经有越来越的团队在不同程度上使用敏捷交互设计的方法,而放弃了流程化的传统产品设计过程。

事实上,敏捷交互设计方法在很多方面都充分体现了敏捷价值观,因此,理解敏捷交互设计实践的最好方法是从记录在敏捷宣言中的价值观开始。

个体和交互胜过流程和工具

一个传统交互设计的流程一般分成以下几个步骤进行:

  1. 任务分析:任务分析基于功能列表(一般来自于客户的功能说明书)──在功能性需求的基础上拆分出人物流程和场景;
  2. 页面流程:根据任务分析的结果,为每一个大任务下的子任务中覆盖的功能制作页面流程;
  3. 信息建模:根据页面流程的设计出一套完整的信息框架,满足用户所有功能性需求;
  4. 原型设计:基于信息建模,设计出低保真原型,交给美工进行页面美化;
  5. 视觉设计:基于原型设计,对页面进行美化,最终产出高保真原型,同时编写设计说明;

在传统流程中,我们可以看到非常细致的分工──产品经理负责功能的拆解和分类,以及页面流转;交互设计师设计信息架构和具体交互行为;视觉设计师负责美化页面;前端开发人员负责高保真原型。

你是否体看见了传统瀑布式开发的影子?弊端显而易见:

  1. 分工造成的局限性──每个人都用自己的视角进行工作,无法形成统一的产品视角(Vision);
  2. 分工造成的“不可评价性”──你没权利对产品经理的功能拆解有异义,因为你不是这方面的专家;
  3. 需求在传递中产生了失真的风险──需要靠大量文档进行记录;
  4. 客户没法说不──当客户需要到整个流程的最后看到一个或者两个大而全的设计方案时,他无法提出任何有价值的反馈,这本身就是用一个贵重的半成品绑架客户;

跟软件交付中的敏捷实践一样,敏捷交互设计倡导全功能团队,避免过于明显的分工,和基于分工特有的流程。仅有的流程是基于产品逐步清晰化的过程,而非基于人员的技能,所有人都应该参与到这个过程中来。敏捷交互设计主要分以下几个步骤:

  1. 寻找产品方向(Inspire):抛开需求列表,从目标人群的期待体验出发,寻找可能存在的产品方向;
  2. 定位产品需求(Identify):定位本产品需要提供什么样的消费者体验;
  3. 设计产品体验(Ideate):对决定的目标体验进行设计;
  4. 验证产品设计(Implement):快速制作原型,并频繁进行用户测试,迭代式改进。

图1. 从体验中寻找交付范围,把功能列表放在一边

除了流程简化和分工融合,在工具的选择上,敏捷交互设计也与传统方式有所不同──对于交互的推崇高于对特定工具的选择。

所有在敏捷交互设计中使用的工具,都应该遵循一条原则:它必须推动设计团队成员间的交互,而不是简单提升单个成员的工作效率。

基于此,敏捷交互设计中推崇各种轻量级工具,而不是大型的第三方软件,例如纸质原型Paper Protityping而非Visio或Axure此类原型工具。过于精细的结果往往会增加协作和反馈的门槛,虽然可能提升单个成员工作效率,却达不到鼓励交互的目的。

图2. 使用轻量级的工具进行交互设计

可工作的软件胜过完备的文档

敏捷软件交付过程中,每个迭代的核心产出是不足够完美,但却满足一个完整业务场景的软件──端到端流程的可完成,而不需要面面俱到的完美。

而传统开发方式中在长时间内只是各个功能模块中功能的堆砌,无法在短时间内实现端到端场景,那么文档便成为串联各个功能保证有序开发的必需品。

传统交互设计也存在这个问题。往往一个标准交互设计阶段的文档分三个方面,它们是:

  1. 内容方面(Content):内容的层次和整体信息架构设计;
  2. 视觉方面(Visual):整站风格的视觉设计文档;
  3. 交互方面(Interaction):整站高保真交互设计原型;

仔细分析这些文档的生产过程,我们不难发现以下特点:

  1. 它们都是以整站为目标,试图覆盖所有使用场景;
  2. 它们的生产过程是线性的,直到三者全部完成才能够指导开发;
  3. 正因为每个环节的过程是孤立的,无法形成统一的认识,文档传递经常发生失真;
  4. 一个完美的东西很难得到产品方向性的关键反馈;

敏捷交互设计试图在解决以上问题。

敏捷交付的核心在于尽早地交付出可进行端到端测试的代码,而非完备文档,而敏捷交互设计的核心则在于尽早地交付出可以进行端到端可测试的原型,同样亦非完备文档。

而这里说的“端到端可测试的原型”包含以下含义:

  1. 端到端:必须设计出符合合理使用场景的端到端流程,这个流程会覆盖一个典型用户最核心的使用场景,所有的交互设计应该第一时间收敛在这个端到端场景周围,而非“整站”功能的分割展示;
  2. 可测试原型:不需要完美的原型,只需要所设计端到端场景中涉及到的原型,同时,原型的完备性上必须达到内容、视觉、交互三者细致力度一致,在测试中,三者力度的不一致往往会隐藏问题,例如,如果测试的原型视觉上过于完美,就会减弱用户在交互上的关注;

假设我们把交互设计的四周拆分成每周一个迭代,每周交付一个覆盖端到端场景,且在内容、视觉和交互方面都相对完备的原型收集反馈或进行测试,和传统项目相比,我们是否可以更早地得到客户反馈,是否可以让设计过程更透明,是否毋须完备的过程文档?答案自然是肯定的。

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

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

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

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

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

客户协作胜过合同谈判

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

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

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

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

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

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

  1. 过程的透明化提升客户的安全感,随时保持对设计进度的了解;
  2. 最好的反馈模式就是让客户亲身参与设计过程;
  3. 了解最终用户和业务模式的是客户,客户是不可多得的资源;
  4. 当设计结果是功能列表的重新确认,对于合同中的内容便达成了新的共识;
  5. 客户参与的过程是建立信任的最佳机会,良好的信任关系应该在最开始就建立;
  6. 在产品设计方向上和客户达成一致,而不是仅靠标书或者访谈结果的支言片语;
  7. 提升参与感有助于培养更负责的客户,在交付阶段,之前的努力将会获得巨大的回报;
  8. 有效控制设计的变化,当客户亲身参与设计决定过程时,很多盲目的设计变化会减少很多;

拥抱变化胜过遵循计划

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

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

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

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

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

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

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

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

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

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

传统交互设计 敏捷交互设计
没有交付团队的参与;客户参与度低;设计团队中各职能分工明确; 交互设计师、用户研究者、视觉设计师、前端开发者、客户代表、以及开发团队代表都完整参与整个交互设计的过程,并只有能力区分而弱化职责分工;
客户需求文档中的功能列表是贯穿设计过程的主线; 基于终端使用者期待体验的设计过程,往往客户功能列表只作为参考;
各自有各自对产品的理解,无法达成共识; 对产品设计方向的形成共识是贯穿整个交互设计阶段;
使用大型的交互设计软件; 鼓励使用白板、海报、贴纸、手绘等轻量级的工具;
客户只在开始和结束参与项目; 客户全程参与设计活动;
主要以文档制作为主; 主要以Workshop工作坊活动为主,高互动过程;
设计师单独和封闭工作; 设计师合作式的工作,随时把工作的产出物展示,接受反馈;
设计师能力专一; 鼓励T型人才;
缺少用户测试; 在不同精细度的原型上快速进行用户测试,迭代式演进设计;
大而全的设计; 只设计足够的交互;
远离客户以避免变化; 和客户在一起鼓励变化;
不对交付负责,肆意发挥; 对交付负责,在成本接受的范围内创新;

感谢张凯峰对本文的审校。

本文原文发表于InfoQ:http://www.infoq.com/cn/articles/xzc-agile-interaction-design

Share