Comments on: UED技术层次初探

By: zman

zman — Fri, 06 Mar 2009 03:58:55 +0000

构架还是很清楚的，抛开团队行政结构，UED的产品开发模式如果能基于DPL，那肯定能高效很多。当然DPL不能解决所有问题，不过可以做为UED知识沉淀，可重复的交互设计、前端代码的大集合。在DPL解决不了问题的地方，肯定需要经验丰富的设计专家和指南性质的文档。所有本质上这个构架和行政的结构没什么冲突，而且好处很多。

By: 无语

无语 — Wed, 04 Mar 2009 00:28:11 +0000

就像丁宇说的，没有人执行，也是白费的。

By: 番茄超人

番茄超人 — Tue, 03 Mar 2009 04:27:29 +0000

学习了，多谢楼主分享～～

By: iceshow

iceshow — Mon, 02 Mar 2009 16:43:05 +0000

应该还算比较成型了，符合第7条。有机会写一个详细版的，hoho~~

By: 丁宇

丁宇 — Sun, 01 Mar 2009 11:35:41 +0000

规范关键在于执行，没有强有力的执行，或者缺乏行政上的支持，规范很难推广和执行。

写过一些相关的文章，参见我blog上“用户体验架构”的内容。

By: 蓝色生死恋

蓝色生死恋 — Sun, 01 Mar 2009 07:19:56 +0000

有点深奥

By: tiandiyoudamei

tiandiyoudamei — Sun, 01 Mar 2009 03:27:54 +0000

呵呵，这个框架本身没有问题。
如何有效的传递，实施，才是关键。所以这个图本身是知识层面的图，建议楼主还要出一个保证这套机制工作的组织结构图。
指南+首席专家是一种，如果团队中有JOBS这样的人，如果没有，这事就不太考谱。引申SHARK的说法，可以构建一个用户体验架构组，这个组负责规范（或者叫指南）的制订和推广，负责进行设计战略的制订和实施,负责保证达到设计战略实现的流程和工具。这个组的成员至少有四个角色，每个岗位各出一个资深专家。他们可以直接和那些M说不，那些M建议就不要再做设计工作了。政治往往是专业的最大障碍。

By: Shark

Shark — Sun, 01 Mar 2009 02:58:04 +0000

和我以前的想法很接近，就差几个字。视觉和交互的部分，我认为到“指南”的层面就差不多了，规范很难定，事实上也很难实施。
而制约规范的制定和实施的最大阻力，是设计师的能力。如果这套东西加给一个平均设计年龄十年的团队，会实施得很好。但如果让一个平均只有2年工作经验的团队，是很难得到理解和实施的。很常见的一种情况，刚入行的设计师很喜欢追求“个性表达”，他们很少能真正从大局去考虑当前这个设计。
所以我认为“指南+首席专家”的制度，比较适合现阶段国内大多数ued的情况。