您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
敏捷用户体验下如何实现设计和开发两条线平行前进
 
来源:《卓望》杂志 发布于 2016-11-17
   次浏览      
 

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

在互联网行业中,用户体验与开发总是一组成对出现的名词,工作中有着千丝万缕的关联。互联网产品的特点决定了其必须关注用户使用的感受和体验,而又需要快速开发、迭代来占领市场和用户,并进行不断的优化改进,然而在用户体验和开发人员眼中,他们各自的角色却大有不同:在用户体验人员眼中,开发人员是技术导向,忽略用户使用感受;在开发人员眼中用户体验流程长、时间久、应变弱。二者之间似乎是一对矛盾体,如图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》

摘自《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。这样的方式对设计师要求较高,产品开发也存在一定的风险。

王巍 ?诺基亚研究院(深圳) 用户体验主管

这种方法更多地基于产品需求和设计人员的判断力,来快速进行设计和原始模型的构建,较适合当前互联网行业的快速工作模式,但是非常依赖设计人员的能力和经验,要求团队成员具备较高的同理心。

1.5敏捷用户体验和全流程用户体验的对比

2.敏捷用户体验现状

通过对敏捷用户体验的研究和总结我们发现,在合适的项目背景下,其对项目的开展、对产品的开发以及对团队的建设都有着较大的推动作用。

1、对项目而言,敏捷用户体验可以更灵活的应对变化,快速响应;

2、对产品而言,敏捷用户体验与产品开发结合的更加紧密,降低产品开发风险;保障产品在“可用”的基础上更加“好用”

3、对团队而言,引入敏捷用户体验思想,构建一支敏捷用户体验团队,增加前端开发人员,有利于完善团队结构;多领域交叉团队,更有利于团队成员能力的提升,迅速培养人才;大量减少设计与开发在团队之外的反复沟通成本,提升工作效率。

3.如何开展敏捷用户体验项目

3.1建立团队

结合上文提到的案例二,我们知道执行敏捷用户体验项目是有方法可循的,但真正重要的还是以人为核心。要开展敏捷用户体验项目,首先要构建团队。团队人员角色如下:

人员组成:研究员、交互设计师、视觉设计师、前端工程师、PM、PL、客户

团队规模:6-8人

工作方式:一起工作,或是能保证每天面对面沟通的方式 。

3.2管理团队

团队成员的认知、目标、方法各有不同,如何组织起来、高效率地协作呢?建立团队共识,一起工作,使用敏捷流程,有完成“不可能的任务”的勇气,有共同跨越障碍的毅力,团队互相信任。

摘自《agile-user-experience》,Declan

1、“用户故事”轻松建立团队的共同认知

用户故事是从用户角度对产品功能简单的描述。把用户故事贴出来,放在明显处,让所有人都可轻易看到。潜移默化之下,用户的形象深深地植入成员心中,形成一种共同的视角。

摘自《UF2011_AgileandUX_CindyLu》

2、重新定义设计师,破除沟通的障碍

让跨职能的成员参与设计过程,甚至包括客户,但保证决定权,最终由正确的人来做决定。可采用上文提到的方法,即“跨界工作室”。

3、进度透明

使用合适的方法,展示当前大家的进度;用电脑软件,或便利贴。随时看到需求、叠代任务的即时变化,方便大家灵活调整。促进沟通、协作,团队共同跨越障碍。

摘自《Human-centered design meets Agile Development》

3.3实际执行中,用户研究和设计如何适应敏捷?

3.31用户研究适应敏捷

嵌入到敏捷开发中的用户研究,通常是可用性测试。可用性测试如何敏捷?

1、从小开始

敏捷用研的目标是为了清除障碍、缩小范围,可考虑从3个被试开始,找到明显的交互缺陷。

2、每周必测

每周固定一天做用户测试,让这个测试周期成为团队工作的节奏,且留有足够的时间响应用户需求变化。使团队习惯在这天前有一定量的有效输出,在这天快速做决策,快速调整。

3、有什么测什么

无论给用户展示什么,即使只是草图,都可以得到有价值的反馈,即便跟用户聊聊,他们抱怨的点也许就是我们的机会点。

4、邀请所有人参与测试

邀请所有的成员,包括工程师、产品经理、相关利益者等,共同参与测试。在访问一两个用户后,整个团队能大概知道问题在哪里,而研究员不必再去做说服其他成员的工作。

5.、迅速汇报

无需漂亮的界面,只需有力的总结和有针对性的建议,把每一次的测试发现都保存在一个共享文件夹里面,供随时翻查,项目不仅仅是快速前进,且每一步都经过真实用户验证。

3.32用户体验设计适应敏捷

1、设计和开发平行发展,结对工作

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

2、每周两次测试

每周两次的设计测试,嵌入迭代周期里。测试内容可以是能运行的软件--有用户基础,且是设计师和开发员紧密合作的成果,便是基于最真实的情况得到的用户反馈,。

3、引入风格指南模板

正如前文案例二所说,它是一套能够复用的组件,如代码、图例、样例等,它能让用户体验团队将宝贵的时间,用来解决核心的交互问题。

4、视觉设计提前

视觉设计师应更多更早地参与到用户体验研究和设计的流程中,提前形成对产品的全面认识,输出视觉元件库,团队则可以快速验证整个设计的体验和效果。

   
次浏览       
 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]
相关文章
由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   
相关培训课程
统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行
成功案例
某博彩企业 产品经理与产品管理
面向产品的需求分析与管理
中国民航 产品经理关键技能
深圳 产品经理与产品管理
某通信企业 基于互联网的产品创新
某知名互联网企业 产品管理
世纪高通 创新创造突破性产品
更多...