《用户体验设计导论》第10章 迭代开发与平衡用户需求

用户体验设计导论IntroductiontoUserExperienceDesign第十章迭代开发与平衡用户需求王晨升，陈亮编著.用户体验设计导论[M]，机械工业出版社，2020.09.内容CONTENTS01平衡系统开发02开发模式与平衡迭代开发03平衡迭代方法的应用平衡系统开发Balancedsystemdevelopment01平衡系统开发平衡系统（Equilibriumsystem）指处于平衡态的系统，它来自热力学的概念；相应地，不处于平衡态的系统叫非平衡系统。在这里，平衡系统开发是指兼顾产品各个相关方的利益均衡的设计与开发方法。理论上，产品开发过程的唯一宗旨是以用户为中心、以追求良好的用户体验为目标的，这是设计师的责任，也是设计所追求的理想。但在现实中大多数产品一般不仅要考虑用户利益，还同时需要考虑公司的盈利等因素，有时候公司的盈利还有可能成为主导的因素。这时用户价值和公司利益就成了不得不面对的一对矛盾。要妥善处理好这对矛盾，就需要兼顾多方面关联因素的平衡。例如在引导设计中，用户需求与产品目标之间的平衡系统是确保兼顾各方利益的多赢选择（图10-1）。图10-1引导设计的平衡系统平衡系统开发在网站设计中，不仅要满足用户和开发商，还要满足另一个利益相关者，即广告合作伙伴。这就像是三类利益相关者在进行一场持续不断的拔河比赛，其拉力决定了最终产品的优先级的分布。如果任何一方拉力过大（优先级高），那么其他两方都会受到削弱（图10-2）。在新产品开发中，各种相关因素也往往是相互影响、相互作用，复杂到令人望而生畏，需要有一套系统的方法来整合发现的问题和创造解决的方案，既关注单个要素同时又不忽略整体，这就要求找到一种更适合的开发模式----即平衡系统开发。图10-2影响产品优先级别的拉力开发模式与平衡迭代开发常用开发模式及其适用范围平衡迭代开发的概念平衡迭代开发的过程Developmentpatternsandbalancediterativedevelopment02常用开发模式及其适用范围1．边做边改模型（Build-and-FixModel）。在边做边改模型中，既没有规格说明，也没有系统设计，软件随着客户的需要一次又一次地不断被修改；开发人员拿到项目后立即根据需求编写程序，调试通过后生成软件的第一个版本；在提供给用户使用后，如果程序出现错误或用户提出新的要求，开发人员重新修改代码，直到用户和测试都满意为止。事实上，现在许多产品实际都是使用“边做边改”模型来开发的，特别是很多小公司，在产品周期压缩的太短时这种模型应用的较多。这种类似小作坊的开发方式的优点是前期出成效快。这对编写逻辑不需要太严谨的小程序来说还可以对付得过去，但对任何规模开发来说都是不能令人满意的。主要问题在于：缺少规划和设计环节，软件的结构随着不断的修改越来越糟，最终可能导致无法继续修改；忽略了需求分析环节，给软件开发带来很大的风险；没有考虑测试和程序的可维护性，也没有任何文档，软件的后期维护会十分困难。因为边做边改模型没有包括编码前的开发阶段，所以它不被认为是一个完整的生命周期模型。然而在某些场合这种简单的方式却非常实用。比如对于需求简单明了、软件期望的功能行为容易定义、实现的成功或失败又容易检验的工程，可以使用这种模型。常用开发模式及其适用范围2．瀑布模型（WaterfallModel），是指将软件生存周期的各项活动规定为按固定顺序所连接的若干阶段，形如瀑布流水，最终得到软件产品。它是由美国计算机专家温斯顿•罗伊斯（WinstonWalkerRoyce，1929年～1995年）于1970年提出的，直到八十年代早期，一直是唯一被广泛采用的一种软件开发模型。瀑布模型是一个项目开发架构，其开发过程是通过一系列设计阶段而顺序展开的，它将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如瀑布流水逐级下落，由此得名。在此模型中，开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容；当前活动的工作结果需要进行验证，如通过则该结果将作为下一项活动的输入，继续进行下一项活动；否则返回修改（图10-3）。图10-3瀑布模型示例常用开发模式及其适用范围3．迭代模型（Stage-wiseModel），也称迭代增量式开发或迭代进化式开发模型，包括从需求分析到产品发布（稳定、可执行的产品版本）的全部开发活动。它出现于二十世纪五十年代末期，是有理统一过程（RationalUnifiedProcess，RUP）推荐的周期模型，其背景是赫伯特•贝宁顿（HerbertD.Benington）领导的美国空军SAGE（theSemi-AutomaticGroundEnvironment）项目。在经历了许多瀑布模型项目的失败之后，美国国防部从1994年的开始积极地鼓励采用更加现代化的迭代模型来取代瀑布模型。在迭代模型中，整个开发工作被组织为一系列短小、固定长度（如3周）的小项目，构成一系列的迭代；每一次迭代都包括了需求分析、设计、实现与测试等步骤；开发工作可以在需求被完整地确定之前启动，每一次迭代中完成系统的一部分功能或业务逻辑的开发；再通过客户的反馈来细化需求，并开始新一轮的迭代（图10-4）。图10-4迭代模型示例常用开发模式及其适用范围4．快速原型模型（RapidPrototypeModel），又称原型模型，是在开发真实系统之前构造一个原型，并在此基础上逐渐完成整个系统的开发。它是增量模型的另一种形式。快速原型模型的第一步是建造一个快速原型，实现未来的用户与系统的交互；然后用户对原型进行评价，给出具体改进意见，进一步细化软件需求，通过逐步调整原型使其满足客户的要求，开发人员也可从中确定客户的真正需求是什么；第二步是在第一步的基础上，对软件进行完善，待用户认可后进行完整的实现及测试，直至开发出客户满意的产品（图9-5）。图9-5快速原型模型常用开发模式及其适用范围5．增量模型（IncrementalModel），采用随着日程的进展而交错的线性序列，每一个线性序列产生产品的一个可发布的“增量”。它融合了瀑布模型的基本成分和原型实现的迭代特征。增量模型中产品被作为一系列的增量模块来设计、实现、集成和测试，每一个模块都是由多种相互关联的组件所形成的提供特定功能的零部件所构成；在各个阶段并不交付一个完整的产品，而仅是满足客户需求的一个子集的可展示模块。早期的增量是最终产品的“可拆卸”版本，它不仅提供了用户要求的功能，并且为用户提供了评估的平台（图10-6）。图10-6增量模型示例常用开发模式及其适用范围6．螺旋模型（SpiralModel），是一种软件开发的过程模型，它兼顾了快速原型的迭代特征及瀑布模型的系统化与严格监控，是由美国计算机学家巴利•玻姆（BarryW.Boehm，1935年～）于1988年提出的，它强调了其他模型所忽视的风险分析，是一种风险驱动的方法，特别适合于大型复杂的系统的开发。螺旋模型以进化的开发方式为核心，在每个项目阶段使用瀑布模型法；每一个周期都包括制定计划、风险分析、实施工程和客户评估等四个阶段；产品开发过程每迭代一次，就又前进一个层次（图10-7）。螺旋模型只适用于大规模软件项目，优点包括设计上的灵活性；成本计算变得简单容易；客户始终参与，能够和设计师有效地沟通；确保客户认可；其缺点有让用户确信这种演化方法的结果是可以控制的有一定难度；开发周期较长，会造成技术和工具上的落伍，从而又导致新的需求差异的产生。图10-7螺旋模型常用开发模式及其适用范围7．敏捷开发（AgileDevelopment），是指以用户的需求进化为核心，采用迭代、循序渐进的方法进行产品开发的方法。敏捷开发把一个大项目分为多个相互联系但又可以独立运行的小项目，并分别完成；在此过程中产品整体一直处于可使用状态。敏捷开发方式的技术核心是敏捷建模（AgileModeling，AM），主要驱动核心是人，其价值观包括沟通、简单、反馈、勇气和谦逊。敏捷开发团队主要的工作方式可以归纳为：作为一个整体工作、按短迭代周期开发、每次迭代交付一些成果、关注业务优先级和检查与调整等。敏捷开发的实施（图10-8）包括测试驱动开发、持续集成、重构、结对工作、站立会议、小版本发布、较少的文档、以合作为中心、现场客户评价、阶段测试与评估和可调整计划等内容。敏捷开发中通过一次一次的迭代、小版本的发布，大大提升了开发效率；这样的分阶段开发、小周期迭代也使得根据客户反馈、随时做出相应的调整和变化成为可能（图10-8）。其优点是“适应性（Adaptive）”的、“面向人（People-oriented）”的等；缺点是需特别注意项目规模的控制，不适合大的团队开发。图10-8敏捷开发的技术路线常用开发模式及其适用范围8．演化模型（EvolutionaryModel），是全局的产品生命周期模型，可以被看作是“迭代”执行的多个“瀑布模型”；主要针对事先不能完整定义需求的产品的开发，属于迭代开发方法中的一种，可以表示为：第一次迭代（需求、设计、实现、测试、集成）→反馈→第二次迭代（需求、设计、实现、测试、集成）→反馈→……直至系统完成。每一个迭代过程为整个系统增加一个可定义的、可管理的子集（图10-9）。在开发模式上，演化模型采取分批循环开发的办法，每次循环开发一部分的功能，它们成为产品原型的新增功能，于是就不断地演化出新的系统。演化模型每个开发循环以六周到八周时长为宜。优点包括任何功能一经开发就能进入测试、能帮助引导出高质量的产品要求、便于风险管理、能均衡整个开发过程的负荷；有利于提高质量与效率；无论何时都有一个具有部分功能、可工作的产品；鼓舞士气、验证测试及时、便于销售提前展开；其缺点包括产品需求变化带来总体设计的困难；缺乏严格的过程管理；易形成心理懈怠；用户对半成品的使用可能造成负面影响等。图10-9演化模型示例常用开发模式及其适用范围9．喷泉模型（FountainModel），也称面向对象的生存期模型、面向对象（ObjectOriented，O-O）模型，是一种以用户需求为动力、以对象为驱动的模型，是由美国学者布瑞恩•塞勒斯（BrianHenderson-Sellers）和朱利安•爱德华兹（JulianM.Edwards）于1993年提出的，主要用于描述面向对象的软件开发过程。模型中软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，而且在项目的整个生存期中还可以嵌入子生存期，类似一个喷泉，可以落在中间，也可以落在最底部；各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其它任何开发阶段中的遗漏。喷泉模型体现了迭代和无间隙的特征，如分析、设计和编码之间没有明显的界限；在编码之前进行需求分析和设计，期间添加有关功能使系统得以演化；系统某个部分常常被重复多次，相关对象在每次迭代中随之加入渐进的系统；由于对象概念的引入，需求分析、设计、实现等活动只用对象类和关系来表达，从而可以较为容易地实现活动的迭代和无间隙，并使得开发过程自然地包含复用。改进的喷泉模型，以喷泉模型为基础，可以尽早地、全面地展开测试，同时将测试工作进行迭代（图10-10）。图10-10改进的喷泉模型常用开发模式及其适用范围10．智能模型（IntelligentModel），也称基于知识的软件开发模型、第四代技术，它把瀑布模型和专家系统结合在一起，将以软件工程知识为基础的生成规则构成的知识系统与包含领域知识规则的专家系统相结合，组成这一应用领域软件的开发系统（图10-11）。智能模型适用于特定领域软件和专家决策系统的开发，它拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高级图形功能及电子表格等），每个工具都能使开发人员在抽象层次上定义软件的某些特性，并把这些特性自动地生成为源代码，这需要第四代语言（4GL）的支持。智能模型的必要性包括能解决特定领域的复杂问题、以知识作为处理对象、强调数据的含义等。图10-11智能模型示例常用开发模式及其适用范围11．RUP模型（RationalUnifiedProcess，RUP），也称统一软件开发过程，是一种面向对象且基于网络的程序开发方法论；具有迭代、用例驱动和以架构为中心的特点，是一种重量级过程（也被称作厚方法学），特别适用于大型软件团队、大型项目的开发。RUP有9个核心工作流，其中6个过程工作流（CoreProcessWorkflows）包括商业建模、需求、分析和设计、实现、测试和部署；3个支持工作流（CoreSupportingWorkflows）是配置和变更管理、项目管理及环境。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。RUP模型是一种过程模板，定义了角色、活动和工件等核心概念（图9-12）；其由四个顺序的阶段来实现，即初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）；每个阶段结束于一个主要的里程碑（MajorMilestones），结尾时执行一次评估，满意才可以进入下一个阶段（图9-13）。RUP中的每个阶段可以进一步分解为迭代，增量式地发展直到成为最终的系统。图9-12RUP核心概念图9-13RUP的迭代模型常用开发模式及其适用范围12．混合模型（HybridModel），又称元模型（Meta-model）、过程开发模型，它把几种不同模型组合成一种，并允许一个项目能沿着最有效的路径发展。混合模型具有灵活机动、适用面广、给开发者最大自由去选择自己熟悉的模型组合等优点；缺点是针对性较差，模型使用效果深度依赖于开发者的水平。平衡迭代开发的概念平衡迭代开发是指在产品开发的过程中，始终关注来自各相关方的约束因素，兼顾各方的诉求，不断创建、检查、继而重建平衡的解决方案，通过持续迭代，一直到通过一致、定期和可预见的方式、同时满足各方对产品的约束为止。以图9-2所示的产品因素为例，用户、广告商和生产厂商（公司）等不同方面对产品的成功往往有不同的理解。1．用户心中的好产品。产品的最终用户体验是产品成功的基石。尽管出色的用户体验并不是确保产品成功的唯一因素，但糟糕的用户体验绝对是导致产品失败的“快车道”。但体验质量往往不是非“0”即“1”的二进制，有时候平庸的用户体验实际上比彻底的失败更糟糕，甚至可能会成为整个商业风险中最为严重的问题。用户心中好的产品包括有好的功能、有效性、符合用户期望。平衡迭代开发的概念2．公司对好产品的定义。除了非盈利公益性公司，所有其他类型的公司进行产品开发根本目的在于盈利。一个公司衡量产品是否成功，通常有两种方式，一是利润；二是产品能否服务于从整体上提升公司品牌价值。这也是公司对好产品的定义。3．广告商追求的成功。广告商是产品推向市场过程中不可或缺的一个环节，扮演了企业与市场桥梁的作用。在互联网高度普及的今天，广告商用流量（Traffic）和知名度（Awareness）来衡量效果。用户、公司企业和广告商对成功产品的定义差异，正是平衡系统开发必要性之所在。平衡迭代开发的过程考虑图9-2给出的三个因素之间的平衡，利用迭代开发模型来实现产品的开发，既要包含通过周期性数据开发而逐渐完善的内在思想，又要反映各要素间影响力的均衡，其背后的核心过程可以归纳成三个基本阶段（图10-14）：1．检查。本步骤试图定义问题以及受影响的各个方面，包括提出问题、分析需求、收集信息、进行研究，同时评估在平衡各要素的影响的前提下可能的解决方案；列出长处和短处，并分出优先级别（因素影响权重）；研究客户需求和开发能力，评估现有产品或原型。2．定义。确定解决方案。在该阶段，随着不断发现目标受众的真实需要及自身能力，产品变化的更详细细节逐渐被刻画出来。3．构建。执行解决方案计划。该阶段最花钱、也最费时，如果既没有检查阶段收集到的数据支持又没有定义阶段的仔细规划，创建阶段所完成的大部分工作将都是浪费。产品需求涉及的各因素的影响权重的平衡，是确定解决方案的关键。产品的每个部分都是权衡的结果，而权衡寓于在产品创建过程中；几乎每次权衡都会改变产品的基本特点：如有些权衡会导致产品发展成为专供某一群人使用；有些会导致产品朝着盈利的方向发展；而有些则会诱使人们更渴望使用产品。理想的权衡是引导产品同时在这三个方向上发展。图10-14平衡迭代开发：平衡各要素，边开发边调整平衡迭代开发的过程体验设计的方法和前述开发模式的思想都可以应用于平衡迭代开发的任意阶段。用户体验出现在螺旋开发的每个起点处，随着问题的出现而提供解决答案。在初期，收集用户背景资料，研究用户所做的工作，描述他们的问题；然后按照人们的愿望或者需要的程度排出特性的优先级别；确定优先级别后，什么类型的人群会要产品、产品能为他们做什么、他们应该了解什么、记住什么，这些就都一清二楚了。在对细节进行设计和测试时，只需要知道唯一要关注的事情是如何展现的，而不用再关注人们的需要或者产品功能，因为这些因素都已经彻底研究过了。图10-15是一个平衡迭代开发螺旋的示例，其中情景调查、焦点小组、可用性测试和日志文件分析等，都被融入到平衡开发的各个迭代阶段，成为开发螺旋不可分割的组成部分。在实践中，不同的项目在各个阶段的任务可能会有所不同，但是这种周期式迭代、螺旋式上升、逐步接近完善的思想应贯穿于平衡迭代开发的整个过程。而且，作为平衡迭代开发的核心，平衡的思想也应同用户体验观一样融入整个开发过程中。图10-15平衡迭代开发螺旋平衡迭代开发方法的应用Applicationofbalancediterativedevelopmentmethods03平衡迭代开发方法的应用下面以日程安排服务为例，来说明平衡迭代开发方法的应用。本例经过简化和理想化，旨在说明平衡迭代开发过程能对产品产生哪些作用，或与实际或有出入，但足以解释方法应用的概貌。【例】假设因为有了某种易于适应的后台技术，某公司想要开发一个基于互联网的约会日程安排产品。其平衡开发迭代过程如下：◆第一轮1．检查。最初将目标受众假设为大忙人，他们长期出差，需要方便访问的高级日程安排工具包；产品收入是来自服务所带来的广告以及高级特性的订阅费。平衡迭代开发方法的应用在第一轮研究中，需拜访很多大忙人，观察他们如何管理日程。你发现大忙人用现有技术安排工作日程非常顺畅，他们通常不愿意使用新技术，除非新技术比正在使用的技术更好用；他们宁愿不早使用新技术，除非他们知道值得这么做，同时也掌握新技术的使用；他们十分在乎服务和互联网整体的可靠性，譬如说在很忙的一天却因为断线而无法上网，这将是一场灾难。通常这样的调研结果说明目标市场对你的产品没兴趣，除非你的产品能打败现有的产品。这会导致你的产品只对一部分市场有吸引力，无法带来足够收入，开发成本无法消化。有一种方法可能为产品找到更大的市场，前提是假设你决定继续开发原有市场，但会采用不同的策略，如被访者可能有几个人表示有兴趣将日程安排解决方案用于社交生活，而不是用于工作。这些都说明这类受众有以下特点：

