设计师和前端开发，如何实现高效协同的工作流

设计师和前端开发，如何实现高效协同的工作流-经验/观点-UICN用户体验设计平台

设计稿的落实是一个系统性的工程，中间的每一个阶段都不是独立存在的，都包含对前面要素的继承和对后续工作的影响。在此，我要借鉴 DevOps 的模式，来构建一个设计师和前端协同的工作流。

设计和开发有个根本的矛盾，那就是一个是方案，一个是实施。

方案可以各种天马行空发挥想象力，而在实施阶段却要受到各方面的制约和损耗，例如时间、预算、人力、专业程度等。

在部分项目中，方案的权威性不容挑战，实施方要想尽一切方法去实现，并对最终的效果负责。但在多数情况下，实施方的权重更高，方案的实现由实施方决定。所以，100分的方案往往只能得到 5、60分的结果，不管你对结果怎么交涉也很难再有实质性的提升。

很多项目如果本来只有做到60分的水平，那么从一开始奔着100分的水平去设计和交涉，都是在浪费精力和降低项目执行效率，要花费双方更多的时间。所以前期的分析核心的目标，就是搞明白项目需要做到什么程度，可以实现什么标准。

设计的分析点主要包含下面几个：

- 设计权重分析

- 设计工作排期

- 前端资源认识

1.1 设计权重分析

即重点认识项目、尤其是领导上级对设计的重视程度，设计结果在项目中的重要性。

例如一个直播软件，针对礼物打赏这种创收场景，那自然是要把设计做到极致，不仅要让用户看着爽，甚至还要优于竞争对手。而一个内部使用的ERP管理系统，自然不会有多高的设计要求，只要界面能看懂不出错就行（又不是不能用）。

两种完全不同的场景决定了设计实现的上限在哪里，如果在第二种情况下用第一种的要求来完成设计，那么设计的产出注定是要被浪费的，因为场景不兼容。

所以我们必须根据场景来判断设计应该做到哪个程度，而这个程度虽然不能直接量化出等级（每个人的高中低认识是不一致的），但可以通过找到对应的案例作为参照。

同时，项目实际的要求还分成两种，一种是项目真实需要的，另一种是满足“领导要求”的。这在可视化项目中非常普遍，前期对设计稿和实现效果的要求极高，因为立项阶段还要给其他大领导过目或者要竞标胜出，而几个月后相关领导根本不记得前面看过什么方案，所以实现成什么样就是什么样（开发Freestyle）。

这也就意味着，设计是设计的，落地是落地的，两件事是独立的，不需要建立错误的预期。

1.2 设计工作排期

即分析项目中所需设计内容的明细，并评估所需的时间成本并安排时间节点。在工排期分析中，主要要结合三个要素分析，设计工作总量、交付时间节点、设计权重要求。

设计工作总量的分析是非常重要的前期分析，一个有经验的设计师应该在设计工作开展前，就把本次项目所需的工作明细都整理出来，包含要设计多少个页面、整理哪些文档、对接哪些工作和会议。

有了这些明细就可以估算所需的时间范围，之所以是范围，原因就是设计任务的完成度是有弹性的，往浅的做自然很快可以完成，往深的做可能就要多花几倍的时间。所以这就受到前面设计权重的影响，需要项目的设计做到什么水平，必须有个清晰的判断。

同时，交付时间也不是全凭设计师个人决定，而是要紧跟项目的整体排期。所以当分析工作所需时间远超排期时，就肯定要做工作调整，一方面协商减少工作量，另一方面要适当降低工作质量的要求，跟上排期的进度。

之所以提这个，是因为设计还原度的实现是需要投入时间的，如果设计任务本身的工作就把你全部精力占用了，那么在前期就肯定预留不出时间去做和还原度有关的工作。所以建议设计的工作量安排至少预留出20%左右的时间，一方面应对需求的调整和突发情况，另一方面要用于和还原度有关的任务上。

1.3 前端资源认识

搞清楚负责界面样式的前端人数、精力和技术水平。

前面说过前端开发中，样式和逻辑是分开的，如果逻辑部分的工作量大，那么留给样式部分的精力就少，所以需要和相关技术负责人确定，他们有多少人力和精力投入到样式的开发中。

