2023年【摹客RP测评大赛优秀作品】协作设计风云际会蓝湖摹客谁与争锋

【摹客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，然后在选择其他电子产品的时候，都会在先去联想苹果生态有没有对应的产品。

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

摹客，是致力于搭建这种“生态圈”的。一旦用户接触了摹客，就会发觉团队协作的最优解，就可以通过摹客供应的各种工具去实现