SaaS产品设计办法论

wangziang

编纂导语：关于产品经理而言，产品在疾速落地前，需求切实理解履行产品面前的念头及目的，这样能够防止用户体验感欠安。本文将分为下列六方面对SaaS产品设计进行讨论交流，值得浏览学习。


有这样一个场景：
老板/用户：我有?个特别棒的设法，优先级很高，你赶快把计划产做出来。
产品经理：包管效力！我马上就开始画原型，而后外部评审，接着推动开发。
这时候候部份产品经理急于表示，需求将需要疾速落地，第?反映就是开始履行，所以常常会产生?种状况，产品经理很致力的去做，把需要或设法百分百的去复原，但后果老板或用户体验完之后发现，这并非我想要的功用。
泛起这类状况的缘故是产品经理没有理解到这个需要面前的念头和目的，这是得多小火伴容易泛起的问题。而SaaS产品设计，不单单只关注设计，在此以前咱们更要关注产品的定义。需求咱们想分明这个需要对应的场景是甚么，场景中的需要价值是甚么。之后才是构造化的框架把功用设计出来。
文章总体分为下列几个部份：
SaaS产品设计痛点场景拆分SaaS产品不同维度的认知咱们经过甚么形式去了解业务咱们如何梳理业务判别需要价值咱们如何设计产品架构与功用SaaS产品生命周期中的设计准则下列，我们一同进入注释~
一、SaaS产品设计痛点场景拆分 1. SaaS产品经理的任务形式
SaaS产品经理?作实质是从发散到收敛的?个进程。发散是指产品的定义，收敛是指产品的设计。但往往得多产品经理?下去就开始收敛了，开始画原型，好?点的产品经理可能先去思考这个功用影响的规模，影响的面。最初梳理出?个脑图，用这个脑图去跟开发去碰，然而?个优秀的产品经理除了?下去就收敛以外，其次需求咱们思惟先发散，终究产品定义这个场景对应的价值是甚么。
2. SaaS产品了解业务是进?需要梳理与功用设计的条件
在这里在跟大家分享三个场景：
场景一：得多同窗都是半路转行过去做SaaS产品经理，往往会遇到不知道如何去跟进行业的趋向，同时也不知道如何去做业务调研。而关于业务了解的欠缺也间接影响到对应的产出，这时候候按照对业务了解而设计的产品计划也会被吐槽，不懂业务。这类场景我置信得多SaaS产品经理都会有许多感受。【了解业务难】
场景二：得多产品经理因为以前教训习气，专一思考单个场景下的用户价值，在这时候候会致使在思考业务场景时常常泛起脱漏，从而致使业务无奈闭环，终端用户对产品感到满意，却没有间接转换成付费。【需要梳理不明晰】
场景三：产品经理进行了全盘梳理，理清价值之后，全身心投入产品设计中去，但是业务泛起了?堆共性化需要，产品经理硬着头皮单点设计，最初演化成定制化设计，致使产品逻辑异样繁杂，研发本钱也不停降低，终端用户在前端界面也会吐槽愈来愈繁杂，不知道怎么动手了。【功用设计繁杂】
泛起下面三种场景状况的缘故是SaaS产品有十分强的业务壁垒，所以不同行业产品经理会泛起隔行如隔山的状况，产品设计不分明详细场景的痛点和难点。其次是SaaS产品业务流程是对比繁杂的，看似简略的功用也会波及多个角色，所以需求通盘斟酌。最初SaaS产品共性化需要十分多，需求知足不同共性化需要，所以致使设计计划繁杂。
所以接上去的文章也会环抱这三个场景去跟大家分享对应的产品办法论。
二、SaaS产品不同维度的认知 1. SaaS产品认知的歧义
得多人以为SaaS产品是toB产品，但从自身定义软件即办事来看，即没有说是toB也没有说是toC。而狭义的SaaS定义是既有toB也有toC（好比印象条记/石墨?档）。从软件交付形式来说，SaaS自身作为一种交付模式，自身不存在toB或toC之分。从商业模式来说，假如咱们把toB产品定义为基于互联网提供办事，?以晋升企业效力，减少企业收?的产品，那末SaaS产品能够算是B端产品的?个分支。
2. SaaS产品不同维度的认知
SaaS模式的泛起很大水平上是适应用户对数据平安和低保护本钱的需要而衍生的。
SaaS产品划分：业务垂直型（提供面向特定业务的SaaS解决计划好比：crm erp等）、行业垂直型（提供面向特定行业的SaaS解决计划好比批发电商、餐饮、医疗、制作业）行业和业务之间确定有穿插的，?个SaaS产品既会有特定的业务，也会见向特定的行业。
SaaS产品特征：
云端架构：SaaS公司提供办事器、数据库等硬件，无需当地部署；本钱降落：无需客户承当根底设施本钱、日常运维本钱，付费灵敏；用户按月/年领取费用，而非?次性购买，体验晋升；后续降级保护由SaaS公司担任，经过数据驱动迭代。SaaS产品业务阶段：总体划分为四个阶段，根底产品完美期、行业产品深化期、生态建立期、再翻新。


