#本文为2022摹客RP原型工具测评大赛三等奖作品

在项目进行过程中，产品、设计、研发、测试是项目的核心角色，但却很少能够做到信息同步，高效协作。对此，选择一个良好的协作平台能够助力他们高效协作，推进项目落地。本文就当前原型协作设计市场中的蓝湖和摹客作为分析对象，以此明确协作设计领域的关键。

我雇的明明是两只手，怎么却来了一个人。

亨利·福特的这句经典的话道出了企业演进的终局。在极致内卷的当下，企业的效率革命将是更多企业作为活下去与建立壁垒的重要手段。

最近，华为任正非内部讲话的寒气，不知道让多少打工人感到瑟瑟发抖。全国的市场，其实早就感受到了凛冬将至。今年大厂、中厂降本增效的新闻一直不绝于耳。而作为身处漩涡之中的一名产品设计者，从团队整体效率的视角出发，深感部门内耗造成的时间与成本上的浪费有多严重。

产品、设计、研发、测试等角色作为项目中的关键节点，很少能做到信息同步，高效协同。而作为单兵个体，每个角色又因为工作习惯的不同，常常要付出额外的学习成本去理解其他角色的产出物。在项目目标与最终成果上，经常出现偏差。产品经理、设计、研发之间因为协同效果差造出的段子，已经足够养活一个脱口秀演员了。

市场中一直在涌现解决以上问题的解决方案，在这些解决方案中，通常会把主要用户群体聚焦到设计师或产品经理。比如摹客、蓝湖。

摹客对于协作设计工具的理解是通过打通产品经理、UI设计师日常协作场景，形成协作闭环。除了提供常规的原型设计工具、UI设计工具，还增加了UI设计规范模块，为原型设计与技术执行赋能，提升协作效率。

蓝湖对于协作设计工具的理解是偏向于设计团队的，对于产品经理的工具搭建能力较弱（后面会专门针对相关模块进行对比）。导致蓝湖在应用时，基本是设计团队专门使用的工具产品。只有在设计内容交付时，才会涉及到和产品经理、研发、测试的交互，并没有很好的做到全流程协作。今年蓝湖推出的MasterGo更是专门面向UI和UX同时设计交付的产品。

至于摹客和蓝湖在用户工作中是如何组织的，我们就通过用户在摹客和蓝湖上工作流程的拆解，横向对比一下吧。

一、启动项目/归档项目

一个项目从规划敲定再到启动，其实是有一套比较科学且规范的项目管理的。

首先，一个需要团队协同的项目，需要从一开始就清晰的记录项目的相关背景知识。这个将作为解释项目的源起，也是达成团队共识的利器。通常这种内容将以各种文字、表格、图片等内容形式去呈现。然后团队成员基于项目背景知识的理解，产出各自的内容交付。

产品经理会产出相关需求文档与原型图。UI和UE会产出设计稿，测试会交付测试用例，技术会交付代码。不过基于当前协作设计产品的定义，基本都是停留在产品经理与设计师两个团队更显性，更易传播的内容的建设。不同公司对于项目知识的解构与协作不同，就会选择不同的工具产品去组织业务。此时，则考验不同协作设计工具，对于业务流程最优解的理解了。

摹客平台在启动项目时，会将不同载体的内容分类来组织项目知识。文档作为轻量级的项目内容描述，更适合背景、目标、价值、用户故事、其他项目知识等文字内容的描述。原型稿与设计稿分别针对原型文件与设计文件进行专业化的内容呈现。通过固定化的分类方式，引导项目团队成员根据固定的文档组织方式进行项目知识存储。甚至在中大型项目中，在整个项目周期内沉淀出的资源、规范、动态和工作任务仍可在项目中进行协作。

在项目交付后，项目知识往往可以得到很清晰与完整的保留。

作为生产力工具，摹客RP、摹客DT是和摹客CC打通的，在摹客CC中创建好项目时，即可发布到项目中，保障项目从创建到执行都可以线上协同。

而蓝湖在创建项目时，同样是创建出产品与设计的模块，不过在模块设计中，更偏向于项目团队成员在其他工具中设计完成后，在蓝湖的项目中进行归档。

蓝湖中也嵌入了MasterGo这个设计工具的引导，不过也只是引导而已，两个工具的团队没有打通，导致用户从蓝湖跳转到MasterGo之后，并没有将内容回流至蓝湖，导致内容断层。

二、产品经理产出需求

产品经理作为项目的灵魂，通常也是项目组织中的关键节点。围绕产品需求产出的设计图与最终代码交付产生的线上产品，都是以原型图作为起点，进行项目串联的。作为中间点，在团队协作时，理应让原型图可以快速验证。需求中的隐患越早暴露，影响越小。