•他们的个人日程表几乎和工作日程表一样复杂；

•他们需要与朋友和家人共享个人日程表；

•他们无法在公司防火墙外使用办公软件，而且家人和朋友也不可能访问到；

•现有日程安排软件看起来都完全关注在上午的日程安排任务。2．定义。意识到这些情况后，你决定将目标受众锁定为繁忙的执行官，但想法有所改变以更好适应他们的生活方式；功能重点转为个人日程表共享；产品描述需要重写，目标锁定为帮助人们以明显优于现有方法的方式来共享日程表。产品描述详细定义了需要解决的问题，并明确列出了目标之外的问题。同时重新定位市场营销和产品形象策划，将精力集中于该服务的个人特质上。3．创建。采用新问题的定义，重写产品描述以反映日程安排子应用工具的新用途，以及对受众需求的重新认识。该阶段的大部分时间应该用在创建产品所提供的特性以及优点的详细清单上；同时还需要同开发团队一起检查清单，确保所提供的特性在软件开发的能力范围之内；此外，还需要创建初步研究计划，列出需要回答的问题、需要调查的市场以及下一轮研究需要关注的地方。平衡迭代开发方法的应用平衡迭代开发方法的应用◆第二轮1．检查。把产品描述带给由繁忙的执行官组成的几个焦点小组后，你发现他们虽然很欣赏通过互联网共享日程表的想法，但他们担心安全问题；此外，他们认为这类系统最重要的部分是能快速输入信息，共享也需要很便捷；有人可能说，每天用共享日程表花五分钟就能搞定所有事情，这反映了他们的期望；他们还可能提到其它功能，如把朋友、同事的日程表跟家人的日程表单独分开，能自动获得特别活动的日程表等。2．定义。虽然核心想法很明确，但需要解决若干关键功能需求才能确保系统成功。软件目标中增加了安全性、输入速度提高和日程组织这三个需求，并传达给产品营销团队。3．创建。根据这些想法，重新定义解决方案：日程安排系统采用“层”的方式，人们可以在常规日程表上增加层；这些层可以是家人日程表、共享的业务日程表或电视节目和体育比赛、广告内容等，后者不仅利用了日程表的个人性质，而且能带来潜在的收入来源；修改系统描述以包括此功能，并解决焦点小组提到的问题。平衡迭代开发方法的应用◆第三轮1．检查。你担心“每天五分钟”的要求是否可以实现。非正规可用性测试表明，很难做到每天用5分钟就能搞定一天的日程表，但如果人们渴望这种感觉，就应该要满足他们；你决定进一步展开研究，了解人们在个人日程表上真正会花多少时间，日程安排管理中是否存在共同的趋势；比如使用情景调查法观察六个日程表管理，你发现他们平均每天要花费20分钟----而不是5分钟----来处理个人日程表；他们最头痛的地方是不知道整个家庭的日程表，也无法从被邀请人那得到是否参加活动的确认；了解到不管在什么地方，他们平均每天要检查3到10次日程表，这便为每天可能的广告展示次数提供了参数；通过几位用户的意见，你还发现产品还有另外两个潜在市场：青少年和医生。青少年日程表复杂、涉及人多；而医生出诊要花很多时间来安排日程，如确定日程安排以及提醒预约病人；你还对主要受众目标进行实地调查，挖掘他们确切的技术能力和愿望、常用哪些相关产品和媒体等。结果发现，他们在家里通常有几台新型电脑，整个家庭共用这些电脑，但每次只有一位家庭成员上网。你认为这说明所有家庭成员需要一种简单方式来使用日程安排服务，同时又不会看到其他人的日程表。2．定义和创建。和前两轮一样，你需要完善产品目标。目标中加入了日程表共享、家庭日程表及确认。然后，你创建了系统概要设计，能实现所有这些目标；然后再写一份详细的系统描述。平衡迭代开发方法的应用◆第四轮1．检查。调查时还发现，你所感兴趣的家庭中每人至少有一部手机，而且使用频繁，他们对体育比赛感兴趣，也看许多电视节目。因此你决定再进行一轮焦点小组调研，以了解人们是否会对服务的手机界面版本有兴趣、需不需要用“层”来显示运动比赛和电视时间表（两者都是吸引广告市场的潜在目标）。某个焦点小组可能说，日程表共享及确认是目标受众最想要的东西，而家庭日程安排和特别活动特性虽然很想要、很酷，但不是那么重要；手机界面版本很有趣，但有上网手机的人大多从未用过手机上网，他们担心会发生尴尬和困惑的事情；你发现青少年认为共享个人日程表很不错，特别是在他们可以安排即时消息提醒和聊天、可以用手机访问日程表的时候；医生----上一轮研究建议的受众，业务发展