三、咱们经过甚么形式去了解业务 1. 业务了解=行业模式（微观）+企业运作流程（宏观）
对业务的了解咱们能够由笼统化转换为具象化，实质需求从行业模式和运作流程去理解。懂行业模式是要可以了解商定俗成的弄法和规定是甚么。懂运作流程是行业中某个企业不同岗位/角色如何各司其职的。运作流程是行业模式的直观体现，行业模式?为了解运作流程提供指南针。
了解行业的限度，理解他的主观法则从而防止走弯路，了解运作流程从而可以复原场景，并设计功用知足需要。所以咱们需求经过行业剖析理解行业模式，经过业务调研理解某个企业的运作流程。
?业模式：从微观角度，咱们理解行业内企业相应业务的弄法，从而笼统出通用的弄法和规定，这样咱们才能够理解企业的中心痛点，其次也为SaaS产品及办事提供标的目的指南。
运作流程：从宏观角度，关于每个企业咱们需求理解企业外部不同员工是如何操作的，终究完成公司业务运行，理解这些能力使咱们产品设计更为落地。


2. 行业模式（微观）：如何疾速理解一个行业
SaaS产品经理算半个行业专家。
网上做行业剖析的办法有得多，首要的是需求找对维度，不克不及只停留在大规模层面，而是需求聚焦于咱们本身业务的界限。对于维度层面这边跟大家分享五个剖析行业的维度，分别是：行业根底信息、内部运营环境、外部市场环境、标杆企业剖析、SaaS竞品剖析；


经过上诉几个维度咱们能够疾速理解?个行业，然而往往实际任务场景是咱们做出了?份剖析讲演，但不知道真正作用在哪?。这类状况下需求回归到实质，咱们是为了理解行业通用规定和弄法，终究办事于本身SaaS业务。
3. 企业运作流程（宏观）：如何进行业务调研
先跟大家讲讲C端产品的用户调研与SaaS产品业务调研的区分，C端用户调研只需求关注单点用户，SaaS业务调研需求全盘斟酌全部业务流程，这也是得多转行做SaaS产品经理会根据之前的调研形式，去做业务调研，容易致使产品流程上没有闭环。其次C端?户调研需求以用户体验为核心，相对于于来讲SaaS产品更关注需要，解决了甚么业务问题。最初C端产品用户需要层面相对于于容易抽离个性，SaaS自然存在少量共性化需要且极度扩散。并且C端产品?般都是用户能够经过共情来挖掘潜伏需要，SaaS产品经理通常不是用户，需求经过了解业务来挖掘需要。
4. 运作流程因素与调研步骤
业务调研终究是为了了解业务的运作流程，运作流程包罗的元素有甚么：企业（经过定义标杆企业描画客户画像）、角色（经过查看组织架构和参考同类型企业来梳理角色特点）、流程（经过视察与调研理解中心业务的任务流）。
业务调研总体分三步：