同时前端本身的技术水平认知也很关键，技术水平高的可以完成一些复杂的样式、交互、动效，但一些水平较低的就不行。主要是在移动端和可视化的强视觉项目中，前端的水平决定了还原度的上限，设计师必须跟着前端的水平范围输出，否则前端完全实现不了的设计只能变成飞机稿。

如果前期对技术一无所知，就尽量在一些复杂的设计场景中多和前端沟通，确定设计方案的可行性，随着经验的积累你就慢慢可以知道相关技术的边界在哪里。

以上三个要素的分析，是对全局状况的认识，会对后续实践产生重要的影响，成为很多决策的依据。在一个团队中协作的时间越久，那么完成前期分析的过程也就越短越容易。

共识建立，就是设计师要和前端开发，以及产品、测试等相关成员共同确立设计和落地的要求，对最终的产出结果建立相同的目标和预期。

要建立共识就需要通过会议或者沟通，来解决以下几个议题：

- 设计做到什么程度

- 设计和前端的对接方式

- 资源管理和命名标准

- 开发顺序和检查方式

2.1 设计做到什么程度

前面说过设计要分析设计的权重，还要结合项目的排期做进一步的调整，单这些想法仅仅是你自己的结论，不代表其他人知道并且认可。所以必须要在会上进行沟通，确定本次项目要实现的标准是什么样的。

光靠口述是说不清的，所以需要找到相应的图例或线上案例，来解释要实现的设计水平。复杂的视觉项目还要和开发确定应用的技术类型、设计的边界。之所以还要在会上再提一次，是因为需要在正式的环境中告知，避免只有设计和技术决定了，但是老板、产品并不清楚，认为设计师的方案是在划水。

同时，还要在会上抛出一个关键的问题 —— 前端打算把还原度做到什么程度？

这个一定要问，也一定也要让负责视觉部分的前端自己来回答，因为在这种公开场合下他很难真的说出 “项目时间很赶，视觉随便做做能用就行” 这样的话来。可能会有其它理由说自己的任务很重，留给还样式的时间可能不够，但这种不明确就意味着有商量的空间，需要趁热打铁让他们愿意尽可能配合设计的工作实现更好的还原度。

主要的工作要由设计主导，这个后面会提。但是，如果前端本身任务就不重，那他就没有理由不对还原度负责，所以提前确认像素级的还原度标准是天经地义的。

只要会上给出承诺，后面就有追责和背锅的条件，所以与其留到后面相互扯皮，不如从初期就明确责任的归属。

2.2 设计和前端的对接方式

设计师完成设计评审后要和前端进行对接，交付设计的产出物，既然要交付当然就有交付的方法。在新的项目和团队中，这个交付的方式也要提前确认。主要交付内容包含规范、设计稿、演示、标注、切图等。

在这方面，我的建议是用越少的工具辅助设计的交付越好，因为工具越多，维护的成本就越大，对效率的影响也越大。比如有的项目设计用 Sketch，标注切图用蓝湖，规范文档用飞书，还要用网盘查看演示视频等，只会让项目变得异常的复杂。

所以，我始终建议设计师自己要优化工作流，最理想的做法就是用云端的设计软件如即时、Figma等来实现界面、交互、规范、演示、标注和切图的集合。

如果前端对这些工具不熟悉，就需要提供对应的说明和上手使用的简单培训。部分前端可能会因为路径依赖拒绝使用新工具，指定像素大厨、蓝湖、语雀等，就需要你去总结优缺点来说服他们了。

当然，这个前提是你对为什么这么做有充分的理解，也能给出让人信服的理由。如果你自己都想不明白，无法说服开发，就根据他们的习惯来做，避免让前端有无条件得牺牲自己来适应你的感受，这会让其它的工作变得更难推进。

2.3 资源管理和命名标准

这一步，则是和前端同步项目中的各类文件保存的方法，页面展示的逻辑，以及便于检索流通的各类文件、图层的命名标准。

