写点什么

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

  • 2010-03-19
  • 本文字数:1827 字

    阅读完需:约 6 分钟

用户体验专家 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-03-19 03:382022
用户头像

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

关注

评论

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

政法委重点人员联防联控系统开发,重点人群管理服务平台建设

a13823115807

你了解集合?那你倒是给我说说啊!【3】

XiaoLin_Java

集合 java基础 1月月更

粤、蒙、沪同步试点全电发票,数字化转型思路你拿捏了吗?

金小K

云智慧运维管理平台OMP荣获OSC中国开源项目评选「最受欢迎项目」奖

云智慧AIOps社区

开源项目 运维工程师 运维监控 自动化运维 运维管理

洞态漏洞检出测试第二期:NoSQL & LDAP注入漏洞

火线安全

DevSecOps WEB安全 安全漏洞

年度盘点丨2021数字化转型优秀案例TOP10

ToB行业头条

涨薪密码 | 音视频开发-程序员界的技术皇冠

Yt

音视频 WebRTC ffmpeg 流媒体 SRS流媒体服务器

项目经理如何有效管理项目进度?项目管理3大常见问题及解决方案

优秀

项目管理 项目管理工具

阿里云「低代码音视频工厂」正式上线,为企业用户打造音视频应用开发最短路径

阿里云CloudImagine

音视频 低代码 开发

如何修改Kestrel上传文件的大小

喵叔

1月月更

安全架构要参:构建企业适用的安全架构

I

安全架构 企业安全

软件定义存储的头部厂商也来了,XSKY 星辰天合加入龙蜥社区

OpenAnolis小助手

龙蜥社区

MongoDB高级应用之数据转存与恢复(5)

Tom弹架构

Java 分布式数据库mongodb

采购堡垒机时候,选择开源堡垒机还是云堡垒机?

行云管家

云计算 网络安全 等保 堡垒机

QCon-OPPO大规模CV预训模型技术及实践

安第斯智能云

算法 计算机视觉 预训练模型

跨越2021丨在逐梦中星夜兼程,在前行中不忘初心

YonBuilder低代码开发平台

低代码

基于STM32设计的数字电子秤

DS小龙哥

C语言 嵌入式 单片机

CRM系统的六大优势

低代码小观

低代码 CRM 客户关系管理 CRM系统 客户关系管理系统

Hoo虎符研究院 | 币海寻珠——2021年4季度区块链投融事件TOP20

区块链前沿News

Hoo虎符 虎符交易所 虎符研究院 区块链投融 灰度基金

低代码实现探索(十二)vue.config.js模块打包

零道云-混合式低代码平台

从事【音视频】的开发者,看过来,如果记不住FFmepg命令,可以收藏,不记得的时候,掏出来翻翻

奔着腾讯去

c 音视频 ffmpeg

Flutter 压缩图像的最佳方式

坚果

flutter 1月月更

Hoo虎符研究院 | 币海寻珠——即将初始发行Token区块链项目

区块链前沿News

Hoo 虎符交易所 初始发行

低代码平台对程序员有哪些好处?

J2PaaS低代码平台

如何用建木CI部署k8s资源

Jianmu

Kubernetes DevOps CI/CD 开源项目

VuePress 博客优化之 last updated 最后更新时间如何设置

冴羽

JavaScript Vue 前端 博客 vuepress

谁说操作系统没有创新,这里就有一个,还是分布式的

LAXCUS分布式操作系统

微信小程序与webview关于iphone X的兼容设置

CRMEB

CVE-2021-32682 elFinder RCE 简单分析

H

网络安全 安全漏洞

2022年石家庄等保测评公司名单(排名部分先后)

行云管家

网络安全 等保 等保测评 石家庄

为什么企业组织更愿意选择内部私有的IM,而不使用钉钉、微信等软件?

BeeWorks

让敏捷与“以用户为中心的设计”和谐共生_研发效能_Mike Bria_InfoQ精选文章