混合岗位很强大，但只在合适的环境中才如此

关于为何“UX工程师”、“UI工程师”和“设计工程师”这类角色日益增多——以及它们真正依赖于哪些条件的个人思考

近几个月来，我注意到越来越多的招聘启事不再简单地写着“UX设计师”或“UI设计师”，而是出现了“UX工程师”、“UI工程师”或“设计工程师”这样的职位名称。

乍一看，这些头衔似乎是熟悉角色的变体，但它们却预示着数字产品构建方式的转变，以及哪些技能正变得愈发重要。出于个人兴趣，以及对国际就业市场和软件与科技行业趋势的好奇，我一直关注这一发展。

这种变化之所以引人注目，是因为它遍及多个行业和不同规模的企业。

我曾学习计算机科学与媒体专业，主攻可用性工程、用户体验设计、UI设计及人机交互。对我而言，设计与技术始终密不可分。我希望理解交互理念如何转化为代码，设计决策如何影响系统架构，以及为何有些想法易于实现，而另一些则不然。

这种好奇心自然而然地把我带入了比传统UX或UI岗位更为综合的角色。多年来，我还开发了许多基于Angular的前端，并搭建过一些简单的云原生后端，因为我想亲眼见证设计决策在真实系统中的表现，以及概念如何演变为可运行的应用程序。

从各大公司的招聘信息来看，这种跨领域的思维方式如今已被明确列为人才需求。谷歌将UX工程师描述为“通过交互式原型和生产就绪的UI组件，弥合设计与工程之间的鸿沟的人”。

苹果使用“设计技术专家”这一称谓，并写道：

“设计技术专家工作于设计与工程的交汇处，负责原型设计并构建交互体验。”

Meta将设计工程师定义为“扩展设计系统，并构建各产品通用的UI基础”的人。IBM则招聘负责设计系统的前端开发人员，要求其“构建并维护IBM旗下各产品共用的设计系统组件”。

微软同时聘用“设计技术专家”和“UX工程师”，并表示：

“设计技术专家创建原型及生产级质量的UI，以验证并落实设计概念。”

虽然称谓各异，但其核心理念却如出一辙：将设计与工程视为一个相互关联的整体。

软件工程领域的一个类比有助于解释这一演变。过去，开发与运维泾渭分明：开发人员编写代码，运维负责基础设施。随着系统日益复杂，这种割裂变得不切实际，于是DevOps应运而生，成为连接两端视角的角色。

随后，SecDevOps出现，因为安全与合规已无法事后叠加，而必须融入开发流程。设计领域也正在经历类似的变化：UX与UI长期分离，后来被整合，最终诞生了同样兼顾技术层面的设计工程角色。

这些角色是否代表未来，尚难断言。我也无法评判它们孰优孰劣。可以观察到的是，它们多见于产品复杂度高、设计系统居于核心地位、需支持多平台且团队紧密协作的环境中。

在这样的背景下，既懂设计又懂技术的人才尤为宝贵。而在其他场景下，比如超大型设计团队，或职责划分极为清晰的项目中，传统的UX与UI角色依然具有重要意义，不可或缺。

问题不在于这些融合型角色是“对”还是“错”，而在于它们适用于何种环境。当它们旨在连接不同学科而非取代彼此时，才能发挥最大价值。

它们需要团队有意利用这种连接，并拥有能使其系统性工作的组织架构。在这样的环境中，它们能够产生深远影响；而在其他情境下，它们往往只是现有角色的延伸，未能从根本上改变工作方式。

我时常思考自己该称作UX工程师、UI工程师，还是设计工程师。对我来说，答案与其说是头衔本身，不如说取决于所处的环境。我的好奇心驱使我涉足那些融合多重视角的岗位。

至于将其称为“设计工程”或其他什么，则取决于团队的工作模式及其界定的职责范围。头衔的变化源于工作的变化——而这或许正是值得反思之处。

归根结底，这仍是基于我的背景、兴趣，以及在软件与科技行业中所见所感的个人观察与经验。

参考文献：

• 《人、角色与成长：HCI职业的演变》：https://dl.acm.org/doi/10.1145/3796540
• Google UXE——将所有技能融于一身：https://uxe.withgoogle.com

混合岗位很有力量——但前提是环境合适最初发表于Medium上的训练营，人们在那里通过点赞与评论继续围绕本文展开讨论。