My Secret Rainbow

#14 从 Figma 视角看设计协同 – Config 2023（下）

篇首语

在上期的文章里我们基于标准化需求和个性化需求两类不同的设计需求，来分析了 AI 设计在界面设计领域中的现状以及未来发展的一些可能性。虽然目前还不太成熟，但它们是未来发展的趋势，作为设计师，我们需要保持足够的关注和一定的参与度。

当然，在现实的工作场景中，我们始终会有一部分的设计需求是 AI 无法完成的，需要人来深入参与。就像 Figma 的 CEO 在 Config 2023 开场演讲中提到的：

AI 可以帮助任何人获得一个好的初稿，但好的初稿不是一个世界级产品，从初稿到世界级产品的过程中需要设计师和设计团队的参与。

如果输出质量无法达到对设计（不同层级设计需求）的要求，那么 AI 于设计师来说只能充当一个辅助工具的角色。我们的关注点还是需要回到对设计过程中，以及设计协同的环节中来，看看如何通过对协同能力来提升业务生产的效率。

被价值低估的设计协同

在阿里的最后四年，我一直都在做设计协同类的产品。虽然它只是一个内部产品，但在其能力辐射的范围上我们还是做得非常广的。所以对于 Figma 今年大会上提出的能力和思考，我还是非常有感触的。

如今我们聊设计协同，其实它早已不是简单地在设计师之间共享文件、组件等设计资源，而是更多的成为业务生产流中的一个重要环节，衔接前期的产品需求规划以及后期的研发实现。想要真正把设计协同这件事情给搞明白，我们就得将它掰开来仔细的分析和思考一下。

设计协同最重要的三个组成部分

设计协同其实是一个被严重低估的领域，在国内无论是同类的产品还是日常的工作中它都很难获得公司的重视。也只有真正参与在其中的相关人员才会理解它于公司的业务生产而言是多么的重要。

首先，它不仅关乎用户对于我们产品的感知和体验，更是连接商业、产品和技术之间的桥梁，也是各个业务元素有机地融合在一起并且提供可视化的环节。所有针对最终交付产品的信息和意见都会在这里交换、讨论。

其次，它还承担着一家公司及其产品的资产管理与分发的工作。比如面向产品研发的设计稿、素材、组件库；面向运营的品牌物料、素材等。通过建立统一的资产库和管理流程来提供更有效清晰的分发流程，提升团队整体工作效率和设计的一致性。

最后，通过它所完成的设计交付还影响着后续研发的整体效率。这里的交付物不仅仅是设计稿，还包含详细的规范文档、交互原型以及研发过程中所需要的各类设计物料。好的设计交付物能够有效地减少沟通中出现的资源浪费，提高研发效率，同时确保最终上线的产品符合设计要求并为用户提供优秀的用户体验。

从过往这几年的经验来看，我认为在设计协同领域中有三个非常重要的组成部分：多角色协同、资产管理及分发、设计交付，它们一起共同构成了一个高效、协调的设计协同生态系统。

 

设计工作中的三个阶段

在产品设计的工作中每个公司都有着自己的工作流程，但实其实大家大体上都差不太多。总体上我们可以将它们分为三个阶段：前期的概念设计 → 中期的方案设计 → 后期的交付跟进。

01. 概念设计

在产品需求构建的初期，需要设计师辅助产品及运营人员进行一些需求的概念设计。这个阶段强调的是产品、设计、用研、市场等角色之间的协作，能够让大家基于一些可视化的概念设计进行需求的讨论和迭代。

02. 方案设计

在需求确认之后，将交由设计师完成设计实现。这个阶段会更强调产品、设计之间的协作，同时也有一些研发会参与进来。通过反复的迭代和评审来确保设计方案能够有效的达成商业目标，同时为用户提供良好的使用体验。

03. 交付跟进

当设计方案确认之后，将由研发团队接受需求进行产品的开发。这个阶段的重点是设计与研发之间的协作。设计师需要给出符合开发流程的交付物，来帮助研发团队更好的理解业务逻辑和设计逻辑，提升研发效率。

如果产品设计研发还是传统的瀑布式，那么大家对协同的需求是比较轻的。但随着互利网行业的不断发展，敏捷的设计研发模式变得尤为重要，这也就对多角色之间的协同提出了更多的要求。需要各个角色紧密合作，快速响应需求变化和迭代，协同的复杂度也因此大大增加。比如：