第?：定义并选择标杆企业。在这里需求定义标杆企业的客户画像，以标杆企业的需要为中心。客户画像包孕（客户/企业范围、从属细分类目、业务规模），在这外面为何咱们需求选择标杆企业的缘故是在于标杆企业需要拥有代表性，相对于容易抽离。其次也是由于标杆企业的声响有影响力，前期可以引领其余客户。
第?：梳理业务链条的??。在这?步梳理好业务流程中的症结角色之后，咱们需求定义角色的特点（次要担任甚么、业务指标标/KPI是甚么、职业特征是甚么），怎么找到这些业务流程中的症结角色，第?能够从企业的组织架构中寻觅，这是最便捷也是最间接疾速的办法。在得不到组织架构的状况下，能够参考同类型企业的流程及角色（固然这里的企业也是属于标杆企业），在做总体角色梳理的时分咱们必需要留意业务的闭环，假如疏忽了业务链条不首要的角色，可能会致使业务无奈闭环。
第三：视察与调研并行。在梳理完业务流程之后咱们需求经过视察与调研，理清角色的任务流（中心流程）。关于SaaS产品来讲，视察比间接凋谢式调研更无效，这么说的缘故是在于产品很难从根下来撼动绝大部份公司的业务模式，所以咱们着重在复原业务，而非发明业务，还有?个缘故是调研过程当中多少都会有客观成份在，所以需求经过视察复原业务。
视察的形式咱们能够经过驻场，深?业务需要方的任务场景，视察他们平时的任务形式。在视察的同时咱们也需求失掉这个角色的任务流是甚么模样的？有无规范化流程？在甚么状况下，履行了那系列工作，实现了甚么业务上的指标？还有?种形式轮岗机制，无机会的话可以间接上手体验业务方的任务是最佳的。用户调研次要从流程维度和详细场景维度去设计调研问题。
无理解业务这个层面上咱们需求按部就班的，了解业务没有太多的技能，经过视察和调研穿插，理解用户/用户需要，并经过产品设计知足需要，理解反馈，进而按照反馈继续知足需要—-经过不停地这样循环深耕业务，能力不停深入对业务的了解。
四、SaaS产品如何梳理业务判别需要价值
得多产品经理在做了?波业务调研之后，也对业务有了?定水平的了解，以为接上去就该到需要剖析了。并不是这样，除了对业务要有?个深度理解以外，还需求复原业务中遇到的场景是甚么，用户需要价值是甚么。如何去判别需要的价值，其实实质是咱们需求在产品定义这个环节去梳理明晰。
产品定义分两个部份：第?回归场景（梳理并形容业务场景），第?理清价值（判别场景中需要的价值）。
1. 为何要回归场景？
在这个跟?家形容两个咱们常见的任务场景，得多时分产品经理在提生产品计划时，大家环抱完成细节开始探讨的时分容易泛起，‘我感觉’的?式来表白本人的观念，每集体都有本人的设法，无奈达成统?的意见。还有?种状况是在没有了解场景的状况下间接开始画原型，这时候候会泛起咱们产品上线之后老是不合乎实际线上流程，还得推倒历来。
当初咱们回忆上?两个场景中为何泛起这类状况，实质是由于产品经理对外（名目组其余人），实现?项工作确定是需求多个部门多个角色频繁的传递用户需要，因此使用一套易了解，贴近实际的沟通的?式就很首要，而场景就是通行于不同角色之间解决产品问题的言语。
对内（本身思考）产品设计咱们需求先发散后收敛，因此动?画原型，写文档以前咱们需求做?量的思考，调研。逻辑基点是用户?临的实际状况究竟是甚么样的，即回归场景。
2. 单个场景与多个场景
在单个场景上，SaaS产品不克不及发明，只能复原。这也是和C真个区分点，C端由于本人就是用户，能够以发散的?式发明场景，从而引领用户需要。SaaS业务自然存在壁垒，无奈发散获得，只能复原场景，且颗粒度需求更细。在多个场景上，SaaS产品需求斟酌业务的闭环。一样以C端举例，c端产品相对于简略，重点在于单点冲破中心场景。SaaS产品业务链长，短少任何?个必备场景均可能?法闭环。所以回归场景咱们需求先将单个场景形容明晰，进而梳理链条中的全场景。
3. 场景咱们该如何去形容
回归场景咱们需求经过?种通?的场景形容形式，对内造成本人的思考基点，对外让大家造成共鸣。在这里跟大家分享?种场景形容办法，场景形容的7因素（用户、环境、机会、指标、举措、截止、工作）SaaS产品的场景是实在存在的，不是闭门造车的。需求在实在业务中失掉验证。场景形容形式自身不首要。首要的是对外可以造成统?的认知，对内思考可以复原用户实际状况才是症结。


