QCon全球软件开发大会9折优惠倒计时,了解详情 了解详情
写点什么

让敏捷与“以用户为中心的设计”和谐共生

2010 年 3 月 19 日

用户体验专家 Anthony Colfelt 使用一个案例告诉我们:仅有敏捷是不够的;他还深入指出:“以用户为中心的设计”(以下简称 UCD)能够,而且应该与敏捷合并使用。

为了表明自己的观点,Colfelt 首先提出:对于发掘业务的真正需求这个难题,敏捷是合适的解决之道吗?他以此引出自己的观点

就其自身而言,敏捷在调整自己、适应变化方面做得很不错。但是我们必须知道:它能否用来治疗某些症状,这些症状的更深层次原因在于:业务不知道自己的真正需求。虽然敏捷能让开发团队更好地应对这个问题,但是并没有从根本上解决问题,很多时候还创建出了新的问题。

他从用户体验的角度出发,描述了自己所见过的、敏捷出现问题的 6 种“雷区”:

  • 雷区之一:设计角色不清晰
    敏捷原则说:“在整个项目过程中,业务人员和开发人员必须每天坐在一起。”这几乎没有为用户体验设计人员留出任何空间,常常让开发人员从事此类工作,而他们又很可能不具备相关技能。
  • 雷区之二:没有定义需求收集过程。
    敏捷团队的头脑中认为:“需求会像魔法一样从天而降”,从而不愿意花时间和精力制订产品的长远战略规划,认为这“不敏捷”;类似的情形并不少见。
  • 雷区之三:走捷径的压力。
    强迫用户体验设计过程使用与其对应开发工作所采取的迭代方式,这会导致冲动式设计(impulsive design),丧失与用户测试设计想法的机会。当然,敏捷允许测试真实的产出的可用性,但是要应对由此产生的反馈,所花的时间要超出人们的期望或是他们所能接受的范围。
  • 雷区之四:称之为“足够好”的诱惑。
    即使(也许应该说尤其)当敏捷表现出色的时候,团队总要面对排定优先级的需要,是“继续改进现有特性,让它们更好”,还是“向产品中继续添加新特性”?正如 Cofelt 观察到的: > 经常发生的是:继续改进的工作被放在一边,人们更喜欢令人兴奋的新东西。如此这般,我们构建出来的产品中,所有的特性都不能令人满意。
  • 雷区之五:无风险的概念探索时间不足。
    很多敏捷团队在项目的第一天(或是很接近的时间之内)就会开始着手实际工作。有些团队会使用“第零个迭代(iteration zero)”来做一些前期的规划和设计。Cofelt 质疑时间是否充足:相对于在编码之前以粗略的方式验证某些想法,以可工作的范例来验证想法这种敏捷的方式是否总能胜出?
  • 雷区之六:伤害品牌。
    将未经(以用户体验设计的方式)实地测试的功能特性放到市场之中,即使是有意要这么做以收集反馈,也会让客户很快地丧失信心,不再相信你们公司能够不断达到目标;这会伤害你们的品牌,而品牌是很难建立起来的,一旦倒下,再想重树品牌就更难。

Colfelt 做了一个有趣的总结,指出:敏捷本身“善于改进,但是不善于定义”。他强调指出:只用敏捷,也许足以“把现有产品提升至新的水平”;但是,特别是在要开始新东西的时候,“某些层面的规划是必要的,这样可以避免勉强拼凑各人对于最好的设计方案的看法,那样只能产生类似于弗兰肯斯坦式的怪物。”

他接下来描述了一种传统的、也是“典型的”UCD 过程,要读者注意该过程中对于产品“战略”的前期研究(他在后面称之为“概念设计”,并举出完美的 iPod 设计作为典型例子),他强调指出:即使采取敏捷的方法论开发产品,前期研究同样重要。Colfelt 的讲述方式很小心,没有说敏捷排斥这样的前期思考过程,而是提出:敏捷能够直接鼓励此类研究,以彰显敏捷之长处。

UCD 的重点是“战略”和“概念”挖掘,它可以而且应该与敏捷的“改进”能力相结合;说到底,Colfelt 就是希望提升人们对于这一点的认识。