•设计师会更多地参与到前期的需求概念设计中，为产品经理和市场团队提供一些前期的设计辅助；

•方案设计阶段产品经理和研发则会参与进来共同讨论和评审设计方案，设计师根据大家的反馈进行方案的调整；

•而在最终的研发环节中，设计师则需要提供清晰的设计规则和交付物，解答他们在实现设计方案过程中遇到的问题，确保设计方案能够被研发团队准确的理解和实现。

这也就意味着各个角色之间的活动范围和协作频率都会大幅的增加，更多更频繁的协作和合作是设计协同领域发展的趋势。而在这些环节中所有会影响“流通效率”的问题，就是我们在设计协同领域需要关注并解决的问题。

 

三个阶段中面临的问题

概念设计阶段

概念设计阶段是一个需求的开始，设计师会基于前期的业务讨论和需求框架来进行一些概念设计，这里可能会包含一些用户故事板、概念草图以及一些竞品分析等内容，方便所有的项目参与者能够更全面的了解业务需求、用户痛点。

这些概念设计有助于大家在项目初期阶段能形成一定的共识，明确产品的定位和目标，同时也为后续的方案设计奠定基础。

在这个阶段中，参与的角色是最多的。设计师不仅需要将对需求的讨论和思考有效的呈现出来，同时还需要做好协调和沟通的工作，确保大家都能有效的参与进来给有有效的支持。这里有几个方面尤其需要协同工具的支持：

01. 一个所有人可以一起讨论的地方

每个职能角色的交付物是不一样的，产品经理和市场输出的是文档、用户研究人员输出是 PPT、而设计师输出的则是图形文档。一直以来我们都缺少一个能够将不同职能角色能够串联起来并且能够共同工作的地方，这最终也导致了我们在工作中信息的碎片化和协同效率的降低。

为了能够更好的协同，我们需要的是：

•没有专业软件的限制，能够让所有角色都可以很容易的触达并轻松使用；

•能够支持不同累心的文件格式，并且能够轻松的相互引入使用；

•能够针对不同类型的信息进行注释和反馈，方便团队成员进行讨论；

•能够对大家的讨论内容进行汇总、输出，形成最终设计过程中的决策和指导。

02. 简易快速的概念设计

既然是概念设计，那么它最关注并不是精度，而是能够让设计者（不仅仅是设计师）能够快速准确地表达出商业逻辑和设计意图。方便大家能够快速的进行讨论、决策以及迭代，提升在项目前期的脑暴、概念设计的效率。

为了能够更好的协同，我们需要的是：

•方便快速的原型绘制（或导入）能力，让设计者能够快速的表达业务需求和设计概念，帮助项目成员更好的表达设计想法；

•触手可及的资产物料，集成日常业务过程中常用的设计物料，方便设计者能够快速找到相应的内容，加快概念设计的制作速度。

方案设计阶段

在完成前期的概念设计，产品经理交付需求 PRD 文档后，接下来将由设计师接手开始需求的设计实现。根据需求文档进行产品的创意构思和设计，然后与其他团队成员进行沟通和评审，不断迭代优化设计，确保最终设计方案能够满足产品的业务目标和用户需求。

方案设计阶段是设计师工作量最多的一段，也是最复杂的一段。除了自己埋头干活，设计师依旧需要与多个职能角色合作，包括产品经理、研发团队以及其他的设计师。在协同的能力方面，我们需要考虑以下几个方面：

01. 设计实现的效率和一致性

在具体的设计工作中，我们非常依赖各类设计规范和资产。可是很多团队里这些内容都分散在同的文档、设计稿甚至是口头传递中，并且版本混乱、更新滞后。

这些普遍存在的问题导致了设计方案产出的不一致性，影响产品整体质量和用户体验的同时也大幅增加了研发环节的开发成本和质量问题，最终造成设计、研发、测试等环节资源的浪费。

为了能够更好的协同，我们需要的是：

•中心化的管理能力。能够让设计团队在同一个地方集中存储和管理所有的设计物料，包含设计规范、组件库、图标、素材以及文案等内容。同时它还应该支持版本版本管理，让团队成员可以随时回溯到前面的设计版本，避免多人协同导致的冲突；

•统一的推送更新能力。通过中心化管理、统一分发的模式让团队所有成员可以实时获取到最新的设计物料，避免因为过久的资产导致输出设计方案的不一致；

