这里小编给大家分享一些UED团队建设：以数据为基础的设计交互设计（共含6篇），方便大家学习。同时，但愿您也能像本文投稿人“xhdixndj”一样，积极向本站投稿分享好文章。
数据，是每个公司都会关心的东西，至少到某一个阶段来说，数据有时候会被“神化”，比如伟大的Google公司，就是一个很典型的数据为一切的公司，
用数据来给我们作为设计导向也是一种很普遍的现象。很多时候设计师对数据便显得无可奈何，因为很多时候数据会成为创新设计师的绊脚石。看看前Google首席视觉设计师Doug Bowman的离职文章，就能看出来鲍曼对于Google用数据作为设计基础产生的愤慨。
数据就像一把双刃剑，有时候我们能用测试结果的数据来说服运营部门利用我们的设计方案，但也有时候运营部门会拿着数据来告诉我们他们的所需。其实作为一名产品设计师来说，对于数据的把握会成为自己对于产品设计的一种经验，就想铸剑师把握火候一样。
一、把握数据的轻重
其实作为数据它只能代表着过去的用户行为，它不能对以后产生影响或有前瞻指导。在进行一些新产品项目设计时，作为产品设计师从运营或者用研拿到一些数据时，要对数据进行自己的判断，这时的数据只能属参考作用，而不起任何引导性或决定性的作用。所以设计师不能被数据牵着鼻子走，要判断数据在这个项目中的轻重权衡。
二、挖掘数据的隐形需求
可用性工程师或用研的同学们会将标本分析整理成数据报告，
很多产品设计师会忽略这些报告，认为这些报告对于自己的设计没有太大的帮助，只有拿着自己DEMO去做可用性得出的结果才会改正。而我觉得作为产品设计师，应该更早的参与到用研的过程中。把用户行为习惯，喜好等也作为标本的经历背景来考虑到产品设计当中。比如，iPod的设计时，发现很多用户听歌曲时，不愿意去选择歌手或专辑，他只想随便听听打发时间而已。所以，shuffle的功能就应运而生了。所以不要忽略数据报告后面这些用户行为习惯。
三、先减后加的数据
“少即多”的交互设计原则我想很多设计师都了解。所以对于数据，我们也可以用这样的原则，一个数据代表产品一个属性，那么我们需要抓住产品核心需求，用数据的权重进行排列，之后和核心需求的属性进行对比，从而抓住产品的重点。而不是一股脑啥时髦的功能都放上去，而不考虑数据和需求。
还有很多公司，只在乎某个项目产品开发时的数据调研，当产品上线后就会将这些数据扔到一边。我们应该保留产品开发整个过程中的数据，且某些属性的数据可以归档整理成为一个纵向的整理属性。比如Personas就是数据积累所形成的一种UCD设计方法。
相关阅读：
UED团队建设：以产品设计为中心
半年里，遇到过很多公司在寻找建设适合自己的UED团队或部门，他们大多为建立这样一个UED部门而沾沾自喜，很多公司只是将原有的美工团队并到了产品经理团队，在我去过的公司比较常见。那么怎么来建立这样的一个用户体验团队，期间有那些地方需要注意，从我自己的角度来谈谈吧。
众所周知，UED团队包括：交互设计师、视觉设计师、用户体验设计师、可用性工程师、产品设计师和前段开发工程师等等。按照公司不同的阶段职位会有不同的增加。那么把职位分这么细就能组件一个UED部门了么？答案是否定的。
UED团队主要的目的是为了将公司的产品变得更加好卖，那么团队不仅仅考虑的产品的可用性或易用性，也需要具备卖产品的能力和对潜在用户的判断， 因此我觉得UED应该是具有一定的综合能力的团队。
我想先从“以产品设计为中心”这点上来看看UED团队该是扮演什么样的角色。不过之前先给“产品”做个定义。个人觉得现在大部分公司的产品可以分成两种属性，一类是新市场开发型的产品，一类是现有产品优化型的产品。前一类型的产品更适合市场产品经理去做，而UED团队主要负责后一类型的产品设计。
一、产品的话语权
在公司里，每个部门都觉得自己是很重要的，因此在产品设计的各个环节，这些部门都会参与讨论，那么各个部门和角色在讨论中的话语权在其专业角度上，都是比较具有权重的，
因此，如果该产品是以UED为主的产品的话，当然，决定权在UED手中，但要权衡其他部门的意见，特别是产品经理和市场部门的。
二、部门协调能力
很多时候，产品会像在生产线上的一样，被一个部门丢到下一个部门去。这样的方式适合在具有一定标准和规则的情况下，包括我之前常常说到的创新设计也是可以进行工业化模式生产的。但我不建议这样的去做，特别是在还没有UED团队的公司来说。我觉得对于UED团队的每个角色来说，都需要具备这样的部门之前的协调工作的能力。日常的需求处理按照生产线流程走，而项目产品的设计开发，建议可以适用项目组开发形式来作为尝试。当然不仅仅是把各个角色位置都搬到一起坐而已，最重要的是解决协作的能力。
三、以产品设计为中心
这里的设计当然不仅仅只是视觉设计咯。因为很多人理解来说，产品进入到UED环节，就是给制定颜色，设计一些交互方式而已，这样只能算是以产品为中心的美化而已。我觉得首先是老板们需要将一些优化类的产品放手给团队去做，其次也需要团队自己具有主人翁的意思，从以往的美工或交互设计的圈圈中调出来。因为每个人都会对产品有自己的认识，那么通过一些方法把认识形成大体上的统一。而这期间，不要忘记团队的力量，团队中每个角色都会有自己的思考。这时产品设计师需要收集这样的思考，然后做出一个团队统一决定的目标。
现在UED部门都在向着产品设计方向靠了，所以从用户体验到产品设计是一个方向。而这过程中对于团队每个角色来说又会是一个新的学习方向。
本文来自：www.maidow.com/blog/?p=282
最近做Presentation用的稿子，
虽说是Internet，仅限网站而已，不包括软件。我没做过软件，但一直认为，网站的交互实现要比软件麻烦的多，因为客户端的原因。
交付物环节尤其重要，我发现有个误区是必须要XX软件才能做XX。日本人做产品几乎就用PDF, XLS, TXT, HTML四种文档，他们用Excel的水准非常高，因为觉得花钱买了正版，就要把有价值的功能使够，
我们的问题正在于备选项太多，如果自始自终都只有Excel，只有Word，相信大家都能练出来。
公司预装软件全正版，那些太先进和稀奇古怪的东西只能在自己电脑上做。仔细想想，人家节约成本也没什么不对，谁让咱学艺不精呢，十年前的Excel都玩不转。
互联网的用户体验设计过程：internet-ued-process.pdf
来自：blog.rexsong.com/?p=1118
抛砖引玉：
我的想法：
视觉规范和交互规范，以用户研究作为基础，比如全站的色调，基本操作的交互等，都取决于对主流客户群心智模型的研究。
前端技术相对独立，在规范的基础上，封装成技术框架供上层调用。这里的框架仅包括基本功能，比如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: developer.yahoo.com/ypatterns/
The Elements of a Design Pattern
UI Patterns: ui-patterns.com/patterns
本文出自：lifesinger.org/blog/?p=1416
三天前，支付宝ued上发表了这样一份文章《潜谈产品设计中的可用性和可访问性》，这篇文章突然让我很想抬一杠。
文章举了一个注册页面的例子，说该页面的编码没有考虑到js禁用的情况，会在禁用js的浏览器中引发注册错误，结论是这属于没考虑到用户的”应用场景”。
说实话，我还真的愣了一下，因为的确难以联系到应用场景上去，因为这并不是一个应用场景设计的问题，而是一个标准的软件测试问题。支付宝ued明显混淆了界面设计、交互设计与软件工程的领域内涵。
在传统的、标准的软件工程测试中，有一种方法叫做”黑箱测试”，其目的就是故意通过破坏性数据、制造非标准条件来诱发软件错误。在标准的WEB测试种，也有一种”兼容性测试”和“环境测试”，在支付宝ued的文章中，浏览器不支持js脚本，就属于一种非标准条件测试。同样的，如果浏览器换成Mozilla、Firefox、Chrome…都属于一种标准的浏览器兼容性测试，其方法是创建一个兼容性矩阵，在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。浏览器的安全性设置和JAVA设置本来就是题中应有之意。
而可用性工程中的应用场景设计，隶属于可用性方法中的用户调研方法，定位于交互设计的角色定义阶段，其内容是描述非技术性的、与用户业务和工作场景直接相关的用户资料。在用户场景中，的确可以对用户的电脑做一般性描述，比如配置档次如何、性能如何、主要用途为何，但绝不能细化到电脑中的操作系统中的浏览器中的js的安全性这种级别上，
简单的说，用户应用场景定义的是用户接触界面之前的事情，用户接触界面之后，对应的是交互设计和界面设计，这是在角色定义完成之后的。即便两者有交叉迭代，那也是有先后关系的：用户场景定义为交互设计和界面设计提供输入。
而浏览器的js安全性、操作系统是否中毒、用户输入法是五笔还是拼音….这些统统可以抛给测试。可以是传统的软件工程测试，也可以是原型级的、非原型级的可用性测试。
如果，按照支付宝的这种可用性设计理念搞下去，大批的设计师可以收拾东西走人了，因为它又把体验设计应当尽力撇开的技术因素再度无情的捆绑在了体验设计的战车上。
支付宝ued的这种初级错误，其实已经陷入了自己的悖论中。因为它只考虑了js的兼容性，却没考虑css。如果用户的浏览器两者都不支持，你怎么搞呢？如果支付宝的测试团队任务艰巨，没时间进行兼容性测试，那么我们可以理解。但如果就此把这些内容划归到本不相干的场景设计中来，则完全是因为不理解可用性设计的基本内容和范畴。该文章的特点，在于可以快速吸引一批js、css程序员的注意力，却就此敲了所有体验设计师一记闷棍。更不可思议的是后面竟然还扯出了”语义化”……
不过有一点，支付宝ued说对了，那就是这个问题的确”不是前端开发工程师要去考虑的”。
本文出自：douis.wordpress.com.cn//01/19/92/
来杭州快五个月了，自从进入UED，整个人的思路会不由自主地带上U的色彩，这就叫融入吧，不是模式化的做作，而是自然而然的落听，一旦进入角色，就会用U的视角思考周遭。两个月前的Z大学之行感慨颇多，沉淀了许久依然挥之不去，所以能够肯定，那不是一时的思绪游离，可以拿出来 了。
思考一：刚来杭州时去了一次Z大学，发现Z大学的校标与世界著名品牌阿玛尼的LOGO非常相似，当时没有跟他人说起，想着自己怎么这么没文化，这都能掰扯上，这么有名的学府之校标岂能容许我这般意淫。无奈第二次去的时候，Z大学的校标处处可见，又一次冲击了我的眼球，让我不得不再次无法自拔地往阿玛尼上靠。应该是我出身调研行业，关注过奢侈品品牌的LOGO，才会有这种困惑，大多数人未必会在意这个问题，不过我还是想深究一下。
经查证，才了解到1990年12月15日Z大学在校报上公布了校标设计稿的二个方案，经教职工和学生投票，选定了第一稿，并作修改后，于1991年1月31日的校务会议再次审议了修改后的校标。这样正式通过了现在的校标。
当初Z大学校务会议成员确定校标的时候，是否考虑过与阿玛尼LOGO相似这个问题呢？>如果考虑过为什么还要挑战已经辨识度这么高的已经存在的标志呢？>是因为一个是教育机构，一个是奢侈品品牌，领域不同而无所谓？抑或一个代表求是鸟，一个代表老鹰，寓意不同而没关系？还是自信这一标志最能代表Z大学而不能割舍呢？——这些问题没有答案，当时的决议是否讨论过这些问题不得而知。但如此设计，A知道阿玛尼LOGO的人会很快记住Z大学的校标，也会在内心揶揄一下；B不知道阿玛尼LOGO的人，如果对校标有印象，以后见了阿玛尼LOGO，会有种似曾相识的感觉，而有可能错愕于两者的相似；C不知道阿玛尼LOGO的人，以后见了阿玛尼LOGO，又有机会看到Z大学校标，也可能会纠结；D其他。
原谅我这般罗列，我不是故意扩大问题，只是这涉及到标识易识易记与唯一识别的问题。延伸到我们网站LOGO或页面的设计，同样有这样的问题，设计师最痛苦的事是一个自己满意的作品做出来了，却跟别的作品如此相似；最最痛苦的事莫过于，与其相似的作品那么的广为人知，自己却未察觉，嚎~
怎么解决这痛苦，别固步自封，怀抱开放的U心态，广泛涉猎，是解脱的方法，
此事的另一个细节，Z大学在校报公布校标设计稿时，校长办公室委托工会和团委发放了1200份印有两个方案的选票，分别征求教职工和学生的意见。通过比较，大多数师生员工倾向于方案一，即以传统的表现刚健、博击个性的“求是鸟”为主体所构成的校标设计稿。
广泛听取广大师生的建议并采用调研的方法是相当可取的，只是，调查了哪些教职工和学生，操作的方式是怎样的，并不清楚，是否科学不得而知，不做评论。反观我们平时的工作，广泛听取网站用户的意见肯定是出好作品的硬道理。但是，怎样操作才能保证收集到的意见具有科学性、推广性？这就需要U们了解各种调研方法的特点、能解决怎样的问题、如何正确操作和分析等，一旦调研方法出问题，豆腐渣无法炼出钢。
思考二：在Z大学往事休闲吧，翻看毕业纪念册，第一次看到了Z大学的校歌，立马被震了，果然是江南文人之地的大学，校歌都这般古色古香的韵味十足，有文采、有内涵。但旋即不由得担心起来，校歌的推广性怎样？>如果入学之初必有校歌的修炼，那需要多久能完全掌握？>Z大学的学生应该都会唱校歌，时过境迁，有多少能记住歌词？又有多少能完全理解其中的含义？
不必深究人家的家务事，但由此联想到我们网站各项服务的说明文件，如果晦涩难懂，或未从用户角度编辑解说内容，后果肯定不堪设想。同样，从商业化角度看，一个插件、一个按钮、一个排版···········，如果理解起来很生硬，肯定不是好设计，如今的网络世界优胜劣汰的规则，加入了太多用户的使用体验，广大用户用着不爽的，推广性就差；如果想着培养用户的使用习惯，让其加入过多的思考，并不能是商业化好设计的精髓。这就如同一个有实力的唱片歌手，如果他（她）坚持走个性化艺术路线，唱片就卖得不好，而变成商业化风格，迎合普罗大众，唱片就可能卖得好；电影也是如此，好莱坞大片受追捧，票房高，自然有他的道理。作为一个实务性的网站，理想化的好设计与商业化的好设计怎样权衡，我们的用户使用习惯需要如何去培养，这些都需要我们在做产品的时候深入思考。
*以上内容纯属个人YY，只是就事论事，各位别拍我。
本文来自：ued.taobao.com/blog/2009/12/28/ued-think-%e7%94%a8%e6%88%b7%e7%a0%94%e7%a9%b6/
★ 方便和交互设计
★ 设计基础教学
★ 设计团队口号
★ 数据收集教学设计
★ 建设设计合同范本
