Agile UX is good, but can be better

在敏捷开发中更好的做用户体验（UX） | Agile UX is Good, But Can Be Better Agile Community Taiwan
在敏捷开发中
更好的做用户体验
廖振宇 JAMES LIAO
Agile UX is Good, But Can Be Better
Agile Community Taiwan

自我介绍
微软咨询部 – 用户体验顾问 + 应用程序开发员
专门从事给世界各國客户提供解决方案
Modern Apps Solutions Centers
国际NGO公益 – 美国总干事
通过互联网信息通讯技术，开发应用解决方案，
让每一个公众轻松、有效地参与到促进儿童信息
素养的公益事业中

 敏捷管理员 ScrumMaster
 产品负责人/产品经理 Product Owner
 开发人员 Developer
 测试人员 Tester/QA
 用户体验 UX
你在工作中主要扮演的角色是什么？

什么是 “用户体验UX” What is UX
敏捷开发中UX的挑战 Challenges for UX in Agile
如何在敏捷开发中更好的融入UX Integrate UX into Agile
Sprint中UX的节奏 Sprint UX Cadence
UX用户故事 UX User Stories
用户需求的快速展望 (精益UX) Rapid Envisioning (Lean UX)
低成本的原型制作 Low-Cost Prototyping
团队设计讨论 Group Design Sessions
快速用户可用性测试 Quick Usability Tests
大纲

日常生活中的各种体验

“用户体验UX”的定义
以人爲本
軟體需要滿足人的期望
而不是人必須適應軟體
同理心
感受用戶的痛點、難點、喜點
情緒共鳴
設身處地
應用程序開發團隊零距離
與用戶和利益相關者
一種純主觀在用戶使用產品或服務過程中建立起來的整體感受
尤其是該產品或服務在使用方面用戶覺得有多麽容易和滿意
用戶體驗的思维方式

UX ≠ UI

“用户体验UX”为什么重要
想要的 vs 需要的
最终用户自己想要什么
与所需要的是什么，
会是两个不同的东西。
用戶體驗的重要性

 找到用户最需，保证有人用
 了解用户目的和动机，符合用户预期
 了解现在用户的做事流程，确保使用方便
 使效益和影响最大化，满足投资目的
UX的目的

什么是 “用户体验UX”
 UX 是以用户为中心，以人为本
 迭代增量式的设计开发过程
 确保在开发过程中有效地让用户充分参与
 从用户的视角来定义SOLUTION功能范围
 UX是与商业策略、系统功能需求和技术规范互补的

敏捷开发中UX的机会
以少做多
敏捷软件开发宣言 UX目的
个体和互动高于流程和工具 vs 用户充分参与
工作的软件高于详尽的文档 vs 保证有人用
客户合作高于合同谈判 vs 满足投资目的
响应变化高于遵循计划 vs 迭代增量式
以用户为中心，以人为本

需要一个完全形成的想法，每次構建一點點
增值式開發

从一个模糊的想法添加细节直到完成
迭代式開發

每次構建一點點，但一定要完成你所構建的內容，
迭代并增值式開發

没有时间做UX调研和测试
Sprint时间表太紧张了
敏捷开发中UX的挑战
没有在开始编码之前
做好UX预备工作

× 团队不清楚最终用户角色，不了解用户
× UX在开发过程中被忽略
× UX是各个开发员编程中临时做的决定
× UX是编程后意外的一个结果
× 整个SOLUTION的UX会像拼凑起来的
× 缺乏统一的体验
× 最终UX来返修，重新设计，重新编UI
没有在开始编码之前
做好UX预备工作

UX Without User Research Is Not UX.
It is just X. UX – U = X
× 没有足够的用户调研，不确定用户需求
× 没有用户测试，没有及时得到用户反馈
× UX问题发现太晚，导致更多的代码需要
重新写
× 降低用户采用率，影响团队士气
× 增加项目失败的风险
没有时间做UX调研和测试
Sprint时间表太紧张了

3个角色
产品负责人
Product Owner
敏捷管理员
ScrumMaster
开发人员
Developer
开发人员
Developer
开发人员
Developer
用户体验
UX Designer/Developer

用户故事
UX用户故事
3个工件
UX
用户角色
原型制作
设计
Scrum
产品 backlog
Sprint backlog
Burndown

用户需求的
快速展望
3个仪式
UX
Sprint 0
团队设计讨论
可用性测试
Scrum
Sprint 计划
每日立会
Sprint 审查与回顾

需求设计开发运营
用户需求的快速展望
愿景目标
团队设计讨论
+
快速用户可用性测试用户反馈分析
UX
Scrum
愿景目标维护 + 跟踪弄清需求
Scrum中UX的节奏
用户角色
用户旅程/
体验路线
Sprint 0
低成本原型制作
互动设计
UI设计样式
收集需求 Backlog分析汇总 UI 界面设计

Sprint中UX的节奏
UX
开发团队