•设计稿自动检查能力。通过设计稿检查工具帮助设计师检查设计稿是否符合设计规范和标准，识别错误或不一致的地方，避免后续开发过程中不必要的问题出现。

02. 快速有效的评审能力

设计评审是整个产品研发环节中非常重要的一环，它即是对设计目的的把关，也是对后续研发效率的一个重要保障。产品经理和业务方需要确定设计方案是否满足业务诉求；设计 Leader 需要把控设计方案的质量；研发团队则需要明确设计方案的可实现性。

设计评审也是日常工作中设计师最为痛苦的环节之一，面临着各种调整和困扰。评审会议通常都非常冗长，经常聊着聊着就跑题，偏离会议的核心目的，让参与者陷入无休止的讨论。

为了能够更好的协同，我们需要的是：

•辅助建立评审机制。协助发起者制定评审会议的目标和评审任务，让参会人员在评审开始之前就能清楚了解会议的目的以及自己需要关注的内容，在会议上能够更加集中地关注和提出与目标和任务相关的问题和建议，确保评审的准确性和效率；

•评审过程的记录和汇总。协助发起者快速有效的记录评审会议中的讨论和决策，并进行有汇总整理，便于项目成员回顾和查阅，同时也为后续的设计决策和迭代提供参考和依据；

•对评审结果进行记录和存档。通过记录和存档评审结果，帮助团队建立起清晰的决策日志，确保责任的清晰和透明，同时也有助于避免后期出现责任推诿或纠纷的情况。

03. 设计需求进度管理

设计项目进度管理一直是产品研发环节中比较混乱的一环。首先，设计师可能会同时负责多个项目，面临来自不同项目的任务交付要求；同时，设计 leader也面临着资源分配的难题，不清楚如何合理地安排设计师的工作，以确保设计需求都能够按时交付。

另外，对于相关的产品和研发团队来说设计的进展通常都不够透明，导致他们无法准确了解项目的实际进展，只好整天跟在设计师后面催进度，他们烦设计师也很烦。

设计领域的需求管理的确与传统的业务或研发需求管理有着很大的差异，同时也因为设计过程涉及到更多细分的环节和阶段，传统的需求管理产品是难以完全覆盖的。

为解决这些问题，设计协同产品需要具备以下这些能力和特性：

•中心化的需求管理平台。帮助设计师管理设计过程中的状态和设计产物，便于其他项目相关成员了解设计的进展；

•全局化的设计资源调度。便于设计 Leader 更好的规划和分配设计资源，确保设计资源的合理利用和高效调度；

•需求关联与跟踪。将设计需求与业务需求和研发需求进行关联，便于公司全局的进度管理和交付物的实时同步。

交付跟进阶段：

设计方案评审完成后，就将交由研发团队进行后续的开发工作。不过将设计稿交付给研发团队并不代表设计师的工作已结束，这个阶段依旧高度依赖设计和研发之间的协作。通过做好设计交付来辅助研发团队理解业务逻辑和设计逻辑，提升研发的效率。

为了确保设计方案能够清晰、准确地被研发团队理解，设计师需要考虑如何做好交付物的准备，这里一般会包含设计稿、设计文档、资产物料、组件库等内容。在协同的能力方面，我们需要考虑以下几个方面：

01. 设计交付物或资产分散不集中

针对一个特定的项目或需求，设计师可能会创建多个设计稿、素材、原型等资产，但这些资产可能分散在不同的项目或文件夹中。这就导致研发团队在开发的过程中需要大量的时间去寻找或询问。

02. 设计稿状态及变更历史不清晰

在项目的进行过程中，设计稿发生修改是非常常见的情况，但这对于研发团队来说这些变更历史以及哪一个才是最终确认的版本却完全的不清晰，这也是研发团队最痛苦的状况之一，最终也导致大量的资源浪费和各种扯皮的事情发生。

03. 缺少开发者模式视图

研发和设计师两种不同的思维模式，设计协同工具中会更倾向于设计师的习惯来提供视图以及相关的参数信息。这种视图研发团队虽然也能用，但缺少对研发人员体验友好度的关注，会造成很多细碎的操作成本浪费。

为解决这些问题，设计协同产品需要具备以下这些能力和特性：

•基于需求的交付物聚合。引导设计师有效的完成设计交付物的聚合，做到设计交付的齐套，尽可能降低研发团队在找文档上的时间浪费；

