你丫才美工
所有从事互联网行业的人，都知道有个工种叫做「美工」，当然他还有许多其他的名字。比如，南方的就喜欢自称「页面仔」，「切图仔」，而之前腾讯的同事就喜欢称我们为「构建」，意思是构建页面结构的工种。虽然美工，构建这些名字看起来没那么高大上，但也不能说带有歧视，只是我们都不太喜欢这些名字。
所以你要注意了，作为前端方向的自嘲是「页面仔」，「切图仔」没有任何问题，但是跟别人开玩笑，最好还是不要说别人是「页面仔」，「切图仔」，这可能是我们内心最后的倔强了哈哈哈。
其实早些年真正的美工的工作，是可以从设计到实现一手包办的（现在称为全栈设计师）。
那么，这个岗位从什么时候开始变得感觉有点 low 了呢？这可能要从《网页重构》这本书，以及这个岗位的诞生开始。重构，就意味着推翻过去的东西，重新构建新的规则制度。美工，由于参与的流程比较长，所以也不可避免地难以做到每个环节都很完美，甚至很糟糕（全栈工程师？呵呵）。所以导致的结果就是，大量素质很一般的从业人员乘着互联网的大潮，进入了美工这个岗位，最后设计设计做不好，代码代码写不好。最终留给人的印象就是：美工都在做一些粗制滥造的东西。
这个结论我只能说，确实有这样的现象，但也不能以偏概全。而且，现在除了有些公司还在招所谓的「淘宝美工」之外，几乎也见不到用美工这个 title（岗位名称，职称）来招聘的了。不过单说写 CSS 这件事，却不只是美工在做的。某年的 The Ultimate CSS Survey 中，第二题就是关于角色的调查：
Which of the following most accurately describes you?
A. I’m a designer that writes CSS B. I’m a front-end developer who does some design C. I’m strictly a front-end developer D. I’m back-end developer who writes CSS occasionally E. I’m a full-stack developer F. Other
我们可以看出，无论前端后端还是设计师，都可能会写 CSS，或者说都可以写一些 CSS。这也从侧面说明，仅仅是 write CSS 并不能成为核心技能，do some design 也是一样。那么 HTML 就更不用说了，单纯技术层面的两板斧，都不能成为核心竞争力。
因此，大家心里一个普遍的认知就是 HTML 和 CSS 很简单，真正的程序员也经常对这些东西嗤之以鼻。总体的印象就是：「简单」，「算不上程序」，「不就是切个图的事儿吗？」。对，这就是对于这个岗位的一个基本认知，至少不了解这个岗位的人，只能联想到这些了。
由于这个角色的 title（岗位名称，职称）实在太多了，我还是统一用 UI 工程师比较好，至少是个比较新的 title 吧。既然是新的 title 必然会有些新的定位，以（2015 年以前的）腾讯为例，许多部门的 UI 工程师也都归到了 T 族（技术族）的通道中（曾经有一段时间是在设计族）。然而，尽管职级通道划分到了技术族，但编制往往是在设计部门，或者是跟着产品线走。那么设计部门中的 UI 工程师，就成了设计师中最懂代码，程序员中最懂设计的一拨人了。
这种略微有点错位的身份关系，也曾让我们迷茫。说是设计师吧，也做不出像样的设计稿；说是工程师吧，只做些页面搞搞动画好像也谈不上工程。唯一一个经常被我们挂在嘴边的词就是「用户体验」，但用户体验又是个很大的范畴，我们能把握的也只有页面的性能，酷炫的动画等等。这些东西确实可以从某种程度上提升体验，但究竟有多大作用，很难去量化。
比如一个按钮，加了 CSS3 动画的比没加动画的点击率高，这就一定能说明体验更好了吗？在页面总 PV 没变的情况下，这个动画是否会让这个按钮哗众取宠，影响了其他元素的关注度呢？当然，我们可以用数据说话，用基数足够大的 A/B Test 去印证它的效果。但是实际工作中，真的有资源去支持你验证这些小动画的作用吗？
所谓身份的错位，是你的角色在部门不是很重要，在整个产品研发流程中也没那么重要，你的价值很难体现，或者悲观一点说，就没那么大价值。
前面我说到 UI 工程师不受重视，这可能不是普遍现象，而且就我本人的经历来讲，我已经在有限的资源内，得到了足够的重视。我所说的不受重视，其实应该说是推动力有限，在整个产品流程中的影响力有限。比如你对你所做的页面有些不同的想法，尽管希望很渺茫但你还是希望能对你做的产品产生一点影响，那么在 UI 层面，向上游你可能需要说服交互设计师、设计师、产品经理，向下游可能还需要跟开发去沟通。所以在常规的产品研发流程中，你几乎很难去影响到你做的产品。
这里面有个特殊的方向，就是电商类的运营活动和卖场，以及各种游戏宣传页等需要大量应用动画效果的地方。在这样的项目上，UI 工程师可以向需求方提供专业的动画效果建议，但，往往也要说服设计师同意你的效果，并且配合你一起制作图片素材。
再举个性能优化的例子。相信很多 UI 工程师都做过所谓的页面性能优化项目，提升首屏打开速度什么的。进行这样的项目往往要先分析页面性能瓶颈，拿到当前的参考数据，再从文件大小、图片大小、连接数、动画帧数、脚本加载时机，blabla 等等逐项提升。
这其中，文件大小可能是开发人员搞定的；图片大小可能需要运营人员和设计师一起配合，如果规范不好，即使自动压缩也很难尽如人意；连接数可能需要运维支持推进服务器 combo，或者前端开发推行本地合并；动画帧数什么的倒是 UI 工程师可以控制的，CSS 文件大小也可以控制，不过很可能运营上传一张大图，你的 CSS 压缩就白费了。从这个例子可以看出，除非你有强大的项目推动能力和跨部门沟通能力，所以类似这种项目，往往都是虎头蛇尾，无疾而终了。
凡事都有两面，不受重视也一样。一方面你可以说你明明很努力了，但是领导就是不认可；另一方面，也可能是你真的没有体现出足够的价值，所以才得不到认可。这其实是个悖论，无法明确因果，很多事情没有领导支持就推行不下去，推不下去就体现不出价值。而另外一些事情呢，领导重视了，期望高了，你反倒可能达不到领导的预期了。这里面具体可能又涉及到复杂的 KPI 导向以及一些人情世故等等，往往不是写代码的 UI 工程师能参透的。所以，这里我们能做的往往是，尽人事，听天命。
说到底，所有岗位的产生都是有社会分工造成的，而在 UI 层面，许多公司单独分离这样一个工种也是合理的。从个人角度，专精和广博本就很难权衡，设置细分岗位有助于专精。虽然很多人做着做着就觉得到了瓶颈，但从职业发展的角度，先专精一个方向是对的。从公司角度，职业的细分可以提升组织的稳定性，降低用人成本。一个再优秀的 UI 工程师离职，也不会造成太大的伤害，不可替代性没那么强。更何况，设立这个岗位的公司本就不多，所以一定程度上形成了劳动力的垄断，因为跳出这些公司的圈子，就很难找到工作，所以轻易也不会动。
话说回来，公司的目的是盈利，虽然有基本的社会责任和愿景，但本质还是为了赚钱创造价值。那么在这个基础上的福利，公司文化，岗位设计，职级体系，薪酬体系，都是服务于这一个目标的。所以在 UI 工程师这个岗位的设计上，对公司是没有坏处的。当然，公司足够大的情况下，具体做的事情还是有很大差异，比如有些 UI 工程师要写 native 应用界面，有些只负责 web，还有些要写 JS 和 PHP 等。我说这些的目的，是想告诉你，不要试图从本质上去修正和抱怨 UI 工程师这个角色，因为本质上，它是合理的存在。
在这样一种错位的身份下，每一个 UI 工程都不可能不焦虑，即使是已经做到团队 leader 的同学也一样。为什么呢？因为 UI 工程师的群体正在弱化，即使是 UI 工程师本身也并不看好这个岗位。不可否认，确实还是有几家大公司里，有那么一群拿着很高薪水的 UI 工程师，但是在大部分情况下，他们也离不开这几家公司了。因为，能提供这个岗位，或者说对 UI 层面有这么高要求的公司并不多了。
管理者也是一样，管理 UI 工程师的经验未必能去管理其他前端工程师。而从 UI 工程师做起能够一路攀升的更是凤毛麟角。这真的是能力的问题吗？当然不是，也没有人愿意承认。只是这个角色限制你只能看到那一点天地，角色限制了你能接触到的人员，也限制了你的思维方式，和影响力范围。
记得我做页面重构的时候，我可以影响产品去改改 UI，可以帮运营去优化工具，可以给开发提建议去优化代码。但是，作为普通员工的我，几乎没有什么机会见到更高级的领导，也没有什么需要我们这个角色露脸汇报的。而开发和运营就不是，往往一个重点大项目就需要跟大领导汇报，完成之后也有各种庆功宴等等可以一起吃饭。我说这些，并不是说多想跟领导套近乎，只是客观地说明你接触的范围会相当有限，所以交流的思想和内容也会受限。跟 level（级别） 比你高的人交流，即使只是听君一席话，可能也收获颇丰，这是不争的事实。
还有一个侧面可以印证你的重要性，那就是看你能闯多大的祸。以一个互联网产品来说，你能偷到用户数据吗？你能删除数据库吗？你能让网站挂掉吗？你能让支付通道失败吗？显然，这对于 UI 工程师来说是不太可能的。我们可以让页面没有样式，但职业的素养要求我们在没有样式的时候也要保证可用；我们可以让页面的图标加载不出来，不过用户可能都不会发现… 所以，我们能闯的祸微不足道，那么我们对于产品所负的责任也几乎忽略不计，责任也就对应了我们的价值。
我们的角色定位，注定没办法直接体现到产品价值上。这也是焦虑的重要原因，工作没办法直接体现价值，就很难获得真正的成就感，你只有融入更大的团队通力合作产出的成果，才能稍微感受到一点成就。