产品交互设计要素.docx

网站产品交互设计要素多时候，往往以为自己理解了概念，却只有等再理解下个概念之后，才明白以前认识还不够。我们都是在某个点出发，逐渐放大试图了解全局，然后才可能正确认识自己的位置，并找到适合自己的突破口。长久被专业名词困扰和误导，我知道它们肯定是一体的，但如何分类、组织、建立联系，让整个框架立体化，合理解释似乎并不是那么容易。基于自己现阶段知识结构，以及同行们反馈的各种观点，重点介绍新突破。行业，在何种业务内做事？ 指导理念，在哪些原则下做事？ 工作方式和流程，一个人怎么做事？ 团队协作，一群人怎么做事？ 组织理念并分层思想信仰——以用户为中心的设计实现目标——良好用户体验具体指标——可访问性、兼容性、可用性、标准化、搜索引擎友好接受来自 IBM的概念定义 启发，依次分为思想、目标、指标三大逻辑层面。关键在于指标问题上，我认为web-based产品因为客户端多样性原因，远不止可用性这一项，经过补充排序结果如下：可访问性、兼容性、可用性、标准化、搜索引擎友好。可以看到可访问性、兼容性、标准化、搜索引擎友好都是web-based产品独有的，这也是做web比做soft麻烦的根本原因。相对来说，我处理可访问性、兼容性、标准化、搜索引擎友好，比可用性更得心应手，这与我的背景、经验和兴趣有关。因此我不会去做soft-based的事情，并且完全有理由相信，可用性不是最重要的指标。理念只是贯穿全局的方针原则，并不具有实操的指导意义。虽然理念都有独立中心思想，但操作层面有交集，所以容易引起各种争论。在做事角度，任何理念角度深入下去，都可能不同程度见到效果。但要把事情做到极致，需要平衡各项指标。组织流程和方法概念阶段——网站目标、用户需求、功能规格、内容说明设计阶段——信息架构、交互设计、界面设计、导航设计、信息设计、视觉设计制作阶段——原型制作、前端编程曾在 纵深协作方式 中提出扁平结构协作初步设想，减少沟通环节避免理解缺失，用灵活性来适应互联网的快速产出和快速迭代，整个流程就分概念、设计、制作三大阶段。《用户体验的要素》所提的战略、范围、结构、框架、表现五层对理解帮助很大，但不适合走操作流程。同时，书中观点对应提出来的各专业方法，我认为还缺少对web-based原型工作的支持，因此容易造成与开发之间的断层。这部分俗称“前端开发”工作一直都处在前后不搭的尴尬地位，补充两个关键点，第一属于产品设计范畴，第二还有原型制作、前端编程两个层级。组织角色和交付物产品经理——蓝图产品设计师——文档产品工程师——原型曾在 模拟高效团队 中提出标配三人团队的初步设想，也是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. 关联理念、流程和交付物思想信仰——概念阶段——蓝图实现目标——设计阶段——文档具体指标——制作阶段——原型理念都是前人花时间花精力总结出来的、带有哲学观点的清晰表达，是做知识传承的重要参考。肯定都是虚的，实际的东西没资格叫理念。理念只可能“引导”做事，而无法指导，易学难懂也最无趣。但为避免混淆，和更有针对性的解决问题，还得努力搞清楚。典型如标准化，针对前端开发提出了一系列颠覆性思路，但目前互联网还是个市场占有率确定标准的时代。从操作层面看，四年前我认为 太过理想化 ，现在依然保持此观点。各层级概念应该对应到做事流程，并有阶段性的产出。在结合流程、交付物后，从这条纵向线索中很容易看清“以用户为中心的设计、用户体验、可用性”之间的区别。同理，迭代也应尽量保证在各阶段内完成。上线后的产品，再去试图更改概念阶段的游戏规则，基本等于推倒重来。关联交付物、角色和方法蓝图——产品经理——网站目标、用户需求、功能规格、内容说明文档——产品设计师——信息架构、交互设计、界面设计、导航设计、信息设计、视觉设计原型——产品工程师——原型制作、前端编程曾在 用户体验的误解 中提出角色对应方法初步设想，我非常不赞同专业“用户体验团队”的协作方式，难道产品经理们做事不考虑用户体验么？还是说把用户体验先留着，等某些人来做？显然不可能，因