更小更快更灵活——设计师谈敏捷

腾讯一直推广敏捷开发,也在强调敏捷开发,但你会发现,即便如此,还是会陷入以下情景
- 又丑又长的讨论会
- 好像人手永远不够
- 不切实际的想法
- 悬而不决的功能点
- 无穷尽的偏好设置
- 越来越多纠缠不清的细节
- 项目依然延期
我们如何构建一个更轻巧的开发流程,让我们更快更好的交付结果?作为一个设计师,如何成为敏捷的一分子?以下是一些心得方法,希望和大家分享
1 界面先行
作为设计师,最简单能让大家明白你的想法就是先把它画出来,不要用晦涩的语言和结构图,毕竟不是所有人都能把你的语言转化为图像。而且界面(视觉,交互)设计是相对轻量级的,修改起来也简单,成本也低。但修改程序就远不是那么回事了。保持界面先行可以让你非常灵活,至少在开始开发之前可以随意修改。
界面先行另一个最重要的原因就是,对于用户来讲,界面就是你的产品,界面可以帮助你从用户角度看待自己的产品,如何展现,如何操作,给人感觉怎么样,是不是易用。只有当你面对真正界面的时候才能回答这些问题,文档概要并不能帮你解决实际用户体验问题。
2 初期不需要太关注细节
虽然大家总说,成功来源于细节,当然,这非常对。但前期过分关注细节的同时也会令你止步不前。先把大框架确定下来,而不是一直纠结于
- 这条提示怎么写更合适?
- 文字字号用16还是14?
- 要不再往左挪1像素?
- 这里加个高光把
- 把2像素的描边变成1像素
你需要关注细节,但不是现在。所有事情都要从大到小的去做。先把他做出来,把该放的东西放上去,然后实际去用一下。
细节是你在使用的过程中才会慢慢显露出来,只有在使用中你才会发现哪些更值得关注。如果你有足够的时间,当然可以面面俱到,如果没有,请先把精力放在最重要的事情上。
3 不要纠结那些还没有成为问题的问题
“当我们的用户用了这个功能以后还想跟另一个功能配合使用怎么办?”
如果想快速推出版本,就先解决当下。不要花太多时间去考虑还没有成为麻烦的问题。别担心,你还有后续版本。
而且你就真那么确定用户想跟另一个功能配合使用么?如果不是,就先放一边,等问题真正浮出水面的时候再去快速解决。
4 帮助产品经理精简功能
好像大家都在弩着一股劲,比谁做的多。竞争对手的产品如果做了**,我们就要做***,他们有4个功能,我们就要做5个。如果不做,拿什么跟他们竞争?
这种方式是行不通的,因为你会发现,永远是赶超,永远没有自己领跑的那一天。怎么办?
做少
通过做少来打败他们
做的功能越多,功能间的交互就会越复杂,用户的学习成本就会越高。而我们的用户真的用的上那些高深的功能么?他们会不会已经被那些多如牛毛,但我们自以为高明的设置搞得疲惫不堪?试着少做一点,让自己的产品更加轻巧而更具备亲和力——没有人会喜欢使用显得自己很笨的软件。
5 功能间更少的牵扯
把一个功能点做的尽量独立,能保证需求改变时更为快速,更为灵活。
如果功能间的牵扯太多,就如同你身上沾满了蜘蛛丝,每做一点改变,其他的都要进行改变,从设计,到开发,到测试。当你发现改变的代价太大时,你就会放弃,然后依旧背负着带有缺陷的功能一路走下去。
为什么不开始就尽量少牵扯呢,这样更加来去自如
6 要有自己的主张
虽然交互设计通常都会处在不黑不白的阶段,因为没有绝对的对与错。但我们还是需要坚定自己的主张。也许果断的观点看起来目中无人,但总比那些“嗯……其实这样也成……”模棱两可要好的多。敏捷开发中需要的就是快速做决定,而不是唯唯诺诺和稀泥。
————————————————————————————————
也许并不是所有的项目都适合,毕竟初期不考虑细节必然要考虑后期更改的成本。但对于一个新产品,快速触达用户,让用户来使用,验证,反馈,得到的数据更加真实有效。根据这些反馈作出的调整总是比自己拍脑袋来的简单,更加符合用户需求。
敏捷,并不只是站立晨会,迭代总结,理论,文档,更需要的做的是,把它做出来。
(本文出自Tencent WSD Blog,转载时请注明出处)