这和上一步的对接模式紧密关联，一个完整的项目必然包含各类文件和层级关系，比如移动端、WEB端，不同的版本，历史文件，以及在画布中页面的排序方式。需要设计师提前确定好标准，让开发可以在你搭建的体系下轻松的找到指定的文件。

另外，命名也是需要被重点确认的标准，因为这同样涉及到后续协作的效率。命名虽然包含资源管理中的文件夹和文件，但那些只要你结构定好了，命名不乱写都不会出错。主要要关注的是设计文件内画板、切图文件、Token 的命名。

要切记，标准的命名不是网上去找那些写给设计师看的英文切图命名词汇大全，而是得同步开发的命名习惯，因为99%的情况不管你怎么命开发拿到切图的第一件事就是根据自己的习惯重命一遍。所以很多设计师费心费力整出来的命名仅仅是自我感动而已，对实际交付没有任何帮助。

命名的价值是为了后期的检索，随着项目的画布、文件、切图数量膨胀而价值越大，所以项目初期很难感受到命名的价值，但随着项目的推进它能带来的负面影响就越来越大，所以尽量花一点点时间在前期进行标准化，就可以带来成倍的收益。

2.4 开发顺序和检查方式

开发顺序就是前端完成页面样式开发的过程顺序，而检查方式就是如何对每个开发完成的节点进行检查的过程。

想必有经验的同学也能看出这是敏捷的快速迭代并检验的流程思路。但毕竟样式开发只是整个开发流程中的一环，不可能依照完整的敏捷流程，所以必须要要做简化。

我的建议是先把开发的模块全部罗列出来并安排顺序，每个模块作为一个任务（Sprint）并有相关的开发负责人和验收人（设计，ProductOwner）。每个任务都要分配对应的完成标准（Story），即负责人自己说这个模块要实现什么目标以及还原到哪个程度。

这里的任务模块并不是只跟着设计的进度或设计稿的模块来列，而是要包含所有和样式相关的工作内容，比如引入第三方图表库并搭建基础图表模块，实现线上 Fonticon 文件引用，项目基础规范样式创建等等……

每件任务都应该是可以被检验的，所以还要确定检验的方式。前端的开发很多时候是本地编写，想要查看写好的部分就需要他们将完成的代码进行服务器（云端或内网）部署，再提供给你访问网址。当然，也可以用其它的方法实现，如直接发文件给你，搭建公共的虚拟机，或者干脆你到他电脑上看，直接做检查。使用哪种方式不重要，重要的是你能在对应节点对开发的内容做出检查即可。

共识之所以重要，就是要避免设计做设计的，开发做开发的，互不过问，互不干涉，互不担责的孤立状态。

通过建立共同的目标和行事准则，为后续更紧密顺畅的协作和沟通打下基础。

以上四点就是共识建立的过程，需要通过会议的形式来进行交流和确定。

而上面提到的问题只有在团队第一次合作中会耗费比较多的精力，只要走通一次流程，就可以慢慢形成标准化。如对接方式、资源管理、命名规范、任务检查的方式，都是在后续项目迭代中可以沿用的，所以不用担心每次项目迭代都要耗费大量的精力搭建共识。

规范的整理即项目设计相关规范的制定和统一过程，很多人以为它仅仅是设计师自己决定就可以的，实际上它是需要前端深度参与的。

因为规范是整个项目的视觉引擎，所有专业项目的界面都是围绕规范延伸而出的，在设计软件中规范文件就是外部引用的样式文件，而在网页开发中规范就是主要的 CSS 样式文件，其它端也有自己的样式文件。设计规范文件和开发的规范文件内样式数值越一致，还原度的结实现水平越高。

再规范整理阶段，主要要完成的工作，包含下面这些：

- 确认前端框架

- 规范架构治理

- 同步基础样式

3.1 确认前端框架

规范在正式整理之前，是需要先了解前端应用了哪些框架的。

因为大多数项目的前端都不是从零开始写，而是应用了第三方框架的基础上开发，比如网页端用的 AntDesign、Bootstrap，桌面端用的 Electron，可视化项目用的 D3.js。包括一些特定的模块也有相应的开源框架，如图表的 Echart、Highcharts，或者富文本编辑器用的 Editable等等。

