网站产品交互设计要素(2)

组织角色和交付物

产品经理——蓝图
产品设计师——文档
产品工程师——原型

曾在 模拟高效团队 中提出标配三人团队的初步设想，也是Google的行事作风。

交付物部分值得商榷，按照《Communicating Design》的总结有需求、设计、策略三类，但我认为有两大问题，第一把所有产出都叫documents欠妥，第二缺少对web-based产出的指导。按属性分为蓝图、文档、原型三类比较恰当，把蓝图从文档中独立出来，原型则是必要补充。

去年曾提出过 使用页面线框图 提速设计流程，也不止一次公开分享其成果，核心指导思想是提高灵活和可控性，用web的方式做web-based产品设计。最近更有Prototyping with XHTML 作者称之为“一个伟大的方式从xhtml原型开始。”

a great way to embark on that journey is to start prototyping with XHTML.

关联理念、流程和交付物

思想信仰——概念阶段——蓝图
实现目标——设计阶段——文档
具体指标——制作阶段——原型

理念都是前人花时间花精力总结出来的、带有哲学观点的清晰表达，是做知识传承的重要参考。肯定都是虚的，实际的东西没资格叫理念。理念只可能“引导”做事，而无法指导，易学难懂也最无趣。但为避免混淆，和更有针对性的解决问题，还得努力搞清楚。

典型如标准化，针对前端开发提出了一系列颠覆性思路，但目前互联网还是个市场占有率确定标准的时代。从操作层面看，四年前我认为 太过理想化 ，现在依然保持此观点。

各层级概念应该对应到做事流程，并有阶段性的产出。在结合流程、交付物后，从这条纵向线索中很容易看清“以用户为中心的设计、用户体验、可用性”之间的区别。同理，迭代也应尽量保证在各阶段内完成。上线后的产品，再去试图更改概念阶段的游戏规则，基本等于推倒重来。

关联交付物、角色和方法

蓝图——产品经理——网站目标、用户需求、功能规格、内容说明
文档——产品设计师——信息架构、交互设计、界面设计、导航设计、信息设计、视觉设计
原型——产品工程师——原型制作、前端编程

曾在 用户体验的误解 中提出角色对应方法初步设想，我非常不赞同专业“用户体验团队”的协作方式，难道产品经理们做事不考虑用户体验么？还是说把用户体验先留着，等某些人来做？显然不可能，因为方法一旦脱离具体业务就成了学术论证，方法不可能创造结果，只可能加速完成。

根据专业方法制定角色，或走设计流程，我觉得都不可取。做互联网设计，应该学会身兼数职。况且所谓的专业方法其实就那么点东西，上手很简单，现在全球知识共享又几乎没门槛，学会做事太容易了。在人才培养角度，懂方法再熟练业务的难度，肯定要超过懂业务再学方法。

最好的Producer，有人可以带领大家做的更好，没人自己也能抗下来。

——————————

Ver1.2 具体指标新增用户友好、开发者友好，并统一页面指标的语法。
Ver1.1 为更细致体现专业性，对专业方法做出调整，继承《用户体验的要素》所做总结。
Ver1.0 图右上增加了目标导向说明文字。