那些能力差的设计师，都喜欢说这10句话

2018-08-04

网上已经有不少文章在说如何识别出一个好的用户体验设计师。

我这篇文章偏不这样，相反地，我想在这儿讨论一下怎样识别出一个糟糕设计师。

这儿有10句只有糟糕设计师才会说的话，准能帮你把他们揪出来。

1. 我是用户体验设计师，所以我知道什么对用户是最好的！

这个想法很多设计师都会有，认为自己比其他利益相关人员或团队、甚至用户自己还了解他们。当设计师总能够坚持己见却很少遭到质疑的时候，他的这种想法就会变本加厉。

必须清楚一点：无论你在一个行业里工作了多久，你的所有想法在未得到验证之前都只是假设，你得去证实这些假设。如果你不做验证，你的方案就缺乏立足之地。这就是为什么我们常说，好的设计师一心为了解决用户的问题，而一个差的设计师只做那些令自己满意的方案。

2. 上次这个方案管用，这次我们还这么做吧。

希腊哲学家赫拉克利特有句著名的话：人不能两次踏入同一条河流。在用户体验设计里，在一个场景下有用的方案，换了一个场景后可未必有用。每个产品都不同，你要从实际项目切入，找到最合适的工具和方法。

3. 这个方案从用户体验角度看起来有些认知负荷过重，我们需要做一次启发式评估来判定我们的初始假设是否成立。

上面虽然只是一个例子，但足以见得「专业术语」在平日对话里多么令人讨厌了吧。这些话在设计团队内部说说还行，和其他合作团队分享设计想法的时候，就经常会造成疑惑了。上面这句话虽然说的挺好，但过于「专业」的表述方式对那些不熟悉设计术语的人来说犹如天书。他们可能会被术语绕晕，不明白你想说什么。

虽然不少专业术语能让你看起来「不明觉厉」，但你在组织大家一起开会或演说你的设计方案的时候，可不是为了显摆自己的吧，最终目标还是获取大家有价值的反馈。

作为用户体验设计师，一项重要技能就是把复杂问题用简洁的方式讲明白。当你把用户体验方案说得简单明了，离获得大家的赞同就不远了。

4. 没时间做原型了，先让产品上线，边看边改吧。

跳过原型制作而直接动用大量资源开发实际产品是设计团队中一个常见而且很危险的错误。当我们花了大量资源去创造一个我们认为很棒的产品，而上线后却发现产品方案根本行不通的时候，可就真的压力山大了。

产品原型能让你在开发团队真的展开开发工作之前就测试你的假设是否成立。最好在早期方案阶段就检测出问题并及时修复，否则等产品上线了再去修复相同的问题，成本就大多了。IDEO 的创始人 David Kelly 就说过：早点跌倒才能早点成功。

建立一个原型不一定就要耗费很多时间。设计师可以利用各类设计方法去进行原型验证。有一种有用的方法叫「快速原型验证」，这个方法很火，通过快速建立一个可迭代产品，比如一个网站或 App，并找一组真实用户来做测试。

5. 这个产品已经设计完了，我可以做下一个产品去了。

有些设计师认为一旦产品上线并能在市场上存活下来，他们的工作就结束了，然而事实上，产品设计的流程可远没有结束。绝大多数情况下，产品上线后你的工作可能比之前更重要。一个设计师必须通过分析用户数据来验证产品：关注用户是如何和产品互动的，并从中找到机会点来调整设计方案，让产品体验更好。

上面这段话还反映出一个更严重的问题，缺乏「主人翁精神」。如果一个设计师说了上面那句话，就说明他没有想要对自己的设计方案负责任。

6. 我是个创意型人才，别和我谈技术。

有些设计师虽然认为开发和市场营销这些知识对设计一个产品很必要，但他们却很少花些时间去学习这些领域的知识，说到底还是停在舒适区里裹足不前。

实际上打破知识的界线是用户体验设计师提升技能的好途径。多和开发者聊一聊、和市场团队打成一片，试试从他们的角度去看待产品问题。这也能让你学会鉴别哪些合作者是好的。乐于学习新知识，并怀着同理心去看待合作团队，才能做出更好的产品。

7. 领导想要什么产品我们就做什么产品。

听从领导的「建议」在设计行业中是个普遍现象。毕竟大家都心知肚明，做一个领导想要的产品，推进过程就会比较容易。

然而这么做是有很大风险的。不能因为一个人位高权重就认为他说的每句话都是对的。用户体验设计师要对产品负责，一旦产品出了问题，设计师则很有可能是第一个被骂的人。这就是为什么一个好的设计师必须也是一个好的沟通者。需要让大家的意见都被纳入设计的思考范围，而不仅仅是领导的意见。

8. 要么就按我说的设计，要么我就不干了。

想象一下：你已经做了用研并且发现了不少可用性问题，你希望产品团队能把问题全部解决，你很确定你说的是对的而且不愿意接受妥协方案，你告诉对方如果不解决这些问题，那这个产品的体验就会很差。

当然了，为了自己的设计方案据理力争是用户体验设计师的必备技能，但另一方面，设计师也需要意识到实际情况并学会接受：没有一个团队的资源是无限供应的，所以不可能用有限的资源在产品上线前解决所有体验问题。这也是为什么团队协作一定会要求某种程度上的妥协。为了能让事情得以进一步推进，你需要将你的需求按优先级排序，让协作团队优先解决最紧要的需求（比如那些对体验危害最大的问题），并同时敲定次要问题的解决安排（比如建立一个产品问题清单）。