Flyme Auto 设计认证
项目背景
随着 Flyme Auto 获得了市场的认可，系统开始面向吉利集团各个品牌以及其他的车企品牌合作。
在没有建立认证体系之前，我们主要通过向协作伙伴提供交互稿、设计稿以及搭载了 Flyme Auto 1.0 的桌面台架，供其点检和学习。
当多车型同时推进时，它开始变得越来越低效，也越来越依赖设计师个人经验和临时沟通。
问题与挑战
我找到往期的合作方，从设计师到项目经理，了解在以往合作中遇到的卡点以及希望优化的流程，得出了以下痛点。
审核阶段摩擦巨大
前期缺乏标准，所有问题拖到最终审核集中爆发。内部设计师觉得需要“从头再来”，合作方在完成度 70%–80% 时被要求重做，双方心理成本极高。
设计表现两极分化
保守型团队照搬原有设计，车型亮点无法有效表达。激进型团队过度追求营销包装，忽视系统流程和使用逻辑，破坏体验一致性。
硬件适配与亮点包装缺少方法
新硬件加入时外部团队不知道如何兼容设计；商务部门希望亮点功能有独特包装，但设计团队缺乏明确指引，拿不出既符合系统逻辑又有品牌辨识度的方案。
设计策略
流程和设计资源解决了合作方的基础需求，设计约束要解决更深入的问题。
合作方不知道哪里可以改、能改到什么程度。
于是我们拆开各业务，把这些问题逐项写成表格。将表格内容完善为设计约束指南，指导合作方做个性化设计。
这张表同时服务设计和审核。
合作方用它判断当前方案是否越过边界，送审时附上自查结果；审核团队沿着相同条目复核，并在反馈中说明问题对应的模块、权限和修改对象。
同一条规则贯穿设计、提交、审核和修改，很多意见就有了共同出处。讨论可以继续发生，双方至少先站在同一份问题定义上。
方案落地
指南和约束准备完成后，我继续参与前期宣讲、日常答疑和审核反馈。
在设计开始前，我们向合作方说明系统原则、提交方式、可调整范围和重点风险。这个阶段越清楚，后面用于修正方向的时间越少。
进入设计后，新的车型和硬件会带来文档没有覆盖的问题。我会先判断它属于既有约束、有限适配还是新的例外，再协调对应专业给出结论。能够复用的判断继续补回文档，让下一次合作不必从头讨论。
审核反馈也不只写通过或不通过。我们会说明问题来自哪条规则，为什么影响体验，以及建议朝什么方向调整。合作方可以理解修改依据，设计团队也能减少观点式沟通。
通过这样的循环，认证文档逐渐从一次性交付物变成业务持续使用的基础设施。
这是我第一次作为组织者完整推动一件事。感谢过程中每一位同事的支持。
这个项目让我第一次从单个业务里抽身，站到全局去看设计的价值：哪些问题值得解决，哪些可以妥协；系统的底线在哪里，边界在哪里。
认证文档从一次性交付物变成了业务持续使用的基础设施。它覆盖 40+ 车型的接入场景，让送审与审核共享同一套判断依据，把过去依赖个人经验和临时沟通的协作方式，固化为可执行、可复用的机制。
偶尔朋友们会转发一些新的品牌、车型用了 Flyme Auto，我也很开心。