只要用了第三方框架，就等于样式上直接受限，因为成熟的第三方框架都会提供一套相对完整的规范和样式，可以做小的改动，但要大改或不受约束的另外开发是不可能的了，这在前文也说过。

但这不代表设计可以躺平了，因为第三方的规范虽然做出了范围限制，但具体的细节要素可没有指定，同时很多规范中不能满足项目实际需求的地方，就要做调整或增加新的内容。所以，设计师一定要熟悉前端涉及到样式的这些框架内容，并基于这个基础完成设计和创建项目专属的规范。

3.2 规范架构治理

这是一个比较复杂的话题，也是很依赖经验的东西，架构并不是只有前端开发独有，随着设计软件功能功能的增长（主要是Figma），对于样式管控的方法就更复杂，更多样化。

其中，比较复杂的就是基于 Design Token 实现的样式管理模式，包括组件切换状态和样式，整套设计文件的主题变更等应用。

Token 的指定虽然看起来和命名规则很类似，但它不仅仅只是命名规则，是需要由开发主导的一种变量管理系统。最常见的应用场景就是用 Token 来管理色彩。

腾讯文档颜色变量表

网上有很多关于如何使用软件色彩样式命名的方式来实现 Token 应用的案例，但随着 Figma 的 Variables 功能的上线，新的应用方式已经改写。同时，Variables 可以实现除了色彩以外的更多属性的更改，从而让 Token 的应用范围在设计软件中进一步扩大（国产软件跟上也势在必行）。

所以，规范架构治理的意思，就是在确定 Token 规则的基础上，把它正确应用在软件规范的实现中，并且这个实现的逻辑能和开发落地的逻辑同步，保证设计和研发的一致。

这需要设计师在制订规范前也有大量的沟通和交流，具体应用方式会在以后的分享中说明，已经有使用经验的同学只要记得这是在规范阶段要沟通并确定的工作之一即可。

3.3 同步基础样式

设计规范中包含的基础样式，有色彩、字体、投影、模糊、遮罩等，还有一些非常基础的标准控件如按钮、滑块、输入框等等。

只要设计师规范给的及时，包含了这些内容，那么样式开发中必然要先搭建这些样式的属性和参数。这些内容的校对要在开发搭建完成之后就进行，也就是前面开发顺序和检查中的其中一个重要节点。

有一定经验的同学可能会有疑问，没有已经实现的页面样式，怎么校对规范的准确性？是这个道理没错，我们不可能直接检查样式的代码，但是开发可以创建样式的应用实例供我们校对。比如看 AntD 等站点时，你会发现设计规范解释中，那些样式、控件都是实现出来的而不是截图。

所以，开发想要呈现基础规范的样式用于检查，只要将这色元素置入到一些空白的页面、背景中，能在客户端进行查看和操作即可，接着就是检查规范的还原度，提交相关的修改 issue，实现两端数值的一致。

以上三步规范的落实，是加快后续效率最关键的一步，因为还原度问题中 80% 的问题都来源于基础规范数值的偏差，而这些问题积累起来要修改就不再只是修改样式参数那么简单（和前端实现逻辑有关），所以到发版前期修改起来又累又慢。

而规范的落实是双向的，一方面我们要保证开发能够在样式应用上和我们保持一致，另一方面，我们在进行后续页面设计中，也要对样式的应用有严格的要求和落实。

设计产出物的交付，是前面共识阶段中需要和前端商议并确定的内容。而在这里，我们要分享设计交付中需要掌握的具体知识和行为习惯。

首先要认识一点，就是设计的交付和前端的交付一样，不应该是一次性的，而是要分节点分批交付。比如前面说的设计规范，就是最早要交付的内容之一。然后，我们再根据前端的排期提前将他们要开发的模块页面交付出去。

这些分批次交付的过程中，需要注意以下的交付事项：

- 标注的交付

- 切图的交付

- 动效的交付

4.1 标注的交付

自从在线设计软件开始普及以后，我是非常不喜欢在设计的交付中使用类 Zeplin 的线上标注工具的。因为用它们是上个时代的妥协产物，凭空多了一套需要维护的系统，并且导入设计后还需要进行二次操作，如备注、画板排列、连线，这都是额外的工作量。

