第2步：交互设计师输出主任务的用户行为操作流程、界面结构或信息架构，期间与产品经理密切讨论;
第3步：交互设计师输出主要界面交互原型图，期间与产品经理、视觉设计师密切讨论，通过全员审核;
第4步：视觉设计师输出主要界面效果图，期间与产品经理、视觉设计师密切讨论，通过全员(尤其是权威角色)审核;
第5步：交互设计师补充剩余交互原型图，视觉设计师补充剩余效果图，通过全员审核;
第6步：交互设计师输出交互说明文档，通过开发评审;
第7步：产品经理将需求文档、交互说明文档、效果图合并为产品设计文档; 正式开发阶段：
第8步：开始正式开发，期间与产品经理、交互设计师密切讨论(此过程最好不要有大的变更);
第9步;测试阶段，交互设计师等各种角色提出细微修改建议(理论上此过程不能出现任何变更); ……
理想的研发流程VS快速研发流程
理想的研发流程
实际上最理想的产品研发流程是在开发前制作出可操作的高保真原型(既不是效果图也不是用axure简单演示的原型，而是主线任务完整的、至少可以进行可用性测试的原型，详见《启示录》一书)，并不断进行可用性测试、专家评估，循环修改，然后按照最终确定的原型进行开发，再不改变任何内容。这样可以极大程度的免去需求变更导致开发重做的可能，并且预防因赶时间而放弃迭代修改，此外还可以免去阅读冗长拗口的说明文档，但更重要的是，将发出的产品已经有了相当有把握的验证。
像苹果、以及国内有些重视用户体验的网站就是采用的这种理想的开发流程。但网站类产品胜在可以快速实现前端DEMO、输出高保真模型，而国内的软件市场就很少有这么做的，基本上都要求产品快速产出，尽快去真实市场占个坑，再去验证和修改，根本不会给产品设计相关人员这么多时间和成本去仔细设计和验证。所以快速研发流程实际上是最常用的，虽然不算最完美，但却很快速，在架构和平台比较成熟的公司比较适用。
对比之下，快速研发流程中显示出一个很严重的风险，在版本出来之前谁也不知道真正的体验是怎样的，所有的过程都是依据经验的预测，如果版本出来后才发现问题，小的还可以改改，大问题根本来不及改正。所以评审和经验就显得尤为重要，这也造成了这种流程中，各种角色都保守异常、纠结致死，更是鲜有创新突破，只敢在小地方微创新一下。 因此全新的软件产品最好用理想研发流程，除非改起来非常简单，而快速移植类或系列产品可以用快速研发流程，但坚决不能边设计边开发，产品经理和设计师们必须提前足够的时间先启动。
产品研发流程与合作之交互设计讲课稿 - 图文
