敏捷用户体验下如何实现设计和开发两条线平行前进-过程改进-火龙果软件

敏捷用户体验下如何实现设计和开发两条线平行前进

来源：《卓望》杂志发布于 2016-11-17

2209 次浏览

【摘要】设计和开发两条线，平行前进。设计师和开发员基于各自承担的部分，结对工作。这样需要设计师、开发员、尤其是企业、产品的拥有者，变得比原来更加的灵活。

在互联网行业中，用户体验与开发总是一组成对出现的名词，工作中有着千丝万缕的关联。互联网产品的特点决定了其必须关注用户使用的感受和体验，而又需要快速开发、迭代来占领市场和用户，并进行不断的优化改进，然而在用户体验和开发人员眼中，他们各自的角色却大有不同：在用户体验人员眼中，开发人员是技术导向，忽略用户使用感受；在开发人员眼中用户体验流程长、时间久、应变弱。二者之间似乎是一对矛盾体，如图1。那么，如何解决这对矛盾？让产品诞生的更加顺畅？我们开始了一条探寻敏捷用户体验之路。

1.敏捷用户体验的由来

1.1软件开发的历程回顾

软件开发起初普遍使用的是传统的瀑布式开发，它套用传统的工业生产。但它自身的特征致使它不适应软件产业的快速更新换代。为了更好地适应变化，渐渐发展起来一种新的方式--敏捷式开发。

敏捷开发是一种以人为核心、叠代、循序渐进的开发方法，在敏捷开发中，软件项目的构建被切分成多个相互联系、但可独立运行的子项目，并分别完成。各个子项目的成果都经过测试，具备集成和可运行的特征。在此过程中软件一直处于可使用状态。敏捷开发具有适应变化、面向人而不是过程的特点，因而受到了行业的肯定，越来越广泛地被使用。

1.2瀑布式开发和敏捷式开发的对比

摘自《Human-centered design meets Agile Development》，Maria Giudice, CEO and Founder, Hot Studio, Inc.

1.3敏捷用户体验的产生

首先，软件行业最能感受到用户体验提升带来的收益，极为重视用户体验。其次，软件行业的发展可谓争分夺秒，敏捷开发应用广泛。随着开发流程不断加速，传统用户研究方法已无法适应当前的需求。再次，敏捷开发需要用户体验。大多数企业普遍采用的方法是设立多个比较可行的方向，逐一尝试，成本较高，而做什么、怎么做，用户的需求是根本。最后，用户体验能带给敏捷开发一些解决方法。Jeff Patton(敏捷思想和UCD思想的集大成者)认为，用户体验解决了对于开发团队成功与否至关重要的几个问题：

1)用户体验强调了使用需求的必要性，必须要满足用户的需求目标；

2)用户体验可帮助识别并确认软件必要的功能；

3)通过不同程度的手段，可以使用户体验方法和敏捷方法相容而不相斥。

1.4三个敏捷用户体验观点

1.41观点一：分段结合，如图2图2 , “分段结合”敏捷用户体验概念

摘自《Human-centered design meets Agile Development》

分段结合的敏捷用户体验，项目前期仍然是传统用户体验流程，直到设计框架和关键页面出来，采用敏捷开发，将设计的迭代修改嵌入开发迭代循环中。在这个阶段，设计是可以被修正的，但不会出现巨大的推翻性的颠覆如图3。

相关案例一

以实际项目为例，来看用户体验是如何适应敏捷开发的。该项目处在开发阶段，为新产品的开发做用户体验优化，整体的解决方案还是经过传统的全流程方式得出，如图4。

1、第一轮测试，开始于单一模块的功能基本可用（阿尔法版本）；

2、单模块测试，一般6-8人，1小时/人左右；

3、版本基本稳定（贝塔版本），开始第二轮单模块测试；

4、样机产出后，进行整机测试。

该项目的不足之处在于没有形成一个完整的循环周期。用研和设计并肩而行，但没有配合开发的步调，用户体验的成果没与开发衔接起来，开发成果也不能即时地拿去做测试。其值得借鉴之处在于，集中全员沟通，使用问题列表，不断跟踪进度。每个问题对应具体的开发版本、危险级别等，且必须对应一个负责解决的人，问题的解决与否作为一个状态随时更新。

1.42观点二：整体拆分重组，如图5图5，“整体拆分重组”敏捷用户体验概念

基于敏捷的特点，将用户体验的研究和设计部分拆分为多个小项目，用研、设计、开发三条线平行、交叉、有序地进行。

相关案例二：The Ladders的敏捷探索之路

The ladders是一家求职网站公司，其网站开发执行团队包括产品经理、开发人员和用户体验人员。执行团队致力于the ladders网站的优化和支撑，随着开发团队从瀑布式开发向敏捷转型，用户体验团队也随之进入“敏捷转型”。

第一次尝试：9个月压缩成2个星期

使用敏捷策略，包括：

-保持同样的流程、版本切换和交付物，将项目规模变小但仍连续工作。

-用“用户故事”代替功能规格说明，用线框图定义规格说明。

-用叠代板展示项目信息，定义需求文件（故事版），项目计划（优先级）、资源分配（标识谁在做什么）和状态指示器（插针、颜色、对勾等）。

-为了跟踪全局，撰写一个高层次可视化文档（本质上是一个工作流）来评估每个改变。图7敏捷策略

第一次尝试以失败告终，成功的只是把截止日期提前了，虽然使用了敏捷的策略，但合作方式和沟通没有改善，团队的单个成员没有发挥足够的主动性，不能把握全局。

第二次尝试：引进两个武器

1.引入风格指南（模板）

减少开发重复元素的时间，缩短设计时间，注意力集中在核心的体验问题上；降低设计平台，允许非专业交互设计师，用组件库建立输出。

2.原型软件adobe fireworks

这个软件能快速实现原型设计，用临时性的代码，要表现体验而不是拆分框架图。

以上两个武器，为项目赢得了时间。第二次尝试，成功！

第三次尝试：将用户体验嵌入迭代周期

1）经过几次尝试，成功定制了一系列原则，来帮助用户研究嵌入迭代周期。

-一次测试不超过三个用户，目标是清除障碍

-一周做一次测试，在每周的同一天、同一时间

-什么准备好就给用户测试什么（从纸质原型到代码、草图）

-邀请每一个人参加这次会议（开发人员、产品经理和管理层等）

2）每周两次的设计评审

评审会为设计人员提供了有奋斗方向的里程碑，精简流程为设计赢得了时间。第三次尝试，成功！

第四次尝试：建立团队协作

通过“跨界工作室”的方式，将跨职能的人集中在一起，每位成员必须画草图来表达解决问题的想法，在白板上展示各自的方案，并说出优点。其他成员基于每个方案的优点和解决问题的能力对方案进行批判。重复三次过程，每一轮加强方案的保真度。每个人都会看到自己的观点反映在项目方案中，明白设计的原因，主人翁感觉使团队的合作阻碍更小，并获得了大量有价值的想法。第四次尝试，成功！

1.43观点三：DUD（design-user research-design）

这种观点倡导先设计方案，用demo或者测试版本做用户测试，而后进行优化和再设计如图8。这样的方式对设计师要求较高，产品开发也存在一定的风险。