从 UI 设计师到系统型设计负责人

2016 年加入 vivo 时，我的工作从系统公共模块与工具产品开始。状态栏、通知中心、计算器、录音机等项目让我建立了系统 UI 的基本认识：一个设计选择必须与信息结构、操作效率、系统规范和工程实现同时成立。那时我关注的是如何把具体方案做准确，也在反复交付中理解系统产品为什么需要稳定的规则。

变化的是问题尺度

之后，我参与的工作逐渐扩展到视觉创意和设计传播，包括 OriginOS 相关视觉实践、壁纸和不同传播触点。这个阶段让我从页面内部走向更完整的设计语言：不仅判断界面是否清楚，也开始思考一个概念如何被理解、视觉气质如何跨媒介延续，以及表达是否忠于产品本身。

再往后，工作进入版本级策略、设计体系和工具迁移。问题不再只属于一个页面或一个项目，而是跨越多个团队、时间周期和资产类型。我需要参与定义方向、建立判断原则、推进协作，并确认阶段成果能否被下一轮工作继续使用。

回看这段经历，我并不认为职业成长是从“做设计”变成“管人”。更准确的变化，是我面对的问题尺度不断扩大：从一个控件到一个模块，从一个项目到一组产品，再到版本方向、规范体系和团队工作方式。

成为设计负责人以后，我仍然需要看具体方案、信息层级、视觉细节和实现状态。方向如果不能落到页面选择上，就无法验证；管理如果脱离真实设计过程，也很容易只剩进度与流程。

同时，我也不能把所有关键判断都留在自己手里。我的职责包括把问题讲清楚、让团队理解判断标准、为不同成员建立合适的责任边界，并在关键节点确认质量。具体成果来自团队共同完成，我需要做的是让正确结果不依赖某一个人的临场判断。

早期，我会自然地用完成了多少页面、解决了多少问题来衡量工作。现在我更关注：团队是否能够持续做出正确结果。一个方案结束后，原则有没有留下来；一个组件完成后，责任是否清楚；一次工具迁移后，协作方式是否真的改善；出现错误后，团队是否形成了新的检查机制。

这并不意味着个人能力不再重要。相反，负责人需要有足够具体的专业判断，才能知道何时应该介入、何时应该留出空间。只是评价的时间尺度变长了：不再只看一次交付是否漂亮，也看这套工作方式能否在下一次问题中继续成立。

我仍在学习如何平衡具体与抽象、质量与节奏、个人判断与团队成长。系统型设计负责人不是一个完成态，而是一种持续扩展问题边界、同时保持设计敏感度的工作方式。