并且，设计文件再初期定稿后还做调整是很普遍的，后续再增删页面，还要同步切图的内容就会产生极大的压力。如果团队还在使用本地设计软件，那么只能继续使用 Zeplin、蓝湖、Coding 等工具。

这里重点要讨论的是如何在云设计软件中输出交付文件，很多团队开发抗拒他们还想使用标注工具的原因，就是因为设计师压根没有做适合查看标注的处理，提交一份乱糟糟的工程源文件的话不会有任何前端喜欢看这样的文件。而标注工具会强制你做这些操作，自然看起来更顺眼。

想要解决这个问题，就要让开发查看的设计源文件中确定标准的、有效的布局形式。

包含侧边栏Page应用，页面排布，连线说明三个要素。

Page 就是软件左上的画布列表，一个项目如果页面多，就一定要用 Page做拆分。而在我们当前的场景中，就可以根据交付的模块阶段划分，每个模块创建一个 Page，这样开发在本次项目中只需要查看这个源文件就可以。

虽然拆分了模块，但是每个模块中包含的页面数量可能也不少，除了不同页面外还包含了不同的状态、事件、弹窗等样式的展示。

所以，我们要做出二次拆分，建议创建 100px 字号以上的文字作为标题，命名和标识这些二级模块。然后再在它的下方罗列相关的页面。

排列页面时，也需要具有一定的逻辑，横向一般表示不同的页面，纵向表示同一个页面的事件和状态。并且横竖间距尽量保持统一，建议左右不低于 800px，上下不低于200px 的间隔，这样即不影响后续添加说明，也不影响前端查看页面时被其它页面干扰。

完成这些操作，可以对一些比较晦涩的跳转和交互做示意，比如用箭头工具直接画连线（角度对象到页面，交互工具实现不了的内容），以及在旁边创建一个画布，专门放相关的说明备注。关于备注，我更建议使用能直接观看到的形式摆放出来，而不是使用评论功能打点，需要鼠标移到上面才看得见。

在前期，这个交付的文件需要单独创建，要从设计工程文件中复制进来排列，但只要完成规范，以及前面一两个模块的整理以后，适应了这些布局就可以直接在这个文件中创建新的 Page 进行设计，加快进度。

4.2 切图的交付

很多人会认为即使标注解决了，还是应该用标注工具，原因是他们可以让开发导出切图。这也是一个非常不合理的操作，因为切图全部让开发自己从页面中导出往往难以检查到切图本身的错误，并且会有切图缺失的问题（类似图标不同的状态）。

我一直建议切图要由设计师自己来完成的观点，即使不由我们完成，也要让前端有更好更直观的导出形式。所以，处理的方法可以在界面画布的侧边，将这个页面相关的切图的元素全部罗列出来。

这里面的每个切图都应该用一个画板包裹，导出切图，就是框选它们后再选择规格即可。一方面导出并不复杂，另一方面这种形式可以帮助设计师检查切图文件，并做出优化和补全。

这里还有个细节，就是切图中尤其是图标，往往是留在项目最后才统一设计。而前期交付中应用的图形可以只是临时的替代品或占位符，只要一开始切图画布规格和命名确定过，那么后期再统一导出，就可以非常轻易的替换之前的内容。

4.3 动效的交付

除了平面的设计标注，动效也是一个需要进行交付的设计内容。正常的动效内容是和所在模块一起提交，如果项目优先级低，也可以留在项目结尾在一起输出后交付。

但是，动效的交付要保证最后能落地，首先自己要有判断做的是什么动效，是交互动效，还是场景动画，以及对动效的开发成本要符合前期分析的项目实际情况。而不是自己做得特别上头，然后开发直接说实现不了，或者要花的时间太多没排期。

在制作复杂动效的过程中，尽量在制作 demo 环节和前端做个简单的沟通，商议实现方案的可行性。很多动效的做法往往可以在这个阶段就得到优化，而不是等到开发阶段再一起愁眉苦脸想怎么实现出来。

同时，交付的过程需要提供非常具体的演示和标注内容，每个动效都要包含下面这些材料：

