我和原型工具的往事
作为一只工龄十年的产品汪，我一直在使用原型设计工具——摹客 ，对于摹客可谓耳熟能详。
初次听说，是产品社群里的点赞安利：做移动端，用摹客。
当时正值2015年，移动端热到不行，每个公司都铆着劲儿开发APP，仿佛落后一步就赶不上下一个时代。一时间，现有的互联网公司从web转向移动，传统品牌每个都想开发自己的app，大搞电商和O2O，还有新入局玩家，敢想敢干，社交新闻，一个不成马上搞下一个，一时间，遍地都是新APP。
与此同时，大量的移动产品经理的市场需求，也随之而来。这些产品进入行业，自然开始挑选起顺手的工具。而摹客比起传统选择Axure，有更贴合本地的优势：更轻便的上手流程，组件丰富繁多，上手程度堪称丝滑。
时间逐格向后，自己经历了不同团队，也经历了更多原型工具的变化。
到过全员sketch的高保真团队。如果需求内审不能拿出漂亮的UE，那你就输了。
也从有过从Axure转向Figma的经历，这次转变造就了职业生涯中画原型最开心的日子。过程中设计先行，建立了UI规范以及庞大的控件库，于是产品的工作被极大简化——画原型变成了拖拽一个个控件，美观和规范成了必然的事情。
而现在，虽然很少再画原型，但也耳闻过Figma关停中国服务的新闻。
此时不禁想起了当年国货之光摹客，思考起这样的一个命题：面向未来，我们会需要怎样的设计工具？
工具的属性
从人类用钻木的方式燃起第一个火苗，就奠定了工具的属性——延伸人的能力。
人之前能做到的事情，工具让人做得更快更好更确定；人之前做不到的事情，工具让人化繁为简，梦想成真。
所以，工具是包括了【提升】和【赋能】两部分的作用。
先聊提升
既然是面向未来，那么就得弄明白未来产品经理会以怎样的方式工作，会在哪些领域工作，工具才能做到又针对性的提升。
就如一位清洁工，清扫街道和清扫家庭，势必会用到不一样的工具，来精准解决不同场景会遇到的不同问题。
未来的关键词1：【卷】
不仅是产品经理，各行各业的卷度或许仍将继续新高。一年千万的毕业生涌入市场，可以用更敢更拼的态度把前浪拍在沙滩上。为了应付这样的卷，我们的工具能否在更快输出UE甚至更快输出prd上做文章呢？
相信每个产品一定都经历过PRD的这些折磨。
-写了好多文字，但是研发不愿意看，被忽略到想吐血。
-UE用工具单独画，每张图贴到prd上，再写备注，一旦有修改，又要双边操作。
-除此之外，还得单独画一张把所有页面串起来的流程图。
为了终结这一切，或许可以创造轻型PRD的概念，让产品经理抛弃文档，输出的原型就是PRD。
它只需要做到两点。
1 以流程串联页面。
新增加原型区域，该区域展示所有已经创建的页面，通过插入可以把页面以整体的形式插入画板中。页面内容不可修改，但可以画线来指引页面间的跳转关系。
2 给每个页面配上易读的文字描述。
点击每个页面，可以查看到在原页面设计时的备注。也可以点击某个具体的元素，来增加备注。
备注可以完全替代需求文档中的文字描述部分。
还可以再进一步，允许用户自定义或者选择prd模版，来补充prd的基础信息。
分享后，大家都可以见到这些信息。
如果不习惯新的查看形式，大可以增加一键下载的能力，把已有的内容分组，生成文档版的PRD。
未来的关键词2：【TO B】
除了更卷，卷的方向也会有所变化。很容易感受到的是，消费互联网红利已经消失殆尽，取而代之的产业互联网，这一风向，又和面向企业设计息息相关。
与之对应的，原型设计工具，准备好为这样的场景做些什么了吗？
有些To B的场景不常见，但是很让产品经理头大。
例如让大屏和仪表盘，因为设计思路和其他模块大相径庭，会让接到需求的产品往十分头痛。
这里头痛的并不是放什么样的内容，而是怎么做出符合大家印象中的大屏或仪表盘。
要完成这样的能力，常规的组件是不足够的，需要的是模版式的载入。模版带有默认的底色，文字色，图片背景色等等，用户拖拽组件进来，自动匹配，产品只需要关注放置哪些内容，而不用再担忧是否“长得像”仪表盘了。
常见的大屏样式
想想看这样的标语：快速设计大屏，用摹客RP，是不是也挺酷的。
还有些常用的能力，使用的过程也可以再进行简化。
例如后台常用的文本输入框，是文本+输入框的组合。下拉单选，是文本+单选按钮的组合。默认给到新的控件组，而不需要用户每次拖动两个组件，将会是一个wow的改进。
再聊赋能
工具型产品的演化路径，往往会从做工具，变成做服务。
通过服务来赋能是更高的维度，把自己从提供者配合者，变成引领者教学者。
举个例子，印象笔记深耕笔记工具领域十来年，早就已经从单纯的笔记工具，转变成知识管理的服务商。在线下场景，提供笔记工具，等实物帮助知识快速向线上迁移，在线上场景，提供模版，组建训练营，构建知识星图。
那么同理，摹客RP也可以成为成为产品经理需求设计的老师。
教的不仅仅是如何画原型，而是如何设计需求。
如果说产品经理有梦魇，面对陌生场景不知如何下手一定是其中一个，下手了也担心自己犯错，需求文档梳理得不全面。
针对这个现象，摹客RP可以如何赋能呢？
首先，我们可以和万千产品经理一起共创，把模版库扩充为案例库，丰富可使用的模版。
案例采用投稿制，投稿需要包含设计过程，以及UE图形和说明。
模版可分为以下三类。
1 页面案例
无论是APP还是WEB，总有一些页面是经常出现的。
比如APP中的【我的】页面，就可以投稿来做针对性的分享。分享这个页面的前世今生：页面在APP里一般会起到什么作用，大概入口在哪里，一般又会放置哪些能力。还可以接着分享：页面常规的布局有哪些，顺带嵌入可以直接使用的布局控件。
对于需要设计这个页面的童鞋，看到这样类似【百度词条】的案例，再下笔时也能胸有成足了。
2 模块案例
对于常规的模块设计，产品经理的难点往往是不了解模块的具体知识，也不太清楚如何设计页面才能匹配模块的目标。
以下图为例，做一个绩效考核的模块，需要先了解绩效考核的背景，知道绩效考核的常规流程，流程中会涉及到的和系统有关的信息，例如哪些人会参与，都会做什么事情，什么事情做，负担什么样的责任产出什么样的信息，以及对应的权限。
作为才接触这个模块的新人，如果能看到这样清晰的，适合于产品设计的信息，再代入去看具体的页面如何设计，也就更加心中有数了。因为页面的呈现只是最后的结果，依葫芦画瓢得，得出来的可能还是葫芦，而不是自己需要的瓢。
3 系统案例
同理，做一个系统的APP，也可以具体的设计过程，再到细节的页面说明。展现从思考到落地的过程，也更加具备可参考性。
另外，页面说明中的内容，是模版上传者的点滴心得，是留给后来者的谆谆教导，一次次页面打开中，知识也就完成了一次次无声的传递。
除了上传模版完成知识传递，我们可以开放案例上的留言能力，完成知识的二次传递。
同一个模块，每天都在被不同的产品反复设计着。留下你踩过的坑，也能成为后来者的宝贵财富。
总结
总结一下，本文从工具的提升和赋能两个部分展开，分别聊了可以拓展的方向。
提升的部分，是轻prd的推动，以及 To B领域深化，都是帮助产品在具体场景中，更高效的完成工作。
赋能的部分，是案例库创建，以及案例库，赋能产品从想清楚开始，再到下笔设计。
工具类SaaS作为国内SaaS的先驱，有着天然的优势。
一套工具，既能服务于个人又服务于企业，服务场景集中，需求也就更加标准。不像行业类和业务类SaaS，受困于不同类型客户的个性化需求，在扩展性上，每迈出一步，改造成本都很大。
但同时，工具类SaaS更多的是把工具放到了云端，还没有把工具转变成服务，真正满足SaaS软件即服务的定义。但相信随着使用和设计工具的人的变化，这一领域也会更多的引入【服务】的概念，更多的作用于【赋能】，届时，工具类SaaS又可以反过来，成为某个产业互联网的重要组成部分，跟着时代的浪潮滚滚向前。