•基于需求的设计稿版本管理。为设计稿提供标注的能力，避免因版本混淆而导致的问题，同时记录设计稿变更历史，帮助团队追溯设计稿的演进过程，了解每一次变更的原因和影响，从而更好地理解设计师的意图和决策；

•设计交付物的开发者模式。为研发团队提供开发者视图，便于开发人员在开发过程中获取设计标注、组件库关联、交互效果等信息，提升项目研发的效率。

到这里，我们会发现虽然在很多团队里没有「设计需求」这个概念，都是直接从业务需求发起到研发需求，中间的设计环节被忽略掉了，但实际上设计需求这个环节里一点都不简单。

设计协同领域是一个涉及多个相关角色的复杂领域，包括设计师、产品经理、开发人员以及市场、运营等。但正如前面所提及的，设计是唯一一个可以将所有的业务需求、想法、方案可视化的地方，所以设计协同才会如此的重要。

按照这个逻辑，我们再来看看 Figma 在这次大会上发布的新功能，更强大的设计变量、高级原型能力，更贴近研发环节的开发者模式以及三方需求管理的对接（例如 Jira），以及过往已上线的资产管理、白板等能力。为什么 Figma 会投入资源做这些功能，这些就都不难理解了。

回到这一次的 Config 大会，通过这些功能的发布我们不难看出 Figma 以及其背后的 Adobe 的一些思考和想法：

01. 保持设计协同领域的核心竞争力

既然 AI 在产品的界面设计方面还无法替代设计师，那么设计协同的能力在当今互联网产品研发中依旧非常重要。Figma 显然是意识到了这一点，所以希望通过对设计协同领域的不断深入研究和创新，保持自己在设计交付上下游协同领域的核心竞争力。

02. 吸引更多用户，提升盈利能力

虽然 Figma 的数据增长一直不错，在设计协同领域也处于霸主地位，但它当前依旧是亏损的。Adobe 为了“防守”花 200 亿美金收购了 Figma ，但它终归是需要盈利。设计师上下游的合作者是一片巨大的金矿，这次发布的开发者模式如果被大家所认可，将会给 Figma 带来一大波新的付费用户。

关于这次发布的新功能网络上已经有非常多的介绍，这里就不再重复了。当然，我还是建议大家自己去看看原视频感受一下。B 站已经有中文字幕的版本，大家可以点击了解查看。

Take away

日常也有不少同学问到设计协同的问题，也想着在自己团队中通过对流程或工具上的优化来提升大家的工作效率。这里有一些小的 Tips 可以分享给大家：

1.识别问题，远比倒腾工具有效。有些时候我们会因为某一款新工具（或个功能）而产生想要优化流程的想法。但这些想法往往只是因为对新功能的兴奋，而忽略了团队中真实存在的问题。所以，不要急着看到一个好东西就往里扎。先好好思考一下团队中需要解决的问题是什么。

2.工具不一定要自己造，选择一个合适的工具先开始。我们经常会陷入到个性化需求的“陷阱”中，总想着针对性的为自己争取资源定制开发。这样往往会陷入大量的时间和资源的消耗，而且未必能达到预期的效果，最终可能还让公司产生负面的看法。所以，不妨先挑选一个合适的工具先进行尝试，等到摸索出一定的思路并验证后再考虑自己研发。

3.与上下游达成一致，不要自嗨。协同不仅仅局限在团队内，更重要的还有上下游的相关人员。在探索协同效率的时候一定不要沉浸在自己的领域中，将思路和想法与上下游进行同步，共同改进协作流程。相信我，没有上下游的支持，自己搞设计协同是玩不转的。

4.不要盲目改进，给自己制定一个目标。协同的目的是为了提升效率，这就意味着我们需要有一个明确的可衡量的目标，否则我们很容易陷入盲目的改进和迷失方向。一定要先给这件事情定义一个清晰且有意义的目标，通过设定目标来持续监测改进的效果，并根据实际的情况进行调整和优化。

设计协同是一个很大的话题，我们今天的文章也只是粗略的聊了一些大的方向和目标。设计协同也是一个非常值得深挖的领域，需要在不断的实践中总结经验。非常欢迎大家来分享一些自己日常工作中的经验和教训，来帮助大家共同学习、进步。如果不想公开分享，而言欢迎私信我单独聊聊。