防止微信内出现全文翻译提示。因此在这里放一个充满中文的分区。 防止微信内出现全文翻译提示。因此在这里放一个充满中文的分区。 防止微信内出现全文翻译提示。因此在这里放一个充满中文的分区。 防止微信内出现全文翻译提示。因此在这里放一个充满中文的分区。
2024年11月27日@Aragakey.

做 UI 的开发

印象里第一次对这个话题有分享欲的时候,是在 2021 年中心专业课的 keynote 中。不,更确切的是在那一年读到 InVision Design Engineering Handbook 时。

2022 年,我又在中心内做了一次名为“做 UI 的开发”的分享,又讨论了一些关于“设计理念还原”的话题:

设计理念还原设计理念还原

分享了关于“设计还原”与“设计理念还原”的文字游戏,以及“以工具思想契合自己的思想”等说起来很空的话题。

后来,我在自己的信息茧房中接触到了更多的信息:

  1. 读到 Design Engineering at Vercel 时,觉得这完全是按着我的模子刻出来的岗位描述,感觉是先有的我,才有的这个岗位;
  2. 看到零星的国外公司对 Design Engineer 的招聘信息,对我来说更多的是获取当今行业的需求,比如 Netflixelevenlabscharacter.ai 等;
  3. 在缺失信心时,每每想到 RaunoEmil 这样让我视为楷模的人,我还是会认为自己有绝大部分工程师所没有的才能。

在 2024 年的现在,我倒没有太多的分享欲,工作状态也谈不上充满激情。可脑子里的混乱想法,总还是需要梳理一下。我没有接触太多的事,但希望再谈谈自己的想法。

那些教不来的东西,你也不用学

曾经我因为看到许多关于 Design Engineer 的说法而感到兴奋,也许那些兴奋的时候恰恰也是质疑的时候。

Google 对 UX Engineer 的描述 中提到:

Weave together strong design sensibilities with technical know-how.
将设计上的感受力与技术上的知识 编织 在一起。

InVision Design Engineering Handbook 中提到很多段话:

People love to think in binaries: right brain versus left brain. Creative versus logical. Emotional versus rational. Design versus engineering.

An entire technology exists at the intersection of two different mental models, of design and engineering: CSS.

现在看还是非常有共鸣的,特别是将 CSS 这门语言视为两个不同思维模型的交集这一观点。

然而现在的我可能越来越倾向于收起这样的兴奋了。在对《做 UI 的开发》这一话题有分享欲的过去,我还会说“解绑自己”、“思考形式和功能之间的联系”这样的话。我并不认为自己说的这些话空洞,主要是因为感到它们用处有限。

我无法让你“习惯性地观察 UI 细节”,好让你“丰富自己的感受”,说到底我已经不相信这些。因为我知道这些的价值有限,太多身边优秀的工程师在不同的领域闪光,他们的影响力比我大得多。这没有自我否定和妄自菲薄,我是真的很正面地认为,本就有很多事情可以追求。

有的人认为做 UI 的目标是为了下次可以复用,但我想做的就是不可复用的东西;有的人会对我说这有什么难,而我知道倒推并无意义,想到再实现并没有多少人能做到。

我们只是把重心放在不同的地方而已。兴奋无用,交流无用,鼓励也无用。我开始认为,除非你能够意识到自己是一个适合做那件事的人,否则那些教不来的东西,你真的不用学。

意识到自己是一个适合做 UI 的开发

在今天这个年代,硬要将前端开发者分为“做 UI 的开发”和“做逻辑的开发”,甚至或许是幼稚的。人的价值不应以岗位划分或自我约束。

然而,我还是会在很多个时刻意识到自己不论做什么,都是一个做 UI 的开发。

哪些时候呢?


我今年参与了一个移动端项目的开发,其底层是微信团队基于 Flutter 开发的一套名为 Liteapp 的框架。其旨在提升 H5 业务在微信内的 UI 体验。必须要承认的是,我在这个项目做得挺差劲的。

我没有掌握能做出优雅 UI 的方法,个人认为对于这点自己和 Liteapp 都有责任。

那么,是在保持自省做得很差劲的时候吗?


由于今年适配鸿蒙的优先级较高,前端团队人力有限。我在一个项目中帮助承担了一些涉及业务逻辑与接口的工作。

在这样角色的转变下,设计师想要改变一些基础的 UI,但时间紧迫,我只能推托到明年,而且本身需要输入和学习业务逻辑。和功能相比,UI 的优先级我必须选择舍弃 —— 但我当然有一些纠结。

当前端同事帮助我评估需求时,我们要求和往年逻辑一样,代价是修改设计稿的尺寸或表现。这确实减少了我们的工作量 —— 但我当然也有一些纠结。

那么,是在评估工作量时还纠结于 UI 的优先级的时候吗?


在设计走查阶段时,经常会发现实际效果和设计稿相差巨大。一些时候巨大到没有办法不上升到关于“尊重”的问题。你没有办法用框架、技术等去解释,因为你可以看出来,它们显然不是失误,而是打从一开始就没有想过要还原。或者对这些人来说,他们视设计定稿与粗略原型为同等的低保真的东西。

你只好明白,工程师与工程团队不会因为还原得多好而得到任何正面的肯定和奖励。你真的只能这样解释和尝试理解。

那么,是因为又感受到了自己的基本职责首先是、也必须是保证设计团队的话语权的时候吗?


对于上面的问题,答案都不能说完全正确。

不管是自己做得差劲,或是纠结于 UI 的优先级,还是保证设计团队的话语权,这些都和我自己无关。它们或许首先是因为我属于设计团队,是屁股决定了脑袋的产物。这不会让我意识到自己是一个做 UI 的开发。

  1. 我知道自己做得差劲,而我也知道 这个项目无法代表自己的能力
  2. 我纠结于 UI 的优先级,也并不因为我的屁股坐在哪,而是我 无法轻易地放弃 UI
  3. 我“尊重”设计定稿,并不是因为我的职责,而是因为我知道 正确的 UI 应该长那样

这无关岗位划分,这也没有自我约束,只要有这一点执着,我就是一个适合做 UI 的开发。

适合很难,适合足矣

我并不认为做 UI 这件事就能够代表什么。我会停止讨论价值。正如我所说,理性与感性上自己都应该少一些兴奋或质疑。渴望燃烧,就是渴望化为灰烬。

每个人有适合自己的领域,这件事或许本就应该这样简单与纯粹。无关价值、无关金钱、无关高低。它不需璀璨亮眼,可它不凋不败;它不需妖冶如火,它不盛亦不乱。

曾经招了一个实习生,确实挺喜欢的,技术能力不高却能自己折腾出个人网站,也可以根据一个设计理念整出一个作品。然而他并不是一个适合做 UI 的开发,当然本来也留不下他,他的价值也不在这里。我会被他的一些方面所打动,可这个领域不适合就是不适合。拼错了积木,一开始发现不了,到头来也只能拆掉重来,不论是对个人还是对团队。

组里来来去去,留下的工程师不过自己。我并不将这归结于缘分。适合很难,适合足矣。

在这个环境下,我开始不关注互相理解,因为我们本就无法。我开始警惕要求与被要求、理解与被理解。不理所当然地以为可以倚靠他人,也没有谁需要为你负责。

不希求他人,不粉饰自己。滑进瞳孔的一盏盏路灯不是星星,热带的太阳鸟也不会落在我的树上。我只需面向暖流走向海。难得了,足够了。

我知道顾城说的执者失之。你想当一个诗人的时候,你就失去了诗。你想成为一个人的时候,你就失去了你自己。在你什么也不想要的时候,或许一切才如期而来。