摹客专门为产品经理搭建了一个原型产出工具摹客rp，通过解构产品经理输出原型的流程与痛点，既提供了常用的组件工具与基本的交互设计，还打通了设计资源，让设计师与产品经理在需求设计时即产生协作，在提升原型产出效率的同时，保障了设计规范上下共识。

同时，针对使用Axure的产品同学，仍然提供了项目上传与管理的方法。

摹客对于产品经理的原型模板也做了重点支持，提供部分大厂的原型设计方案，帮助产品经理快速产出原型需求。

而对于产品经理的生产力工具的支撑，蓝湖并没有进行重点建设，只是提供了产品文档上传。这种设计思路大大降低了产品经理对于蓝湖生态的粘性，无法完全保证项目完全在蓝湖生态下运行。

三、UI、UE产出设计稿

目前国内设计团队使用的软件大部分还是依赖国外的UI设计软件，但UI设计软件是一个难度相对较低，壁垒不高的领域。设计师并不是一定要依赖国外的软件的。今年figma断供大疆，更是加速了国内设计师拥抱国产软件的节奏，当前的UI设计领域当真是风云际会，今年上半年UI设计软件更是迎来了一波流量高潮。其中摹客dt就是其中比较有代表性的产品，这里不讨论运营向的动作，只聚焦一些产品设计方向进行产品力思考。

摹客针对UI、UE团队设计了摹客dt这款工具，支持通过一款工具解决设计图与交互的完成。从设计工具的角度分析，中规中矩，基于摹客团队生态生长，基本满足了设计师的日常内容产出需求。

在设计图产出后，通过打开设计稿，设计师、产品经理、研发可以围绕项目面板上的设计图进行评论、定稿协同、矢量图标注与生成代码。不过这种工作流程的设计思路有个弊端，就是项目团队要制定机制，保证团队成员通过打开设计稿进行信息标记，同时信息可以及时反馈给设计师。当然，这里摹客提供了打通微信提醒的机制，但是这种机制仍然是后置的，需要团队流程进行管控的。并没有通过产品力形成团队自组织。

四、需求评审

在需求评审时，一个能把需求描述清楚的线上内容载体至关重要，这个内容载体既要描述清楚需求的背景知识，还要描述清楚需求中研发需要做哪些工作，让研发可以进行工作量评估。同时还要让测试可以根据内容评估出测试用例。最终这个内容载体最好支持实时协同，一个高效的需求评审会，会后就要即时形成结论性的成果，即需求文档里面有异议的地方应都有对应的结论与解决办法。会后技术和测试就可以开工执行了。

在摹客的项目中，需求将围绕CC中的项目文件进行评审。产品经理首先可以通过文档模块传递项目的基本背景，随后即可针对原型稿进行具体的原型流程阐述。

不过这里有个细节其实可以拿出来思考一下，就是关于查看详情模式与演示环节在项目流程中的作用。从目前摹客设计的流程来看，用户需要先进入查看详情模式，这里可以完成评论、定稿、开发标注等动作。这里的产品框架沿袭自摹客设计稿协作思路。不过通常原型稿不是实际的设计稿，在这里有这样一个环节其实很容易让人错愕。

此时，产品经理如果想要针对原型稿进行原型稿的讲解，需要点击演示才能进行（因为产品经理的备注信息是在演示时才能展现出来的）。这样就导致需求评审在这个环节加入了原型细节评论与原型整体呈现的二元割裂场景。无法让产品经理判断出要通过哪种方式组织需求评审的协作更加合适。

从我个人的角度可以发散个思路，就是把查看详情的流程和演示的环节合二为一，让需求评审的环节真正发挥原型讲解与实时评论交互的操作。提升团队协作效率的同时，也减少用户在宣讲需求时关于系统流程的冗余思考，缩短决策路径。

查看详情模式：

演示环节：

五、一个细节

关于摹客这款产品，有个产品体验的细节还是想要单独讨论一下的。作为一个小白去第一次接触摹客，实际上会发现这个细节刚开始感觉很奇怪，仔细一思考就理解了为什么这么设计。但是在理解过程中，就已经付出了学习成本，这些学习成本最终会反作用于产品增长。

场景是在项目创建多终端样式的页面时，会让项目类型与实际项目中的页面不符。这个体验会导致用户理解成本升高，此时用户内心会感受到不安，因为无法预期项目能否顺利演示。

当点击确定时，发现页面样式与底部的项目类型不匹配，此时不安的情绪高涨，想要赶紧预览一下，看到底是什么情况；

当预览发现图真的和内容不匹配之后，内心直接崩溃了。用户面临的要么是弃用，要么是继续探索（还会面临几次精神崩溃），终于发现要按照终端规则进行项目创建。

这里还有一个细节比较反人性。当项目初始值设置为网页项目时，在切换页面为手机项目时，默认是横屏。根据手机的硬件的设计原则，是鼓励用户竖屏使用手机的，这个原则迁移到移动端的项目中后，竖屏的设计就是是占大多数的。即使平台希望用户一直沿用横屏的体验，其实也应该考虑到，在这里创建移动端的项目究竟是为什么。这块的细节实在是不应该漏掉这种设计认知。