针对单?的场景咱们能够经过单?场景形容形式去复原，针对多个场景时咱们能够借助场景需要清单，场景需要清单是多个场景串连造成的构造化信息，他是?个业务链条下的场景拆分后的需要聚拢，场景需要清单能够帮忙咱们梳理业务链条下的场景瓜葛，防止脱漏影响业务闭环的场景。基于以前的调研，找到关联步骤/流程，按照流程复原每个流程下的代表性场景，并拆解出需要。核?步骤提炼成三步：第?梳理出明晰地业务流程、第?将场景归类到流程中、第三基于场景拆分用户需要；需求留意的是每个流程下能够写多个拥有代表性的分?场景，同时咱们也能够把??标注出来。
示例：场景需要清单


当场景清单足够宏大时，咱们需求对原本的场景需要清单进行抽离，抽离出最症结的种别/流程，以及其中不成或缺的场景造成场景需要清单，这?步的中心在于如何抽离（需要了解业务），说到中心场景咱们需求后面提到的业务闭环，业务闭环咱们能够定义他为为了实现指标下的最小步骤的聚拢，中心场景即最小步骤的展开，关于最小步骤依赖于对业务的了解，需求站在业务员的角度，来看哪些是不成或缺的，同时咱们需求斟酌到不测状况下的分支场景，假如泛起不测状况而致使业务无奈进行，业务无奈闭环，那末也会致使用户保持使用产品。讲到这里咱们发现中心场景也是MVP版本。
4. 微观与宏观的价值理清（理清价值）
价值主意与需要对应的价值，二者之间产品的价值主意为判别需要的价值提供标的目的和准则，而不同需要价值的积攒进?步稳固价值主意。
价值主意（微观）：为特定用户群体提供差别化价值，价值主意是进行需要判别的第?准则，SaaS产品应该尽量知足每个客户的共性化需要，但不应包孕与价值主意彻底不?致的需要。假如在实际任务中遇到需要判别常常找不到标的目的，或许应该开始思考产品的价值主意。
需要价值（宏观）：需要的两种价值?是?户价值（给产品?户带来甚么），此外?种是商业价值（给SaaS?商带来甚么），针对用户（咱们提供业务闭环类价值、效用类价值、体验类价值）、关于SaaS厂商（支出价值、对本身是不是可以收集到更多的业务数据价值）。在SaaS产品顶用户价值中最多见的是效用价值。


5. 如何找出场景中的需要价值
找出价值咱们需求做的三件事：第?需要的用户价值是不是与产品价值主意相契合？第二用户的需要价值详细类型是甚么，表示在哪里？第三需要是不是存在商业价值，表示在哪里？
6. 如何判别场景中的需要价值
需要来源于场景，知足需要则发生价值，?对扑面而来的需要SaaS产品经理更需求明晰了解并判别需要的价值。SaaS产品为何更需求了解价值，缘故在于SaaS场景都是实在存在的，客户就是上帝，不存在伪需要，所以需求对?量需要进?判别。在需要判别中惯例会泛起三种场景分别是：


