也谈前端与设计师的合作
本文是对《现代 Web 开发困局》中“设计/前端协作困境”章节的一些读后感和评论。
在这个章节中，指出了设计和前端由于工具链的原因造成的工作流的割裂和协作上的困难，并且提出了一种解决方案，就是设计和前端共同使用同一种工具进行工作流衔接和资产物料的流转，并使用面向组件的工作方法。
这个观点并不是什么新鲜的观点，全球范围内也有很多大小团队，尤其是研发产品原型工具的公司，都正在或者曾经尝试开发一款新的原型工具，统一这样的工作流。但是结果显而易见，作者作为中国 TOP 大厂的优秀前端，依然没能将这种工作流带入生产环境。
其实这种前端和设计梦寐以求的工作方式早已经在游戏产业得到了实现，它就是每个游戏玩家都知道的虚幻引擎和 Unity 引擎。这两款引擎第一次将游戏生产中的几乎全部工种，包括策划、美术、研发和基于这三大工种衍生出的细分岗位，都统一到虚幻编辑器和 Unity 编辑器中，实现了剧本创意、美术资产、逻辑代码等资产的有效流转和快速迭代。这样带来的好处是，使得游戏开发，尤其是核心玩法的原型开发，可以快速呈现到现实。也就是说，当策划想到了一个绝妙的玩法，为了测试其可玩性（在独立游戏开发中，这是特别重要的一环），以前需要分别去求美术做设计、求程序进行逻辑开发，沟通成本巨大，时间过长，往往等到实现的时候，已经失去了最佳时机；而现在只要在编辑器中就可以统一所有岗位的工作流和美术资产，甚至通过虚幻引擎蓝图系统这种低代码可视化编程工具，策划本人就可以实现游戏逻辑，迅速测试和调整自己的想法。
大前端产业并不比游戏产业规模小，历史也并不比游戏产业短，但为什么至今没有诞生能承载这样工作流的工具呢？
《现代 Web 开发困局》中提出了设计和前端有“职能重叠部分”，为了解决职能重叠，原文写到“从情理上讲，页面样式 这块工作应该归属于 UI，而前端工程师只需要负责 功能逻辑 即可，这样两个工种的工作就正交了”。不得不说，这一句简单的“从情理上讲”，忽略了很多细节，本身就充满了前端程序员的傲慢与偏见；并且在讨论工作流这么大话题中，更是很不可思议的忽略了另一个重要岗位 —— 产品经理。
在记录人类早期驯服前端代码的纪录片《代码奔腾》中，我们可以看到在 20 多年前，Netscape 就搭建了用户研究观察室，借助包括摄像头在内的各种传感器，观察用户使用产品时的各种反应，以此来研究用户体验。这种细致的用户体验哲学和相配套的方法论，随着苹果公司对用户体验的推崇浪潮，在 2005 到 2015 年被传入了中国，并被大厂所采用，各大公司都成立了自己的 UED 团队。那个时候，产品是讲究人文关怀的，每个职位，包括产品经理、设计、前端都可以从中发现各自所在行业的更深层次的系统科学领域，并深入钻研，当这些专业的知识在产品上得以应用后，会得到巨大的职业自豪感和成就感，并获得相应不错的报酬。
但是随后当移动互联网时代到来后，厂商更加追逐用户的碎片化时间和短期利益，产品的功利性和功能性越来越被看中，几乎没有人再提这些“学院派”的老旧用研理论了。产品经理的工作重点不再是输出产品价值、解决用户痛点、维护产品生命周期，而是要么变成了项目经理或者 PMO，要么变成了用原型工具画原型的工具人 —— 甚至高保真原型都已经没人做了。设计师的工作重点不再是深入探索用户心理将用户体验和设计美学结合在一起，而是单纯的使用原型工具进行组件拼凑的枯燥乏味的重复工作。只有程序员岗位一家独大，甚至其重要性被过分的夸大，他们的收入以不可思议的相对速度增长，让整个前端开发行业以不正常的速度泛滥成长。
产品的投入成本是固定的，那么程序员的成本高了，企业必定会降低在产品经理和设计师上的投入，长此以往导致产品经理和设计师的职业地位相对下降，职业自豪感和成就感很难达成，职业成长空间被压缩。同样对比游戏行业，在一起使用那个编辑器的人中，对于游戏公司来说，策划、美术、研发同样重要，这三个岗位都可以通过游戏产品的成功，得到非常高昂的报酬，同时形成自己行业内的独特成长体系，国内的某个游戏美术设计师，可以通过学习不断成长，达到暴雪、EA、UBI 这样顶尖游戏公司的优秀美术设计师的水平。这对于国内的网页设计师和产品经理来说是不可想象的。
国内的设计师并不是没有才能，而是被现在的用工和薪酬体系压迫成了只会用原型工具进行组件拼凑的工具人。回到 2005 到 2015 年的那个时候，Flash 充分释放了网页设计师的才能，国内优秀的网站经常登上 Awwwards 榜单；但是到了今天，你几乎很难看到国人制作出充满视觉创意的网页作品了。Behance 上优秀的动效设计，也只是成为了设计师面试的敲门砖，你从来不会在国内大厂 APP 或者网站中看到如此灵动的视觉效果。国内已经很少有网页工作室（Agency）这种公司了，只有少部分广告公司还在做一些类似的轻量级工作，国内优秀的产品经理、设计师、前端开发资源都被互联网大厂垄断，而在那里，你不需要发挥你的创意才能，你只需要成为公司大生产线上的一个螺丝钉即可。
再说说关于面向组件开发的话题。组件的概念可大可小，我想讨论的是一般前端工程意义上的组件库，类似 Ant Design、ElemenetUI 等。所有的组件库的基础并不应该是功能，而应该是标准，这套标准是从最早的人机交互科学中发展而来的，能够从理论上普适性的覆盖所有人机交互的逻辑。例如 Bootstrap 就是拥有这一硬核基础的组件库的代表，这也正是它为什么经历如此长的生命周期依然毫不过时的原因。
具体一些说，设计语言应该就是这套基础标准中的重要一环，而这也正是国内在做组件库的人最不关心的一件事情。设计语言并不是简单的主题配色、圆角和阴影的 CSS 参数，而是一整套通过美学基础和人际交互科学基础输出的合理的视觉表达的哲学观和方法论。在这里我想举一个简单的例子，例如 Vuetify，正如其名，它是一个 Vue.js 的组件 UI 库，但是官方立场上，他却并不是如此介绍自己的；在它的官网，你可以看到最大的字写的是 “Material Design Framework”，也就是说它的制作者对它的定位是输出 Material Design 设计美学的框架，其次才是 Vue.js。这一立场贯穿了整个 Vuetify 的开发过程，作为这个框架的早期用户，我清楚的记得当年各个组件的功能还不是很丰富，有人会在 Github 上提 Feature Request。对于国内的组件库开发者来说，如果程序可以实现、功能又确实使用，那么就可以排期开发了，甚至都不需要其他人的意见，程序员就可以做主，顶多随后让设计同学出个设计稿。但是在 Vuetify 的开发社区中，首先就轮不到程序员讲话，而是社区参与者在讨论这一功能的引入是否违背了 Material Design 的设计哲学，如果不违背，那么再讨论应该用 Material Design 中的哪一种方法论来进行实现，然后是组件原型和设计稿，最后才会落到代码实现层面，交给程序员实现。所以，有了 Material Design 这一强大的设计语言作为基础，有了 Vuetify 这么严谨的开发流程，使用者甚至可以无需“特别的大开脑洞的创意设计”，而仅仅是将这些组件合理的摆放出来，就可以做出来符合用户体验的优秀产品。这一点在国内组件库是根本做不到的，正因为如此，才需要本应该去做更上层工作的设计师，需要屈尊来做组件的拼凑摆放这种枯燥乏味的工作。
综上所述，搭建归一的工作流和资产流转工具，肯定会为各个岗位都带来学习成本，为了让所有人都接受这额外付出的学习成本和工作付出，同时更重要的是拉齐各个岗位的报酬水平，让各个岗位都能有更广阔的成长空间，能看到进入更高层次的机会，获得职业自豪感和成就感。
而这不是前端开发这一个工种就可以解决的问题。