设计战略与体系建设

从项目到方向

在早期设计工作中，我面对的通常是一个模块、一个产品或一次明确的交付。随着参与 OriginOS 3、4、6、7 等不同阶段的版本级规划，我需要处理的问题逐渐跨越多个业务和团队：设计要回应什么目标、哪些命题最值得优先解决、不同项目怎样形成共同方向，以及阶段成果如何进入下一轮迭代。

我的工作重心因此从解决单个设计问题，转向定义设计命题和判断原则。这里公开的只是角色与方法，不包含任何未公开版本的具体策略、产品方案或组织信息。

设计战略如何落地

对我而言，战略不是一组宏大表达，而是一条能够不断向下验证的路径：

版本目标 → 设计命题 → 判断原则 → 关键体验 → 组件与规范 → 案例与治理

版本目标提供方向，但仍然需要被翻译成团队可以讨论的设计命题。命题再转化为少量判断原则，用于选择关键体验和验证方案。当原则能够解释真实页面中的取舍后，才适合继续进入组件、规范与案例。

我会参与方向梳理、关键方案判断和跨团队推进，但体系成果来自多角色共同工作。产品、研发和不同设计团队提供的约束与反馈，会直接影响原则是否成立。我的职责是让这些信息在关键节点被看见，并推动团队形成足够清晰的共同判断。

HIG 与规范体系

HIG 不是静态文档集合，也不只是组件属性的说明。它需要连接设计原则、组件能力、真实案例和责任机制：原则解释为什么，组件提供稳定能力，案例说明如何在具体场景中使用，责任机制则保证内容会被维护。

如果规范只记录结果而不说明边界，团队仍会在新问题上重复争论；如果规范过度追求完整，又会增加阅读和执行负担。因此我更倾向于先覆盖高频、关键和容易产生分歧的场景，让规则真正帮助团队减少争议，再随着实践补充例外与案例。

我的角色变化

我的职业角色经历了从设计执行、项目主导，到带方向、搭体系和组织协同的变化。问题尺度扩大以后，我仍然需要理解具体页面和视觉细节，因为战略最终必须落到这些选择上；同时也要建立工作节奏、判断节点和责任边界，让团队能够持续推进，而不是依赖一次集中评审。

当前反思

战略必须能转化为具体判断，否则只是难以验证的口号。规范必须拥有维护机制，否则交付完成时就开始过期。体系建设也不是一次性交付，它更像持续运营的基础设施：需要版本、反馈、审计和明确的维护责任。

我现在更关心的，不是产出多少份文档，而是团队面对新问题时，能否更快找到正确的讨论层级，并在保持质量的同时继续演进。