UED技术层次初探
抛砖引玉：
我的想法：
- 视觉规范和交互规范，以用户研究作为基础。比如全站的色调，基本操作的交互等，都取决于对主流客户群心智模型的研究。
- 前端技术相对独立，在规范的基础上，封装成技术框架供上层调用。这里的框架仅包括基本功能，比如css框架里的reset和grids，js框架里的dom、event等，不含widgets.
- 再上一层是设计模式库DPL(Design Pattern Library). 大部分模式的形成，需要视觉、交互和前端三种技术的融合。比如淘宝首页的幻灯片卡盘，不仅仅是前端技术的产物，和淘宝的视觉规范与交互设计也密切相关。
- DPL是一份文档化的说明，面向的是UED全体设计人员。DPL的背面是技术实现，一般体现在JS框架里，比如YUI的widgets库，jQuery的UI插件库等等，这些封装好的代码组件面向的是程序开发人员。
- 在DPL之上，可以构建各种应用。比如Yahoo的首页，Google的GMail. 每个公司的DPL各不相同，体现的是一个公司整体的设计观。
- DPL负责的是通用模式。具体应用中的特殊模式，还需要直接根据前端框架、视觉规范、交互规范以及用研数据来完成设计和开发。
- DPL初期的构建和维护成本很高，但一旦有效运作起来后，团队将获得丰厚的回报。
延伸阅读：
- Yahoo! DPL: http://developer.yahoo.com/ypatterns/
- The Elements of a Design Pattern
- UI Patterns: http://ui-patterns.com/patterns
March 1st, 2009 on 10:58
和我以前的想法很接近，就差几个字。视觉和交互的部分，我认为到“指南”的层面就差不多了，规范很难定，事实上也很难实施。
而制约规范的制定和实施的最大阻力，是设计师的能力。如果这套东西加给一个平均设计年龄十年的团队，会实施得很好。但如果让一个平均只有2年工作经验的团队，是很难得到理解和实施的。很常见的一种情况，刚入行的设计师很喜欢追求“个性表达”，他们很少能真正从大局去考虑当前这个设计。
所以我认为“指南+首席专家”的制度，比较适合现阶段国内大多数ued的情况。
March 1st, 2009 on 11:27
呵呵，这个框架本身没有问题。
如何有效的传递，实施，才是关键。所以这个图本身是知识层面的图，建议楼主还要出一个保证这套机制工作的组织结构图。
指南+首席专家是一种，如果团队中有JOBS这样的人，如果没有，这事就不太考谱。引申SHARK的说法，可以构建一个用户体验架构组，这个组负责规范（或者叫指南）的制订和推广，负责进行设计战略的制订和实施,负责保证达到设计战略实现的流程和工具。这个组的成员至少有四个角色，每个岗位各出一个资深专家。他们可以直接和那些M说不，那些M建议就不要再做设计工作了。政治往往是专业的最大障碍。
March 1st, 2009 on 15:19
有点深奥
March 1st, 2009 on 19:35
规范关键在于执行，没有强有力的执行，或者缺乏行政上的支持，规范很难推广和执行。
写过一些相关的文章，参见我blog上“用户体验架构”的内容。
March 3rd, 2009 on 0:43
应该还算比较成型了，符合第7条。有机会写一个详细版的，hoho~~
March 3rd, 2009 on 12:27
学习了，多谢楼主分享～～
March 4th, 2009 on 8:28
就像丁宇 说的，没有人执行，也是白费的。
March 6th, 2009 on 11:58
构架还是很清楚的，抛开团队行政结构，UED的产品开发模式如果能基于DPL，那肯定能高效很多。当然DPL不能解决所有问题，不过可以做为UED知识沉淀，可重复的交互设计、前端代码的大集合。 在DPL解决不了问题的地方，肯定需要经验丰富的设计专家和指南性质的文档。所有本质上这个构架和行政的结构没什么冲突，而且好处很多。
leave a reply