这个模块违反的设计原则是设计中重要的原则之一，所见即所得。当我们进行一项设计时，很自然的会根据我们的既有惯性去进行使用，摹客提供的画板想要规范化每个项目的画板，节省用户操作的思考，这个思路很好，既可以让用户专注终端设计，又在项目结束时，可以自动的归档每个终端迭代的内容。

不过每个公司对于项目的组织形式是不同的。有的公司是以终端进行划分的项目，比如做APP的一直做APP，而有些小公司的项目是综合性的，一个项目往往要多终端，前后台进行配合，当一次迭代在同一个项目中建立时，往往可以对项目描述的更加立体，更便于执行，且后续在归档时，往往会以迭代的里程碑进行归档，终端只是里程碑中项目范围的描述。

在当前阶段，小公司和小团体其实是摹客不可忽视的一股力量。这种多终端融合的项目执行在摹客上创建过程并不是很流畅，往往需要付出几次调整后，才能慢慢的掌握使用方法。这也是为什么小公司还有很多仍然继续使用Axure，因为Axure更加兼容并包，对项目的组织更加灵活，在设计中与设计完成后都遵循所见即所得的原则。

结语

通过以上的对比，摹客和蓝湖体现了两种协作设计平台的设计方向，一个是平衡各角色在系统中的参与，从而让各角色都通过系统中的工具实现无缝协作；另一种是打通单点，通过一个工具能力的突破，带动其他角色参与到平台上。

两种方向哪种更优我先不说我认为的答案，我们可以先进行一个思考。

我们在抱怨PS太难协作，交付的设计稿到开发的过程中拉扯低效，本质的原因是什么？

我们还会抱怨axure操作繁琐，制作高保真原型时间长，最后评审的时候，频繁修改导致版本控制困难等，本质的原因是什么？

这些问题真的只需要在工具中加上协作方案就解决了么？只能说解决了一部分问题，设计师和产品经理的工作效率提升了。但是在团队协作过程中，我们从项目发起到项目实施，最后到项目收尾，整体流程产品、设计、研发、测试等角色的整体协作流程还是会因为自己使用的工具不同，沟通仍然需要需要借助通信软件进行项目实施的“最后一公里”。在项目完成后，项目产生的内容仍然是散落在不同地方。我们最后在组织过程资产的整理时，很容易遗漏关键知识，导致知识传承断档，影响关键产品决策。

在产品设计工作中，我们会发现，不同角色的核心价值，通常都不是使用工具的熟练能力带来的。比如产品经理，对用户、对需求的洞察力的判断，是衡量一个产品经理是否专业很重要的维度。反而在实施阶段的原型设计，只能算作产品经理的一个基本功，做的再出彩也只是个人的特性，不会作为产品经理能力的体现。比如设计师，对设计方向的把控是其核心的产出，设计工具的运用也只是为了更快的实现其设计的思想。

团队之所以被称作团队，是企业寄希望个体协作的力量要大于每个单体产出的内容，团队协作最好能通过某种连接组成一个整体，而这种连接，我愿称之为“生态圈”。就像我因为买了一台iPhone，当我需要一个无线耳机的时候，我第一选择往往是AirPods，然后在选择其他电子产品的时候，都会在先去联想苹果生态有没有对应的产品。

产品设计的“生态圈”就是类似这样的感觉，每个人都期望在这个圈子里享受到触手可得、快速响应的工作节奏。这种“生态圈”的建立，才是协作设计工具领域的终局。每一个工具纵深能力的探索，都只是创造了一个用户选择而已，并不是给用户一个成熟的解决方案。比如我们选手机，大多数人不会因为moto razr手机真的很帅去选择摩托罗拉的手机。反而是鸿蒙生态给了人们生活中各项需求协同的解决方案，让人欲罢不能，大多数人最终会选择购买华为手机。

摹客，是致力于搭建这种“生态圈”的。一旦用户接触了摹客，就会发现团队协作的最优解，就可以通过摹客提供的各种工具去实现。这种自然生长出的用户使用，是产品力的最佳体现。当然“生态圈”的搭建仍然任重而道远，除了本文着重分析的产品力，还要有跟更多运营导向的设计介入其中，不过产品力始终是产品能否支撑起用户体量的根本。

协作设计领域因为工具的低壁垒性，抢占用户将是未来的第一要务。在更远的未来，出需求，设计图，写用例，垒代码这四个互联网领域每天都在发生的行为终将走向自动化的方向。而到了彼时，站立舟头的，又是哪位船客呢？

本文为2022摹客RP原型工具测评大赛的测评文章，如对摹客RP感兴趣可点击体验链接：https://www.mockplus.cn/rp-event/?hmsr=woshipmsonghengda