认真的头图

写在前面

年底了，各公司各部门都在为员工考核忙碌着，前几天一位朋友问我UI设计师的绩效该怎么考核？应该以哪些维度作为评估标准？我们都知道如销售的绩效是按销售额为标准的、HR的绩效是按招聘的结果为标准的、产品经理的绩效是按需求的产出和用户的反馈为标准的、测试的绩效是按线上bug数量为标准的......

那么设计师的绩效标准是什么？以支持的需求量的多少？这就像程序猿的绩效不能以代码量来评估一样，写的代码多，但不一定质量高，A写了一屏的代码实现了一个功能，B只用了两行；A写了一天代码的工作量，B只用了两个小时，因为A对逻辑没有思考清楚而不断的删除重写，而B逻辑清晰，代码准确率高......

---

针对设计师绩效考核标准这个问题我大概做了一下总结：

一、如何对待问题

在设计师接到一个需求后，是怎么对待问题的，直接上手做显然不是一个合格的设计师，我们首先应该去弄清楚一些问题：

1、需求的背景是什么？

2、应用的场景是怎样的？

3、要解决什么样的问题？不解决会怎样？

4、该用什么样的解决方案？有没有更好的？

5、预期要达到什么样的目的？什么情况下算惊喜？

6、涉及到的工资量和时间节点的评估

7、...

通过这些基本上可以看出设计师是如何对待问题的和开展工作的，而不单单是为了做页面而做页面，那样顶多也就算是支持需求，对于自我的提升和思考是毫无价值的。

二、如何思考和解决问题

有的设计师接到一个产品需求，就去看竞品是怎么做的，或相似类型的软件怎么做的，然后就直接照搬下来，甚至有的颜色都不改一下的；这已经不是在参考了，而是抄袭，找参考没有错，但我们要有度的参考借鉴：

1、它为什么这么做？

2、它的需求背景和应用场景是怎样的？我们的是怎样的？不同点是什么？

3、它要解决什么样的问题？我们要解决什么样的问题？

4、它的用户人群是哪些？我们的用户人群是哪些？

5、它的优缺点

6、结合我们自身的需求背景值得借鉴的地方和更好的方式

三、沟通方式和问题的跟进

不管是需求前，需求中，还是需求后的交付，其实都是一个不断沟通的过程：

1、需求前弄清楚需求背景、解决的问题，思考是不是有更好的解决方案，而不是产品需求怎么说就怎么做；如果有更好的方案应与产品及时沟通，而不是闷头做，做完后再与产品核对，若考虑不周全方案被否，既浪费时间精力又耽误了工期；需求中及时和产品、开发沟通自己的想法，以保证后期方案顺利进行；交付后及时跟进及上线后的反馈效果，验证方案的有效性及可优化的点

2、沟通推进的过程中能够有条理有依据去阐述自己的想法；

3、换位思考，结合需求价值、开发成本、工作量、时间节点综合考虑最优方案

4、主动跟进及复盘线上的问题，可优化的点提出优化方案，跟进迭代

四、学习能力和自驱力

每做一个项目，我们都应该总结经验；犯过的错、踩过的坑也应该及时复盘总结汲取教训；确保下次遇到这样的问题至少不会再蒙逼；交过的学费也肯定不能白交。

如果一个设计师每次在做类似项目的时候都用同一种方式，遇到一个类似的问题都用同一种解决方案，固有的思维不去做创新，不去做改变，懒得思考新的东西，那么你顶多算一个页面的搬运工，只会复制粘贴。

1、同一个问题，每过一个时间段后应该有一个更深层次的思考、看能不能站在更宽的角度看待问题和解决方案，这样才能不断突破，得到自我提升

2、不再只是看专业技能类的书籍，更应该多去看如心理学、人机工程学、人文历史等更宽知识面的书籍，加宽自己的知识面，在看待问题的时候能站的角度更高，考虑的更为全面

3、专业领域的不断自我提升，不断巩固已知的同时也要积极的去学习新的东西，这样才能跟上设计趋势的潮流，不断做练习、做总结，而不仅仅是工作上的；不进则退，做好自己的学习计划，不盲目，不浮躁，有时候慢就是快，重在坚持。

---

总结：

我认为设计师的绩效是没办法完全量化以数据来考核的，你说这个设计不好看，你的评判标准是什么？你了解这个设计的需求和背景吗？显然这样的判断过于主观和感性；因为好看的设计不一定好用，尤其是页面设计，肯定是以易用性为第一的，就如有些设计师一味的追求极简、追求美学，做出的页面很好看，配色很好，构图很好，也很有艺术范儿，但在用户看来却不知所云，重点是什么？该怎么去操作？商业需求要体现它的商业价值，这是首要的，也是最基本的，在这基础上再去考虑美学的东西，是锦上添花。如果连基本的需求价值都没有体现，这几乎就是无效的设计。毕竟设计不是艺术。

虽说所有的成绩都是以结果为导向的，但设计师的绩效考核大多应该参考整个设计过程，过程中他们所做的事情和思考可能远比你想象的多的多......