【摘要】设计和开发两条线,平行前进。设计师和开发员基于各自承担的部分,结对工作。这样需要设计师、开发员、尤其是企业、产品的拥有者,变得比原来更加的灵活。
在互联网行业中,用户体验与开发总是一组成对出现的名词,工作中有着千丝万缕的关联。互联网产品的特点决定了其必须关注用户使用的感受和体验,而又需要快速开发、迭代来占领市场和用户,并进行不断的优化改进,然而在用户体验和开发人员眼中,他们各自的角色却大有不同:在用户体验人员眼中,开发人员是技术导向,忽略用户使用感受;在开发人员眼中用户体验流程长、时间久、应变弱。二者之间似乎是一对矛盾体,如图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、视觉设计提前
视觉设计师应更多更早地参与到用户体验研究和设计的流程中,提前形成对产品的全面认识,输出视觉元件库,团队则可以快速验证整个设计的体验和效果。
|