互联网设计敏捷迭代

星期三 11.19.2008 - Posted in 工作分享, 操作流程, 敏捷迭代 - 6,864 views

Web-based Product Design Process – Spiral Model.pdf

做互联网设计最重要是为了运营,蓝图和文档好比做作业打草稿、画画先描白,经验丰富可以考虑先省下这步骤。因为如果不表现在具体web-based原型上,蓝图、文档再好也无法快速切入开发流程,做为有大局观的Producer应该尽快意识到这点。

UED团队合作与开发流程优化是以前在雅虎做产品同事写的,雅虎团队的产品工程师们技术好,而且有来自美国团队的协作经验传承,做前端编程一直是他们的强项。但传统瀑布模型进程必然要面对“前松后紧”问题,根源在于设计、技术团队要互相等。因此,如果规避必须从观念上做出调整:快速产出快速迭代,也就是软件工程里的Agile and Iterative Development。

以前我也常抱怨做互联网设计没谱,一是资源紧、二是变化快。项目周期和人手似乎永远都无法满足,来自内部考虑不周、外部竞争压力双方的需求变更频繁。其实这就是互联网设计的常态,接下来提到的方法,分为三个大步骤,版本仅供参考。

Alpha.快速完成核心功能开发

这里“蓝图”只是个代名词,也许只有些蓝图片段,或规划片段。曾经我们在老板办公室开会,根据头脑风暴结果、会议记录直接做原型。这么说可能有点一觉回到解放前的感觉,事实如此,第一步很关键,但质量不重要。

因为开始就期望得到完善想法是不可能的。比如,你开会描述个东西,让同事提意见,可能大家什么都说不出来。但只要你动手做出具体原型,同事亲自测试体验之后,意见噼里啪啦一大堆就来了。在这层意义上,绝大多数原型是炮灰也应该。

最初工作用自己最熟悉、最快速的手法完成,别让开发团队等。当然,这部分代码质量将直接影响以后的迭代工作量,根据时间灵活安排。不要考虑的过于复杂,总结起来有三点:

  1. 尽早用web原型评估设计质量
  2. 制作避免过早陷入web结构和表现细节
  3. 设计避免过早陷入功能细节

每个业务都会有核心功能,也就是用户的核心需求,基本上做产品前都会考虑清楚。可能核心功能内还会有核心模块,意思就是逐步提炼,找准关键点下手,这样才能搭好框架。也许经过几次迭代后,这部分工作已经是个可以跑起来的低保真产品,颇具alpha版本规模。

Beta.迭代完成固化需求功能开发

搭框架不要下手太狠,别自以为经验丰富把盘子搞大。因为刚才说了,互联网产品灵活最重要,虽然需求变化是经常的事,但我们要把风险控制在最低点。接下来在已有框架内,用同心圆放大的模式,按优先级实现辅助功能迭代,直至需求固化。

与此同时,产品设计团队除了对低保真原型的继续支持,还应并行完善和提炼高保真原型,并且着手对产品规范中复用模块的持续化整理,主要分为三部分:

  1. web呈现效果迭代。先做图再切效率太低,因此我是直接用css美化低保真原型,通常这步可以把效果做的很得体。实在有必要,最后再截屏用photoshop处理细节并完善css。
  2. web结构和表现迭代。我自己可以完成html framework, css framework两大块。
  3. web行为迭代。需要工程师协助完成javascript framework。

也就是说,在包括beta版本以及之前,重中之重是实现功能需求层的良好用户体验。可访问性、兼容性、可用性、标准化、搜索引擎友好这些具体指标不要过早引入到应用开发中,让它们都在高保真原型的迭代内准备就绪。

比如可用性,做低保原型时尽量用最容易的方式解决问题,不要过早追求“用户体验”玩花样。大量的js互动效果和ajax异步加载会给原型维护、迭代测试带来大麻烦。

再比如标准化,良好结构的web页面,很受应用开发工程师欢迎,样式表则无伤大雅。因此我们可以多花功夫先处理html结构,节省时间让css样式表与功能开发并行迭代优化。

Release.模块化迭代提升用户体验

至此如果一切顺利的话,应用程序已经模块化并测试通过,设计规范也已经模块化、并有针对性的给出了高保真原型界面标准。用户体验的具体指标,已经在高保真原型的迭代中测试通过。

经验丰富的Producer可能都了解,成熟网站真正模块化后的内容其实不多,无非头、尾、导航、页签、表格、列表、搜索等等。传统方法流程的没有把操作体验与功能体验割裂开来,以至于来回折腾,反复做了大量工作才让产品模块化。根据设计规范迭代提升用户体验有两步:

  1. 先处理界面视觉效果,比如分情况美化数据表格、文章列表等。
  2. 再处理界面交互效果,比如可以把某些跨页流程改为层异步加载等。

永远记住不可能一步到位,花本钱的创意设计要用保守方案,用户体验是奢侈的。对多数应用开发工程师来说,使用样式表控制表现是件神奇而时髦的事情。光秃秃的一个架子,加上css马上就能风光起来,并且还不影响已经开发出来的程序,有点不可思议。

其他

敏捷设计思路同样来自前辈们总结过的软件工程思想,只不过换在了设计支持角度。真正的敏捷设计必然与开发绑在一起,只在产品阶段的砍掉文档、砍掉步骤、砍掉管理对全局影响不明显。

对产品团队来说,应该不断利用等待空闲调整规划,用任务分解、故事板等专业手法出文档优化结构。敏捷设计关键不在技术有多高深莫测,而是动作要跟得上节奏,前后衔接得当,才可能把时间一点点抠出来。不墨守陈规,把专业方法打散使用,融会贯通于每个思考点。

UCD翻译小组的同学们已将Boxes and Arrows的这篇Prototyping with XHTML译成中文,操作细节和心得很丰富,关于快速迭代总结的相当好。类似方法我们也已实践近两年,并且主导执行过两款大型产品,核心思想超过90%重合,以上补充了部分本地化快速产出经验。

原文说“只需要花费几个小时,学习一下网上众多的在线教程,你就可以立即开始书写xhtml。”事实上即使计算机背景的同学,没有两三年功力,要实现兼顾前后的无缝协作都很困难,搞不好还会返工增加工作量。但长远来看,这样的训练很有意义,用web方式做web-based产品设计的优势将更垂直的专业、体系化发展。

Spend just a few hours following any of the innumerable online tutorials and you’ll be writing XHTML markup in no time.

团队成员越少,沟通效率越高;每人承担越多,整体风险越低。这是行云流水的产品、技术并行迭代的优势体现。总之,除对瀑布模型进程深刻认识,方法流程得靠团队的内力来推动。

你可能感兴趣的:(产品经理的职业技能)