以数据为基础
数据，是每个公司都会关心的东西，至少到某一个阶段来说，数据有时候会被“神化”，比如伟大的Google公司，就是一个很典型的数据为一切的公司。
用数据来给我们作为设计导向也是一种很普遍的现象。很多时候设计师对数据便显得无可奈何，因为很多时候数据会成为创新设计师的绊脚石。看看前Google首席视觉设计师Doug Bowman的离职文章，就能看出来鲍曼对于Google用数据作为设计基础产生的愤慨。
数据就像一把双刃剑，有时候我们能用测试结果的数据来说服运营部门利用我们的设计方案，但也有时候运营部门会拿着数据来告诉我们他们的所需。其实作为一名产品设计师来说，对于数据的把握会成为自己对于产品设计的一种经验，就想铸剑师把握火候一样。
一、把握数据的轻重
其实作为数据它只能代表着过去的用户行为，它不能对以后产生影响或有前瞻指导。在进行一些新产品项目设计时，作为产品设计师从运营或者用研拿到一些数据时，要对数据进行自己的判断，这时的数据只能属参考作用，而不起任何引导性或决定性的作用。所以设计师不能被数据牵着鼻子走，要判断数据在这个项目中的轻重权衡。
二、挖掘数据的隐形需求
可用性工程师或用研的同学们会将标本分析整理成数据报告。很多产品设计师会忽略这些报告，认为这些报告对于自己的设计没有太大的帮助，只有拿着自己DEMO去做可用性得出的结果才会改正。而我觉得作为产品设计师，应该更早的参与到用研的过程中。把用户行为习惯，喜好等也作为标本的经历背景来考虑到产品设计当中。比如，iPod的设计时，发现很多用户听歌曲时，不愿意去选择歌手或专辑，他只想随便听听打发时间而已。所以，shuffle的功能就应运而生了。所以不要忽略数据报告后面这些用户行为习惯。
三、先减后加的数据
“少即多”的交互设计原则我想很多设计师都了解。所以对于数据，我们也可以用这样的原则，一个数据代表产品一个属性，那么我们需要抓住产品核心需求，用数据的权重进行排列，之后和核心需求的属性进行对比，从而抓住产品的重点。而不是一股脑啥时髦的功能都放上去，而不考虑数据和需求。
还有很多公司，只在乎某个项目产品开发时的数据调研，当产品上线后就会将这些数据扔到一边。我们应该保留产品开发整个过程中的数据，且某些属性的数据可以归档整理成为一个纵向的整理属性。比如Personas就是数据积累所形成的一种UCD设计方法。
来自: 麦兜的设计 点击查看原文
以产品设计为中心
UED团队包括：交互设计师、视觉设计师、用户体验设计师、可用性工程师、产品设计师和前段开发工程师等等。
UED团队主要的目的是为了将公司的产品变得更加好卖，那么团队不仅仅考虑的产品的可用性或易用性，也需要具备卖产品的能力和对潜在用户的判断， 因此感觉UED应该是具有一定的综合能力的团队。
从“以产品设计为中心”这点上来看看UED团队该是扮演什么样的角色。
不过之前先给“产品”做个定义。
个人感觉现在大部分公司的产品可以分成两种属性，
一类是新市场开发型的产品，一类是现有产品优化型的产品。
前一类型的产品更适合市场产品经理去做，而UED团队主要负责后一类型的产品设计。
一、产品的话语权
在公司里，每个部门都觉得自己是很重要的，因此在产品设计的各个环节，这些部门都会参与讨论，那么各个部门和角色在讨论中的话语权在其专业角度上，都是比较具有权重的。因此，如果该产品是以UED为主的产品的话，当然，决定权在UED手中，但要权衡其他部门的意见，特别是产品经理和市场部门的。
二、部门协调能力
很多时候，产品会像在生产线上的一样，被一个部门丢到下一个部门去。这样的方式适合在具有一定标准和规则的情况下，包括我之前常常说到的创新设计也是可以进行工业化模式生产的。但我不建议这样的去做，特别是在还没有UED团队的公司来说。对于UED团队的每个角色来说，都需要具备这样的部门之前的协调工作的能力。日常的需求处理按照生产线流程走，而项目产品的设计开发，建议可以适用项目组开发形式来作为尝试。当然不仅仅是把各个角色位置都搬到一起坐而已，最重要的是解决协作的能力。
三、以产品设计为中心
这里的设计当然不仅仅只是视觉设计咯。因为很多人理解来说，产品进入到UED环节，就是给制定颜色，设计一些交互方式而已，这样只能算是以产品为中心的美化而已。我觉得首先是老板们需要将一些优化类的产品放手给团队去做，其次也需要团队自己具有主人翁的意思，从以往的美工或交互设计的圈圈中调出来。因为每个人都会对产品有自己的认识，那么通过一些方法把认识形成大体上的统一。而这期间，不要忘记团队的力量，团队中每个角色都会有自己的思考。这时产品设计师需要收集这样的思考，然后做出一个团队统一决定的目标。
来自：未开窍的石头 点击查看原文