HOHO,原来设计跟开发一样的。
是沙发不!
占坑看文章!
这个也要视情况而定,前期不对全局多加考虑,可能对后期的修改带来很大的成本。另外,当前没有浮现的问题,可能到以后出现时,已经很严重了。
感谢,拜读
作者从设计人员的角度提出了这个问题。下面发表下个人看法
1.设计先行
成本低是相对于程序而言。两者都不易先行。
如果是为了弥补会议中语言表述不清晰的问题,可以画界面草图。
2.初期不需要太关注细节
这点赞同,前期主要是订需求,界面表现层面的东西不是这个阶段的任务。
3.不要纠结那些还没有成为问题的问题
前期还是要考虑周全,等问题出现再解决就被动了。但不意味着纠缠在细枝末节,对问题的重要程度要有清晰的判定。
4 帮助产品经理精简功能
这就是产品人员的问题了,提出清晰的产品需求是对产品人员的基本要求。需求搞不清,大家都受累。这个问题该放在第一点。
5.功能间更少的牵扯
还是在考验产品人员的功力。
6.要有自己的主张
这点赞同,有差异才有碰撞嘛。不过问题是当大家无法达成共识时有没有一个能做快速决定的人,不然就纠结了。
从文章中感觉产品人员做的工作不够到位,导致问题落到了大家身上。设计师提出了这些问题,指不定开发人员也提了一堆意见呢!
1.设计先行
线框图或低保真原型能搞定这些事,一些公司里,产品人员会提供的。
2.初期不需要太关注细节
非常同意
3.不要纠结那些还没有成为问题的问题
这得看团队了,这些问题总得有人想,多想一点没有坏处。
4 帮助产品经理精简功能
首先需求肯定是清楚的,否则不应该开始做交互以及视觉。但是在做的过程中,与产品人员讨论,也是积极的,会对产品更好。
5.功能间更少的牵扯
其实是与在市场人员/领导/客户 纠结,你也许能暂时说服他们“少即是好”,但背着市场指标的人,需要更多的功能来确保自己有更好的市场机会。
6.要有自己的主张
这点赞同,有差异才有碰撞嘛。不过问题是当大家无法达成共识时有没有一个能做快速决定的人,不然就纠结了。
———————–
总结,要是每个做交互或设计的人员都是楼主这素质,那产品研发就太愉快了。
回复leo:
1 我说的是“界面先行”,包括低保真或高保真模型,并不是特指完整效果图。做什么都有成本,单就设计和开发而言,取舍一目了然。
3是要尽量考虑周全,但互联网的优势就在于可以快速升级,不会像食品行业,吃死人再打官司。当然,取决于你对你产品的定位,以及公司自有实力。有时间,就慢慢磨,没时间,请快速出版本,后续加强补丁升级,不然你随时会被out
另:本文章只是个人感受,毕竟只是敏捷初学者。而且涉及不是很全(包括leo说快速决策人员,当然要有,这不用多说,就跟产品不能脱离用户一样)敏捷是一门学科,写全了估计能卖书,这里只探讨个别现象。
好滴产品经理还是有滴,比如QQ阅读的产品经理。
最后:开发肯定一肚子想说的话嘛,所以请leo多动员开发来看看我的blog,对于不同意见多发表,互通有无,一起进步。
哟,是“我们的blog”,少写了个们,看我鸡冻的。一说到拉客户,偶就鸡冻
QQ阅读我觉得做的很差,功能不多也就算了,核心功能做的也不好,还有手机QQ也不咋地
谢谢楼上的提醒,我们版本在逐步改进中,也期待您提出更多的改进意见。
设计师越来越像程序员了
感觉这里文章更新挺慢的,大家是不是都很忙啊,呵呵
期待作者分享更多关于敏捷开发的经验~
其实界面先行,就是界面设计先行呗。设计先行在诸多行业都是固定的流程了,理论上大部分产品不是设计先行就没法做,至少是做不好。
而界面设计师如果不在初期参与产品设计,等于在做尸体彩绘,或者只能在大框架之内做发挥一点点价值,虽然国内真正做到设计先行的IT公司还不多,需要共同努力。
苹果就是注意了那些没有成为问题的问题,而成就了伟大的体验
参考。。。。。。。
自己的主张很重要吧,呵呵
这里面什么都讲了,就是没讲数据,“现实”永远都是非常残酷的,不基于数据的草图,原型与空谈的价值几乎是同等的。不要被眼睛所蒙骗。由其是敏捷开发更需要有丰富经验的人才能准确对数据进行快速分析与定位草图。所以关键是在“三军未动,粮草先行”行兵最基本的条件。欢迎分享与交流~
感觉 很多点都似曾相识……
好奇怪
还是蛮有道理的,不是所有IT公司都那么大,对流程要求那么严格,如果是新产品,你慢点,你的客户就飞了。从营销和销售的角度来看,界面先行有时候非常重要。产品可以出第一版,第二版,客户一旦接触到其中一家后,如果没什么大问题不会轻易更换,因为他们不会轻易再付出时间成本和沟通成本
很受启发
5 功能间更少的牵扯,我有点疑惑,往往有的功能间会具有关联性,比如你完成某项任务可能会诱导去完成另一项任务,这时候到底是提供关联好,还是不提供关联好呢?
太扯蛋了,完全照抄getting real
尊重自己的感觉
很经典 受教了
界面先行有同感,有参考价值
敏捷,并不只是站立晨会,迭代总结,理论,文档,更需要的做的是,把它做出来
文档概要并不能帮你解决实际用户体验问题
界面设计的很好