示例：场景需要价值清单


五、咱们如何设计业务架构与功用 1. 甚么是业务架构
关于SaaS产品首先咱们了解场景七因素中的任何?个因素产生变动，都会致使场景不?样，从而发生不?样的需要。SaaS产品有十分强的业务属性，假如不足框架性思考，单点设计功用将会让你精疲力尽，对外部来讲不停堆砌功用，开发本钱会愈来愈?，对内部来讲用户看到的信息复杂，无奈高效的实现工作，所以咱们设计功用前需求理清架构，以?种全局的框架视?来思考。
业务架构是?套功用依据业务进?分类整合，造成笼统化的业务模型，架构能够帮咱们理清每个业务模块/功用间的界限，以及他们之间的瓜葛，在咱们?对多个相似的需要时先梳理架构就能基于场景迅速定位到对应的模块，在设计功用时咱们需求重点斟酌以?个功用知足多个相似的需要。


业务架构：架构的作用在于建设?套规范化的业务模型，搭建框架，终究是为了高效知足用户的不同需要。所以也就是咱们常据说的后端规范化，前端共性化。了解业务是梳理功用架构的条件。
示例：微信业务架构


2. 基于目前的场景和需要咱们如何梳理架构
梳理架构分红三步?：第?将场景需要清单拆解到功用、第?将功用按不同维度整合、第三梳理模块之间的逻辑瓜葛；在第?步将功用按不同模块分类整合时咱们先拿出合乎通?模块的功用，进行归类整合，切记反复造轮?。不合乎通用模块的功用，按照业务首要水平和繁杂性独自整合。假如有须要按照业务首要水平和繁杂性，持续梳理?模块。在梳理模块之间的逻辑瓜葛时咱们先梳理动态模块（不发生数据流），在梳理静态模块（发生数据流）。总体外表上是梳理架构图，面前是对业务的粗浅了解。
架构实质是后端业务逻辑的规范化；在实现后端规范化之后，跟着产品的不停开展，咱们需求经过可配置的形式在前端知足?量共性化需要，即前端共性化。由于SaaS产品自身特质，咱们需求斟酌到少量共性化需要。那末咱们需求斟酌如何设计?个功用知足绝大少数需要，中心咱们需求应用可配置去解决前端共性化需要和后端业务归类。
3. 如何设计一个功用知足不同场景需要
经过可配置化知足客户的共性化需要。?般会存在两种状况，第?是业务流程与现无方案差异较小，那咱们能够从功用层面进行配置，第?是业务流程与现无方案差异大，那咱们从零碎层面进行配置。
在可配置层面?般来讲包孕界面规划，字段名、验证逻辑、计算规定、审批流配置，角色配置，角色功用权限配置，用户配置，用户数据权限配置等。在产品设计时需求布局好甚么样的配置功用凋谢给客户，甚么给到本人。准则上为了不客户的繁杂度，尽可能凋谢小规模的配置功用给到客户本人使用。高配置往往会形成低易用性，配置项过量会带来页面不简洁，流程不高效；实质下去说用户要的不是配置项，是低本钱完成指标的功用。
在判别功用要不要做成配置时咱们能够经过两个维度来做判别，?个是模式切换频率，还有?个则是需要的长尾水平（用户需要差别化水平），针对?些默许配置项判别规范咱们需求回归到场景，在少量同?品种型的共性化场景中，找到最中心的场景，并按照场景下的功用设计设置为默许配置项。
六、SaaS产品生命周期中的设计准则
经过后面的文章，咱们知道了SaaS产品的办法论之后，咱们也应该理解底层的设计准则，理解准则的益处有两点，艰深的来讲一方面是能够驱动产品优化和产品经理自身的自我生长，另外一里面则是能够打消内部给你带来的一些负面影响。
准则是自我改良的无利工具，能够在日常任务中验证咱们本人的办法论，帮忙本人生长；有了准则，就可以超脱情绪和环境的影响，自主判别选择最好计划。