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

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

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

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

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

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

　　尽早用web原型评估设计质量
　　制作避免过早陷入web结构和表现细节
　　设计避免过早陷入功能细节
　　每个业务都会有核心功能，也就是用户的核心需求，基本上做产品前都会考虑清楚。可能核心功能内还会有核心模块，意思就是逐步提炼，找准关键点下手，这样才能搭好框架。也许经过几次迭代后，这部分工作已经是个可以跑起来的低保真产品，颇具alpha版本规模。

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

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

　　web呈现效果迭代。先做图再切效率太低，因此我是直接用css美化低保真原型，通常这步可以把效果做的很得体。实在有必要，最后再截屏用photoshop处理细节并完善css。
　　web结构和表现迭代。我自己可以完成html framework, css framework两大块。
　　web行为迭代。需要工程师协助完成javascript framework。
　　也就是说，在包括beta版本以及之前，重中之重是实现功能需求层的良好用户体验。可访问性、兼容性、可用性、标准化、搜索引擎友好这些具体指标不要过早引入到应用开发中，让它们都在高保真原型的迭代内准备就绪。

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

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

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

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

　　先处理界面视觉效果，比如分情况美化数据表格、文章列表等。
　　再处理界面交互效果，比如可以把某些跨页流程改为层异步加载等。
　　永远记住不可能一步到位，花本钱的创意设计要用保守方案，用户体验是奢侈的。对多数应用开发工程师来说，使用样式表控制表现是件神奇而时髦的事情。光秃秃的一个架子，加上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.

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

　　? 一叶千鸟（转载请留原文链接）

　　原文：http://blog.rexsong.com/?p=2365