- 动效演示视频/Gif

- 动效的切图文件

- 动效的标注内容

动效的标注需要非常具体，要有针对象的时间、属性值、缓动效果做出准确的描述。

如果是使用 AE 制作的场景动画，则可以直接使用 Lottie 导出，但是，Lottie 的导出不是万能的，它存在非常多的限制和BUG，需要设计师每次导出后自己用别的软件检查导出文件的有效性。

复杂的动效实现只要标注给清楚还原度就高，落实就容易。真正麻烦的是页面中大量的微动效，比如鼠标悬浮的各种动画、气泡浮层、模态弹窗的动画，所以还想进一步提升开发和还原度水平的话，就是要对动效的内容进行标准化，如动效时间定义、类型统一、缓动统一等等。

具体的内容不在这里展开，可以在 TDesign 官网中查看它们对于动效规范定义的模式，这可以极大的改善项目交互反馈的体验，也可以加快制作和开发的速率。

要有好的还原度就要提供完善的 交付内容，并能依据开发的查看、使用习惯建立工作流。

只要项目进入到样式开发的阶段，就代表设计和前端的协作开始建立并推进设计落地了。这个过程前面说过我们可以借鉴敏捷的方式来完成。

为了确保设计师和前端都能接受这种工作流，在设计流程的时候就一定要注意流程化的要素一定得少，不能让流程解释起来费劲，执行起来也很困难（比如正统敏捷）。

下面分享有关敏捷推进所需的工作，主要包含三个部分：

- 看板的创建

- 每日的“站会”

- 问题的修复

5.1 看板的创建

看板是敏捷最常用的工具，想要在这个过程中推进样式的开发，自然也要用上。而基于精简的原则，这里我要用的看板并不是独立创建的看板，而是结合设计还原度检测 issue 的看板进行合并。

在看板工具中创建待开始、进行中、待检查、修复中、已完成5个步骤，然后开始在待开始内创建相关的任务卡片。

这里要注意任务卡片的创建中，设计的任务和前端的开发任务可以共同添加进去，因为我们要在这个看板中相互查看和跟踪对方的进度。

添加任务时，可以用标签或标题前缀，来区分设计还是开发的任务。这个创建的过程尽量在前面说到的共识建立的沟通会议中进行，并对每个任务内添加实现的目标和水平，以及对应的负责人。

在任务开始进行时，则把卡片移动到进行中状态，做完后移入待检查，任何完成的任务都需要进行检查，设计做完的任务要让前端检查完整性和可行性，而前端做完的则需要让设计进行测试和检查。

检查完成后的任务需要移入到修复状态，等修复完成后再移回检查，等到这项任务已经完成了，再把任务移入完成列表中实现归档。设计的任务要由开发来归档，而开发的任务要由设计来归档。

5.2 每日的“站会”

这里的每日“站会”打上引号，是因为它不需要和正统敏捷一样每天早上在会议室里过个10分钟内的站会（能实现当然最好），可以更灵活的改成别的时间，或者使用线上的方式也行。

要进行一个相关人员都参与的简会，来相互汇报目前工作的进度，以及中间出现的问题，需要其他人确认和帮助的地方。在上文中说过很多需要和开发沟通校对的步骤，都可以留到这个时候进行。因为碎片化的问题没有限制反复打扰其他人并不是解决问题的方式，所以尽量集中到一起解决。

这个站会的时间需要控制在尽可能短的时间内，如果发现每日站会可以交流的东西少，不需要那么频繁的话，也可以改成两天一开。

站会的目的是为了促进沟通，前面反复强调的优秀的还原度需要有效的协作来支持，没有站会来促进团队成员对其他人工作进度和质量的认识，就很难让他们实现更紧密的沟通和协作。

5.3 问题的修复

最后一点，就是关于还原度问题的修复。因为前面我们已经说过，这个看板本身和还原度 issue 提交工具是合并的，所以我们可以直接在这里面提交还原度的问题。

所以，当一个开发任务进入待检查状态时，设计师就可以对已经做好的内容进行检查，并提交相关的 issue了。大多数看板工具都可以添加描述内容或下级任务，要利用它们来提交相关的还原度 issue。