Sprint中UX的节奏
Sprint 1 Sprint 2 Sprint NSprint 0

每星期UX的节奏
周一周二周三周四周五
9:00 每日立会每日立会每日立会每日立会每日立会
10:00
团队设计讨论团队设计讨论
11:00
UX 开门办公时间 UX 开门办公时间 UX 展示解说
12:00
13:00
14:00
每周快速用户可用性测试
15:00
16:00
17:00

建立UX用户故事，并给予故事点：必须与其他用户故事写程序任务平等
作为【用户角色】，我想要【UX活动】，以便于【页面/环节/流程】。
 低成本的原型制作 Low-Cost Prototyping
 团队设计讨论 Group Design Sessions
 快速用户可用性测试 Quick Usability Tests
UX用户故事

一周（5天）的时间：把所有的用户角色代表都聚集在一起。
各种基于场景的分析，根据每一个用户角色，以用户为中心，以人为本
什么是“场景”？在一个人物角色期望得到某些东西或者达到某些目的时
候而要做的事情。帮助链接工作目的与IT技术所能提供的能力。从中看
到可能存在的缺口。
什么不是“场景”？不是要覆盖所有的工作流程，也不是要定下任何工作
流程，更加不是讨论任何具体软件界面的使用流程。
用户需求的快速展望过程：精益UX
现在的
状况
将来的
愿景
用户
人物角色
用户
体验路线
用户
情境式调研
用户
服务蓝图
用户故事需求
分出轻重缓急

用户需求的快速展望过程：精益UX

乡村学校很多图书室是锁着、关着，这是最初的问题。找出原因，也就
找出了真正的需求。深入调研后，发现以下4点主要原因：
1. 缺少专业管理图书的老师。
2. 图书室缺信息化管理：书目、借阅管理、读者数据库，等等。市场上
城市图书馆的软件不适合，并且乡村学校也没钱买软件。但学校认为
有责任保管好那些书。
3. 缺少足够让孩子们感兴趣、可看的书籍。
4. 现有学校教学体系中，学生缺少常态阅读的时间与空间。
乡村阅读解决方案展望过程案例
现在的
状况
将来的
愿景
用户
人物角色
用户
体验路线
用户
情境式调研
用户
服务蓝图
用户故事需求
分出轻重缓急

开发两个产品：图书馆借阅管理软件和捐书网。
 用条形码来做借阅管理——免除对书籍标准编号的功能，因为不是以
书籍管理为主要目的，而是以方便简单、迅速开放图书室为目的。
 公开透明——图书室借阅数据公开、透明地展现在捐书网上：公众能
看到乡村孩子读了多少本书、看到图书室的开放。
 精准捐赠——因为数据的公开透明，所以，捐书的公信度加强了，从
而引导捐赠人更便捷、精准、合理地捐赠图书。
现在的
状况
将来的
愿景
用户
人物角色
用户
体验路线
用户
情境式调研
用户
服务蓝图
用户故事需求
分出轻重缓急

【讀者】小明
學習
在學校裡學習還算認真，但不是非常出眾。
但是他思維比較活躍，喜歡耍小聰明。
他最喜歡的課是數學課，電腦課，體育課。
動機因素
讓爸媽驕傲，和對妹妹的愛，是他的動力。
他希望能早一些幫助爸媽分擔家裡的負擔，
希望為自己的家庭出自己的一份力。
挑戰
學習生活過程中，僅僅限於讀課本、聽老師
講課，對閱讀非常嚮往，但是不知道從哪裡
可以得到課外書。跟著爸媽在城市裡的時候，
經常會去書店，找科幻類的書看。
也希望長子也能分
擔一下生活負擔。
所以就15歲帶著他
去北京跟著。
父母在北京大城市
打工，因為有2個
孩子，家裡生活壓
力比較大，所以父
母出去打工。
爸爸：北京打工，
機場。媽媽：北京
打工，餐館服務員。
妹妹：上小學。爺
爺奶奶：在河南老
家，照顧妹妹。
名字：小明
性別：男
年齡：15
來自：河南
現在的
狀況
將來的
願景
用戶
人物角色
用戶
體驗路線
用戶
情境式調研
用戶
服務藍圖
用戶故事需求
分出輕重緩急

现在的
状况
将来的
愿景
用户
人物角色
用户
体验路线
用户
情境式调研
用户
服务蓝图
用户故事需求
分出轻重缓急

现在的
状况
将来的
愿景
用户
人物角色
用户
体验路线
用户
情境式调研
用户
服务蓝图
用户故事需求
分出轻重缓急
 学生自我管理图书室的功
能——从情景时调研中我们
了解到，老师们即使很快学
会了软件操作，但她们放学
后经常没有时间留在图书室，
因为要回家烧饭带孩子，所
以我们在软件设计中增加了
儿童自我管理图书室的功能，
让儿童自主借阅、自主阅读。

