## 产品设计体会(二五)——当交互设计遇到敏捷开发
让我们先回到2002年1月15日,交互设计之父Alan Cooper和极限编程创始人Kent Beck在pk,话题是“当交互设计遇到敏捷开发”。就像小说里两大高手对决一样,双方大战三百回合还是没有分出胜负,终归握手言和(或者小气的赌气分手,呵呵),引用一些对那场战斗的评论:
Ø Cooper大师认为子弹很贵,因此在每次开枪之前一定要精确地瞄准。负责瞄准的人应该是专业的交互设计师。
Ø Beck大师认为有了极限编程,子弹变得很便宜,我不需要瞄太准,打不准就再放一枪,没什么大不了,最终总能打中目标。
Ø Cooper大师很适合做一个狙击手,点射的命中率几乎能够达到100%。
Ø Beck大师很适合做一个机枪手,机枪是不可以点射的,一般都是扫一片,用密集的火力消灭敌人。
Ø 两者考虑问题的角度不大一致,其实并不存在非常大的冲突。相反,交互设计与敏捷开发方法能够结合起来,以更小的成本交付令用户满意的产品。Patton在这方面做了成功的尝试。
还 是那个道理,方法只有是否合适,没有好坏之分,也许“交互设计”比较适合传统领域、成熟公司、时间资源充裕的时候,使用者在某领域中已经出于领先地位,目 的是求稳,不犯错就是胜利;“敏捷开发”适合新兴行业、创业公司、时间紧迫,大家都在赶,谁先出头谁就能占得先机,或者作为挑战者进入某个行业,团队本身 灵活,失败了损失也不大,重来的成本低。从这点上看,互联网行业、SAAS模式似乎更偏向于使用敏捷开发的方法,但敏捷绝不是在时间紧迫下的被迫放弃交互,而是主动为之的一种思想,并且要将交互融入其中(敏捷设计?)。
从另一个角度想,“交互设计”适合设计型公司,“敏捷开发”适合技术型公司,各个公司都有其强势的部门,先不展开,下次说。
“交互设计”之于“敏捷开发”,有点像那个“大象与猴子”的寓言(一时找不到),又像楷书与草书,同样是写字,没法评价哪个好哪个差,也许结合一下又出现了很赞的行书。
- 前言
- (一)——变态吧,开始帖周报了
- (二)——数据分析
- (三)——性价比:做不做?
- (四)——需求管理
- (五)——有关流程
- (六)——再谈流程
- (七)——需求探针
- (八)——产品与项目
- (九)——关于学习
- (十)——团队合作
- (十一)——市场扫描
- (十二)——少而精
- (十三)——再说需求分析
- (十四)——做过的几个项目
- (十五)——PM、PD、UE与UI
- (十六)——Feature List
- (十七)——PD的几种文档
- (十八)——概念设计
- (十九)——UPA年会的流水账
- (二十)——有关改版
- (二二)——封闭开发
- (二三)——用户研究
- (二五)——当交互设计遇到敏捷开发
- (二六)——PD就是出来卖的
- (二七)——大产品设计
- (二八)——细节之文案
- (二九)——产品设计的五个层次
- (三十)——“体会”导读的思维导图
- (三二)——零散的体会
- (三三)——用户大会
- (三四)——土老板破冰必杀技
- (三五)——QA与测试
- (三六)——再理解“敏捷”
- (三七)——可用性测试
- (三八)——项目外包!=开发外包
- (三九)——CSDN专访精编版
- (四十)——销售渠道
- (四一)——用户创意无限
- (四二)——又是零散体会
- (四三)——说说评审会
- (四四)——项目外包不适合“敏捷”?
- (四五)——外行眼中的技术分工
- (四六)——UML学习摘录(上)
- (四七)——UML学习摘录(下)
- (四八)——资源战争与BRD
- (四九)——产品市场化
- (五十)——终点:Matrix
- (五一)——敏捷的估计与规划
- (五二)——MS Office使用心得
- (五三)——产品文档与规范
- (五四)——PD招聘广告词
- (五五)——项目Kick Off
- (五六)——《需求工程》培训记录
- (五八)——《项目化管理》培训记录