总的来说,要想把二者结合在一起使用,就要避免对它们各自的武断态度。要记住:敏捷没有强制如何定义概念或是整体的设计方向,但是很善于执行具体的设计研究和良好的规划。UCD 必须要很灵活,以应对如下现实状况:实现团队遇到问题,不得不强制采取另一种设计方案。文档只记录必要的信息,以便于传播。设计与开发团队应该尽量坐在一起,因为跨职能的协作和面对面的沟通至关重要。设计团队在开发团队之前先使用一个 sprint 也很有帮助,他们就能有足够的时间测试和迭代。如果遵循这些规则,两种方式就能和谐共存,发挥作用。

在做出任何强硬判断之前,不妨先花些时间读读 Colfelt 的全文。你不妨看看 Johnny Holland 这篇相关文章,其中提到用户体验设计人员在敏捷(Scrum)环境中如何调整自己的工作方式,他还讨论了与“战略”相关的类似主题,不过更关注与开发团队的交互,以及迭代层面的活动和团队动力相关内容。

查看英文原文: Harmonizing Agile with “User-Centered Design”

2010 年 3 月 19 日 03:381397
用户头像

发布了 479 篇内容, 共 130.5 次阅读, 收获喜欢 33 次。

关注

评论

发布
暂无评论
发现更多内容

SpringCloud从入门到精通02---支付模块01

Felix

Kube-OVN 0.6.0 发布,支持 IPv6、流量镜像及更多功能

York

灵雀云 Kubernetes k8s Kube-OVN

文档驱动开发模式在 AIMS 中的应用与实践

华为云开发者社区

Web 代码 API 文档

volatile 关键字精讲

伯阳

Java volatile 关键字 后端开发 多线程与高并发

代码也能“杀”虫:此虫,真虫非Bug也

华为云开发者社区

代码 华为云 modelarts

软件测试--缺陷报告

测试人生路

软件测试

再谈自研开源Kube-OVN, 设计思路及实现原理

York

灵雀云 Kubernetes k8s Kube-OVN

Yarn RM写ZNode超数据量限制bug修复

笨小康

大数据 zookeeper YARN

从七日更,到28天写作挑战,我无法拒绝的原因

梁龙先森

前端 编程语言 28天写作

Kube-OVN 0.5.0 发布,支持 NetworkPolicy、用户自定义网卡和MTU

York

灵雀云 Kubernetes k8s Kube-OVN

“持证”就能上岗 京东绿色内推招聘通道开启

京东科技开发者

云计算 大数据 程序人生

VUE项目性能优化实践——通过懒加载提升页面响应速度

Geek_Willie

Vue

Hive的调优你都知道那些?

大数据老哥

大数据 hadoop hive

Java中定时器Timer致命缺点(附学习方法)

叫练

学习 定时任务 多线程 定时器 技术学习

一个正确的编程思维

程序员吴师兄

28天写作

要想软件“一想之美”,UI测试少不了

华为云开发者社区

软件 测试 华为云

边缘计算安全技术研究

华为云原生团队

云计算 大数据 云原生 边缘计算 华为云

SpringCloud从入门到精通01---父项目创建

Felix

SpringCloud Eureka 高可用架构

技术实录 | 灵雀云基于 OVN 的 Kubernetes 网络架构解析

York

灵雀云 Kubernetes k8s Kube-OVN

Kube-OVN v 0.7.0 发布,IPAM、子网和安全功能增强

York

灵雀云 Kubernetes k8s Kube-OVN

Python进阶系列文章汇总

Kaito

Python 爬虫

开始的开始-可能是最早提交的28天写作活动作品

石君

28天写作

如果你听说过 Elastic Certified Engineer

escray

七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

Spark HistoryServer日志解析&清理异常

笨小康

大数据 spark hdfs

ETL都没弄懂,谈什么大数据 ?我用一分钟给你整明白

智分析

ETL

新思科技网络安全研究中心发现Bouncy Castle中的漏洞

InfoQ_434670063458

新思科技 Bouncy Castle

价值 - 价值的底色(一)

石云升

读书笔记 投资 28天写作 价值

灵雀云Kube-OVN:基于OVN的开源Kubernetes网络实践

York

灵雀云 Kubernetes k8s Kube-OVN

云算力矿机租赁挖矿APP系统开发|云算力矿机租赁挖矿软件开发

开發I852946OIIO

系统开发

软件界旷世之架:测试驱动开发(TDD)之争

华为云开发者社区

软件 测试 TDD 代码 devcloud

大作业一:架构设计方案评审

Nick~毓

让敏捷与“以用户为中心的设计”和谐共生-InfoQ