老师操作
与系统接触
学生操作
校长/公益组织操作
校长/公益组织报表
能见度隔离
时间轴
登陆管理软件
软件登陆页面借阅图书页面
学生自主借阅
分析图书馆运作情况发起捐书活动
图书馆运作报表图书馆所需新书报表
现在的
状况
将来的
愿景
用户
人物角色
用户
体验路线
用户
情境式调研
用户
服务蓝图
用户故事需求
分出轻重缓急

用户需求的快速展望过程

作为【用户角色】，我想要【活动】，以便于【目的/价值】。
【必须的】【需要的】【可以有】
【必须的】作为图书室管理员，我想要录入、更新、删除图书信息，以便
于我对图书室书目的管理。
【需要的】作为图书室管理员，我想要上传图书室的读者信息，图书信息，
与借阅信息到捐书网，以便于公开图书室运作的透明。
【可以有】作为图书室管理员，我想要用手机来扫条形码，以便于不需要
扫描枪就可以输入索书号与读者号。
现在的
状况
将来的
愿景
用户
人物角色
用户
体验路线
用户
情境式调研
用户
服务蓝图
用户故事需求
分出轻重缓急

调整适应用户详细记录
在用户正常环境中至少二个人：UX+1 提前设置期望值可靠的用户角色代表
时间限制每个环节不谈技术细节
用户需求的快速展望成功法则

在操作通过使用
以用户为中心，以人为本

纸上的简易原型 Paper Prototyping
https://vimeo.com/2273993
花小錢辦大事

 低成本，性价比高
 简单，谁都可以画
 可以迭代式修改
 用户/客户会更愿意
给建议，觉得“便宜”
 不用在美观细节上
浪费很有可能将来
都不需要的UI
 不占用程序员开发
时间，不浪费代码

低精度 vs 高精度

寻找灵感：竞争分析

团队设计讨论
 保证团队对特别复
杂的用户故事需求
达成共识
 帮住团队准备将要
接下来开发的需求
流程和任务
 收集团队的知识
 更多的设计思路
 提高团队协作能力
 增加团队默契

时间活动任务
2' 场景讨论介绍将所要设计的用户故事细节以及场景
2' 无声的头脑风暴各自在纸上写下2-4个解决的想法
1' 分享解决想法各自用10"时间来相互分享觉得自己最好的解决想法
10' 纸上的简易原型各自画原型，确保符合场景，目的是为了满足用户故事
10' 认知走查依次轮流相互介绍自己原型的用户使用路线，相互给予意见
5' 讨论优点总结所有原型中的设计优点，并记录下来
团队设计讨论

团队设计讨论

为什么需要快速用户可用性测试
猜
 更频繁的用户测试，可以让客户对开发出来的解决方案更加了解。
 越早发现错误，越有可能修复。越晚开始测试，越有可能增加项目
失败的风险。
 更多的用户测试，能让团队更加了解用户/客户。
 邀请开发团队成员、产品经理、项目管理、等参加无声观察用户测
试，可以提高整个团队对项目的认知。

旋转门式测试
专用UX测试实验室
 邀请开发团队成员和产品经
理参加，确保无声观察
 开发团队楼内的专用房间
 台式机
 安装Morae 3与HD摄像头
快速用户可用性测试
用户环境中测试
移动UX测试设备
远程测试
远程UX测试设备
 至少2个人 UX + 1，同时
帮住建立客户/用户关系
 专门为带到用户环境中
 笔记本电脑
 安装Morae 3与HD摄像头
 远程的简易原型测试
 专门为移动应用在平板电
脑和手机上测试
 实物摄影机 ELMO, MO-1
 安装Morae 3

應用簡介
1. 燒傷中心病人管理
2. 病人病房分配
3. 病人治療方案計劃與執行
4. 醫療團隊咨詢協作透明
5. 醫療數據的即時分析
技術簡介
1. 6周時間——從展望到可能
性的探索開發完成
2. Surface Hub 多人觸屏應用
3. 雲支持計算實時數據分析
可能性的探索開發
例子：瑞典乌普萨拉大学医院医院烧伤中心

需求展望過程：實景觀察
基於現實工作場景分析得到用戶所要做的事情和目的。

用戶充分參與設計：藉鑒已有的解決方案

可能性的探索應用

用戶充分參與測試：每兩周的實景測試

感谢
Modern Apps Solutions Centers

保持联系
JAMES.LIAO@microsoft.com
@JAMESZLIAO

【必须的】作为读者，我想要自主借阅，以便于在老师忙的时候借书。
团队设计讨论模拟
• 条形码
• ISBN
• 书名
• 出版社
• 作者
• 定价
• 书架
• 索书号
书的信息包括
• 学号
• 姓名
• 性别
• 出生年月
• 联系方
• 读者类型
读者信息包括

Agile UX is good, but can be better

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Agile UX is good, but can be better

Semelhante a Agile UX is good, but can be better (20)

Mais de Jen-Chieh Ko

Mais de Jen-Chieh Ko (20)

Agile UX is good, but can be better

Notas do Editor