在上一篇文章「从做设计，到构建秩序」里我们提到，设计系统的真正价值不在于样式和组件的统一，而在于提供确定性。
尤其是通过 Pattern 这种面向问题的抽象思路，把常见问题的解法沉淀下来，帮助设计师跳出细节，专注更高阶的业务思考。
当这套机制建立起来，设计师不再需要花精力来每一次都从头开始。那么问题来了，当这些重复性的工作被系统接手之后，设计师的角色会走向哪里？
今天这篇文章，我就想接着这个问题往下讲讲。
当设计不再从零开始，设计师应该往哪儿走？
设计系统完成某个阶段后，设计师的日常开始变得熟悉甚至有些重复。你会发现，很多事情都已经被提前定义好了，你要做的，仅仅是 “照着来”。看起来轻松了不少，但也开始让人感到焦虑：
如果我的工作变成使用既定的方案，那么我还能创造什么价值？
这是一个很现实的问题，也是在设计系统逐步成熟之后，许多设计师共同的焦虑。
但大家要知道，设计系统的建设从来不是一劳永逸的事。它更像是一个持续演进的过程。随着业务的拓展、产品形态的变化，系统也需要不断被更新和迭代。
它没有“最终版”，也不存在“完成时”。
也正因为它变成了一项长期存在的基础设施，也就不可避免地，带来了设计协作方式的变化。设计逐步走向一定的中心化，秩序逐步显性化。
设计系统构建团队负责制定通用规范，其余设计师则深入到业务，以这些规则为基础推动产品演进。大家在各自“既定边界”内创造更大的价值。
有些人会继续深入到行业和业务中，提炼共识、持续地构建确定性；而其他更多的设计师则走向业务，将 Pattern 和组件当作“标准件”拼装调度，用设计去解决实际问题，推动产品落地。
如果没意识到这种转变，那么依旧会停留在执行细节里原地打转。今天改布局，明天调动效，每天都在赶交付、救火、填坑，忙得身心俱疲，却不知道这些工作是否真的还有价值。
这些看似必不可少的工作，其实设计系统早就在一点点接管。你还在一块块堆砖头，人家已经在起楼了。
但如果你能看清这个变化，意识到设计早就不是把需求一个个画出来。它不是在手动复刻业务流程，而是用系统化的方式，把重复劳动压缩到最小，让真正重要的部分浮出来。比如业务逻辑、产品流程、信息结构等等。
当你开始把这些问题当成你需要解决的设计问题来看，那么就会发现你的设计空间，不是变小了，而是被重新打开了。
其实早在 2020 年，我在负责集团设计中台团队时，就隐约意识到一个趋势：未来的体验设计师，会逐步分化为两类角色 。一类负责构建设计系统、制定规则的架构型设计师，另一类则深入业务一线，推动产品落地与业务增长，是更偏执行与协同的业务型设计师。
当时只是作为一个内部判断提出，并不确定是否成立。但几年过去，越来越多的团队和公司，正在沿着这个方向演进。
这不是因为谁预判得准，而是因为这本就是行业走向成熟、协作方式系统化之后的自然结果。
但这两个方向，真的有清晰的边界吗？我们又该如何判断自己适合哪一条路？这些角色背后，又分别隐藏着哪些挑战和机会？
在这篇文章的下半部分，我想带你一起聊聊我对这两类设计师的理解和观察。
如果你正面临选择，或者正在寻找突破瓶颈的新方向，希望这些内容能为你提供一些思路。
欢迎订阅我的小报童专栏，解锁本期文章全文内容。
