首先，很荣幸能够加入 淘宝的 UED 团队 。期间也有很多朋友问我，「UED 是干什么的」、「你竟然不写 PHP ，去写 Javascript 了？」，等等问题 -- 的确不幸的是，作为「传统程序员」的我，之前对于前端开发的理解，都会笼统的认为那是「美工」的事情。

然而这个观点，在我进入这个团队一段时间以后，发生了点改变 -- 目前我一点也不怀疑，前端的工作会比服务器端轻松多少。OK，废话不多说，下面说下我对于 UED 的认识和见解。

UED（User Experience Design），从字面的意思上理解就是「用户体验设计」。在解释这个名词之前，就不得不说到 UE（User Experience，用户体验）方面的概念。

说实话我有点讨厌那些概念性的解释，任何这样类似的知识都可以从网络上找到。 百度百科上对于「用户体验」的解释 ，可以总结归纳为「用户用你的产品感觉怎么样」（ 维基百科上解释 更详细，不过需要跳墙访问）。

总而言之，按照我自己的话说，_UED 的使命就是让用户用我们的产品用着爽_ -- 这句话可以分成几个部分，即「用户」、「产品」还有「爽」。「用户」是服务对象，「我们的产品」是产出，而「爽」是目的。

所以，UED 相比传统的开发人员更多了两层额外的因素。第一，就是面对用户；第二，就是面对产品。这就是为什么我感觉前端开发者并不比「传统程序员」要轻松的原因。

从技术角度上理解，前端开发人员当然要熟悉相关的前端开发知识，比如 CSS、Javascript 以及 HTML（是的，没有开玩笑）；更「要命」的还要理解一些概念上的知识，比如 Web 标准 等等。

还要可能会和后台开发人员相互沟通合作，这就有可能需要写基本的服务器端的知识，比如 PHP 、甚至 数据库 等等。

而最重要的是，除了技术层面上的东西，还要跨出开发人员这一角色 -- 更多时候是扮演设计师的角色。所以，必须

具有战略眼光、研究产品方向（范围）、优化产品架构（结构）、视觉创
新与规范（界面）于一身，专业特质使得他站在以用户为中心的设计、研
究层面思考一切问题。

-- 偷个懒，引自 白鸦老大的 Blog 。

就说这些了。阐述这些概念的目的，其一是能让我的朋友们了解我的工作，其二能让自己明确目标，并朝这个目标努力。

再贴几个链接，以便大家能更深入理解

1. UED 是什么样的部门
2. UE 是怎样的一个部门，描述你心中的 UE
3. UED应该向产品负责，而不是向 PM 负责

附，文中插图部分引自 淘宝 UED 招聘页面 。

很多人对于淘宝评价的表单 有微词 了，近些天留意收集了下淘宝的评价表单页面。看得出正在不断的改进中，在这里表示关注和支持。

下面看图不说话：

原评价表单

版本一（目前在用的）

版本二

还有一个我以前对于此的评价表单的草图，个人对 版本二 比较满意。不知道大家更倾向于哪个？

这不是一篇罗列了很多规则的范文，而是个人的一点点牢骚。其实我以前也发过 类似的牢骚 ，而这次也是按照常理，不写下来不会痛快。

人们总是认为自己做的成果是有价值的，而关键就在于怎么去让用户接受它们。相信普遍的用户和我一样，都非常的懒惰，他们甚至不会考虑你精心设计的按钮是做什么的。

前几天安装 Msn 的时候，发现在安装过程中的有一个非常棒的选项（虽然全都是打钩默认的）。微软多年的软件开发经验，的确在细节之处发挥到了极致。

而我在网易查看一些信息的时候，页面突然弹出所谓的调查窗口着实让我「吓了一跳」。我很反感这所谓的调查，因为我关注的是我需要的信息。就这一点，相信对于有基本用户设计概念的朋友，能够非常容易的理解。

就这点，本人认为 Msn 的设计是真正的处于用户的角度上考虑的，而网易则需要进一步的改善。

正如我上述所言，用户不会明白你精心设计的按钮到底是干什么的，所以在这个 Web2.0 时代开发人员不得不「蛊惑」用户，而将按钮拼了命的放大。这就造成了非常有趣的现象，就是进入了「大控件时代」。

再举一个比较极端的例子，例如下面的软件你知道先从那里下手不（一款 Oracle 管理软件）？

这正是本问要说明的观点。让用户接受你的产品，比如首先要做到不要打断用户的行为（好比谁都不会在领导忙的时候提出加薪要求），其次就是尽量做的简单（把用户当作「傻瓜」）。

当然用户友好方面的设计不仅仅完成这两点就足够了的，还有很多需要注意的地方。听听别人怎么说的，比如 这里 还有 这里 （在白鸦大哥这里确实能学到很多的东西，在这里表示感谢）。