要有心理准备，前面几个模块任务完成以后产生的问题可能就非常多，可以提交的错误也很多。这些任务的修改必然会占用很多精力时间，挤压后续还没完成的工作的时间，前端肯定会非常反感在这个阶段进行样式的修复。

所以这需要设计师和前端做出充分的沟通，并不是直接说服他接受这种“低效”的模式，而是得让他明白这么做是更高效合理的。

原因是因为还原度影响最大的不仅仅是规范部分的实现，还包括前端对样式实现的编写逻辑。相比大家都知道 CSS 中盒模型，可以用于实现元素的排版和定位，一个元素的位置由相关所有元素的盒模型中的参数应用决定，

比如一个标题栏中标题的位置，可以文字基于栏的垂直居中，也可以是栏给内间距，或标题加外间距（内间距也行）。写法多种多样，而出现和原稿不一致的原因就是写法中某些地方出错或者不匹配，而这种错误往往和习惯有关。

越早能检查到这些习惯导致的错误，越可以让前端注意并进行检查和改进。这些调整沉淀下来，就可以在后续的推进中减少同类问题产生，也就会让后续模块中的还原度问题越来越少。

所以，前期的修复是绝对值得投入时间去完善的，因为后面的效率会越来越高，结果也越来越可控，与其把炸弹留到结尾引爆，不如趁早开始排出风险。

当绝大多数任务都完成以后进入正式的测试阶段，那么就可以在这个看板中继续添加BUG修复的卡片，来对结果进行检查并收尾了。

在敏捷的推进过程中，任务的推动是双方共同投入精力协作的，任务的制定、分配、检查、提交、修复、站会都包含了需要交流的部分，所以必然需要通过实践去磨合。

想要建立一套有效的系统，就需要实践，并且反思和改进。所以每当我们完成一次完整的项目以后，就需要找时间和前端开一个总结会议，找出此次项目中存在的问题，并结合大家的意见如何在后面进行改进。

比如开会的时间，任务创建和安排的方式，资源管理的方法，测试版本发布的优化等等。而这些讨论优化的结果，都可以在下一次项目中进行实践，检验它们的有效性。

所有对流程的优化和调整都可以用图文的形式记录下来并形成规范，不仅是用于后期新加入同事的培训，也方便对它进行讨论和修改。

同时，这些流程看似非常繁琐，但面对的项目周期并不是只有一两天的小迭代，而是起码超过一周以上或几个月的项目，这些工作被分散到这个跨度中占比就并不高，而它们能产生的效率也注定远远大于投入的成本。

一定要以发展的眼光看待这套还原度管理的方法和系统工程，不要因为前期的尝试受挫而停止对它的信心和探索。多做总结和反思，你才能在失败中成长并实现目标。

结尾

说实话关于还原度所需要做的工作，还有很多想写的没写进来，忍住了，否则就太长了。这些工作全部执行下来对设计师本身的要求是比较高的，因为如果水平不够，基础知识积累不足和对前端没任何理解，是无法管控中间涉及的细节的。

还有很多同学可能在这个问题上还是会抱怨各种 “团队不在意设计”、“前端永远说没时间”、“设计对项目一点价值也没有” 之类的话。这些抱怨的潜台词就是，你需要团队主动给你空间，主动配合你工作，这是不可能得。重点不是团队给你什么样的设计环境，而是 —— 你想实现什么样的设计环境。

只有团队出现其他各类无法调和的矛盾时，比如需求不确定，发不出工资，内部斗争等，那么设计的落地才会没有着落。

除此之外，专业的设计师应该在能做好自己本职工作的基础上，去发挥影响力，逐步建立和前端的共识，并形成对高水平设计产出的追求。罗马不是一天建成的，但不代表它永远建不成，区别在于你想不想，和有没有能力。

我一直秉持的想法就是，当自己足够专业的时候，环境硬想摆烂，那它们自己摆自己的，影响不了我。但当环境需要我发挥专业性的时候，那我就要具备足够的专业能力和来征服所有对象。

你们想要专业，那就给你专业。

这是一个设计/产品的真正底气。

就写到这里，我们下篇再贱~