作者: 一叶千鸟
UED全称User Experience Design，中文叫“用户体验设计”。
UXD全称User eXperience Design，中文叫“用户体验设计”。显然这两个词还是一回事情，但要比UE迟的多。最早我在2005年底从Yahoo那边了解的，大概2006年听到同行普遍提起，同年9月份“淘宝UED”团队博客建立之后，才被大家熟知。但中国互联网公司最早成立部门研究“用户体验”的不是淘宝，而是百度，当时就叫“用户体验部”，后来才被同化的UED。大概在2005年已经有30人左右成型的团队（用户体验部总监郭宇，于2004年11月加入百度）。
首先UED这个词来自海外，但在海外除Yahoo很少有公司提起。如前文所述，老外并不习惯叫UE，所以理论上描述“用户体验设计”的缩写不应该是UED，而是UXD。确实也有UXD的说法，但只偶尔在某些海外网站上见到，同行心目中的认知程度不高。
再仔细推敲，其实不难发现，UED这个词有误。因为“用户体验设计”的说法本身有问题，UE并不能通过Design完全解决，通常Design涉及的只是UE比较表层的Experience需求。事实上，海外公司普遍都叫“UX团队”，也没有“UED团队”的说法。
而UED来到中国后，反而成为主流论调，得到广大公司的认可。可见与UE类似，UED也具有很浓的本地化色彩。在进入用户体验执行层面之后，很多同行/公司的第一反应，是要有这样的一个人，或者有这样的一个团队。因此才有了“UE工程师、UE设计师”和“UED部门”类似的称谓。
早期UED部门设立的职能职位主要有用户研究、交互设计、视觉设计，慢慢后来加入前端开发、界面设计等，某些甚至把产品经理也划入其内。具体叫法五花八门、千奇百怪。有个重要差异值得探讨，关于“工程师、设计师”的区别，根据理论推敲，既然UE是个非理性话题，不似Usability那样有逻辑可以遵循，有标准可以执行，所以我认为偏重“感性”的用户体验应该更靠近“设计”。
当然，以现在的成熟观点来看，不管叫“UE设计师”还是“UE工程师”都是不合适的，因为本身用户体验设计就不应该是一个人或一个部门的工作，而良好用户体验是产品的全方位目标。从执行层面看，用“概念”来命名职位（如可用性工程师），明确职能（如产品部门、用户体验设计部门并存），都不利于团队协作，容易造成责权不分，具体我在2008年6月所写用户体验的误解中大概清晰了执行思路。
http://mashable.com/2009/01/09/user-experience-design/
User experience isn’t just the responsibility of a department or a person, That compartmentalist view of UX is evidence that it is not part of the organizational culture and hints to teams not having a common goal or vision for the experience they should deliver collectively.
有趣的现象，几乎国内所有公司组建的“用户体验设计团队”都叫UED，并且已经形成固定用语，比如淘宝UED。只腾讯有个用户研究与体验设计中心(Customer Research & User Experience Design Center)，简称叫CDC。
2008年之后，应该说业内UED发展达到高峰，互联网一线公司基本都组建了自己的UED团队。除淘宝外，阿里系公司先后还有阿里巴巴UED、阿里妈妈UED、阿里软件UED、支付宝UED、中国雅虎UED、口碑UED。业内其他还有百度UED、搜狐UED、网易UED、携程UED、金蝶友商网UED等等，都在互联网上有网站（绝大多数就是个blog）宣传和公关。大有成为互联网公司标准配置的趋势，从业者也以能进入这样的“专业团队”为荣。
我更倾向于腾讯CDC这样以专业研究机构名义的命名，如此更利于用户体验“理念”的推广，而不会造成部门之间的“隔绝”。事实也证明，成立“用户体验设计”部门走业务流程，自下而上推动产品质量提升的效果并不明显。容易给其他同事造成“做用户体验是那帮人的事”的错觉。
以大家喜闻乐见的Google为例子，2005年7月Google在中国设立研发中心，也相继设置了用户体验部门。与当时的百度一样，不叫UED，而且执行体系沿袭Google风格，基于产品而不是部门（注意此区别），一般由PM+Developer+Designer组合的小团队共同向产品负责，有时会有Researcher介入。产品组同事各有所长，展开平级协作，由整个团队来推动用户体验设计。
归根结底，体制决定一切。如今类似小团队跨部门的协作方式已被国内互联网公司积极学习，并且取得了良好效果。在执行框架内，如果UED脱离产品进行盲目细分，堕落成为用户研究+交互设计+视觉设计+前端开发，我认为将很不利于产品的创新、迭代、改进。
本文系作者授权数英发表，内容为作者独立观点，不代表数英立场。
转载请在文章开头和结尾显眼处标注：作者、出处和链接。不按规范转载侵权必究。
转载请在文章开头和结尾显眼处标注：作者、出处和链接。不按规范转载侵权必究。
本文系作者授权数英发表，内容为作者独立观点，不代表数英立场。
未经授权严禁转载，授权事宜请联系作者本人，侵权必究。
未经授权严禁转载，授权事宜请联系作者本人，侵权必究。
本内容为作者独立观点，不代表数英立场。
本文禁止转载，侵权必究。
本文禁止转载，侵权必究。
本文系数英原创，未经允许不得转载。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权，侵权必究。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权，侵权必究。
评论
评论
推荐评论
暂无评论哦，快来评论一下吧！
全部评论（0条）