SaaS产品是云计算中的一种服务类型，近年来已经成为一种流行趋势。作为设计师，如何设计SaaS产品的交互？

 

首先，我们要对SaaS产品有一个全面的了解，形成一个标准化的流程。

 

1.梳理产品目标

 

目标是第一位的，只有方向正确，才能沿着正确的道路不断前进。

我们可以先了解行业背景，比如我们的产品属于哪个行业，或者多个行业的通用产品。

 

此外，我们可以了解我们服务业的上下游环节，以及我们是处于末端环节、中间环节还是头部环节。

 

有了这些准备，我们开始专注于了解目标。

 

其实目标很多。企业在不同的发展阶段有不同的目标，比如某一年的目标，分季度、分月的目标，三到五年的战略发展目标。

 

这个目标也可以理解为商业目标。我们的用户也有用户目标，也就是用户使用这个产品想要达到的目的。

 

目标这么多，不应该全部遵守。这时产品经理需要平衡业务目标和用户目标，最终得到产品需要遵循的目标，即产品目标，作为后续工作的指导思想。

 

作为交互设计师，我们主要参与这部分的工作，用我们专业的交互知识帮助产品经理整理出最终的产品目标。

 

2.梳理业务流程图

 

这里有两种情况。如果是0对1的产品，我们需要分析实际的线下业务流程，先梳理一下，然后再考虑转到线上解决方案的时候如何设计业务流程。

 

如果是1到N的产品，应该已经有业务流程图了。我们要做的是熟悉和了解产品的业务流程；如果不是，我们要做的就是根据实际系统整理业务流程图。

 

做这项工作的主要目的是帮助我们先有一个全球化的产品感觉。

 

3.梳理功能架构图

 

同上，这里有两种情况。对于0到1的产品，可以先分析需求文档，提取里面的功能点，画出功能架构图。

 

如果需求文档的准备还没有开始，可以参与需求的处理，细化成功点，然后绘制功能架构图。

 

至于需求收集，我们通常将分散的需求放入需求池中进行管理。关于需求处理，可以用需求的四象限法来处理。

 

这种方法被需求分析师和产品经理广泛使用，主要是对需求池中的需求进行优先级排序。

 

横轴纵向表示紧急程度，横向表示重要程度。重要和紧急性质为主。过去，许多经验问题被置于不重要或不紧急的尴尬境地。随着体验时代的到来，体验有望提升到战略高度。

 

对于1到N的产品，功能架构比较简单，只是整理需求文档或者实际系统。目的是让自己大致了解产品的整体功能点。

 

4.组织权限描述和字段表

 

个人认为需求文档的这一部分属于底部。它可以分析产品的书面需求文档，提取权限描述和字段表。

 

如果产品编写的需求文档中没有这样的内容，就需要和产品经理进行面对面的沟通，了解产品的底层逻辑。

 

5.协助完成珠江三角洲文件

 

如果产品经理完成了PRD，我们会用自己专业的交互方式帮助产品经理优化PRD文档。

 

如果产品经理没有开始写PRD，可以用以上步骤协助产品经理写PRD文档。

 

主要是业务规则的编写，输入输出等。

 

B端SaaS产品设计：从0到1

所谓万事开头难，产品设计通常最难的是从0到1、从无到有，而后续的产品升级迭代则相对没有那么难。所以，笔者在这里重点讨论的是如何从0开始设计B端SaaS产品。笔者将B端SaaS产品从0到1的设计分为四个步骤：规划、梳理、设计与开发。

 

1、规划

首先要做的是确定产品的方向与目标，回答“要去到哪里”、“往哪个方向走”的问题。要回答这两个问题就需要开展缜密的分析。从宏观角度出发，先做行业研究，理解甲方企业所在的行业结构，了解甲方上下游价值链是怎样构成的，分析他们的商业模式和核心业务流程。在此基础上，分析甲方客户的普遍需求是什么，目前我们作为乙方是通过什么方式来满足甲方的这些需求的，还有哪些竞争对手是怎样提供服务的。然后，基于SWOT分析厘清自身的优势和劣势，认清外部的机遇和威胁，结合自身的服务能力与资源禀赋现状，找到适合的产品定位与目标。

2、梳理

第二步是在认准方向的基础上做深入细致的需求分析与梳理。在第一步我们已经锁定了产品方向，第二步首先要做的就是仔细研究这个产品方向所针对的甲方业务流程，分析业务流程涉及了哪些主要节点、每个节点的输入和输出是什么，整个流程的瓶颈和问题是什么等。然后带着这些问题深入到甲方客户中，开展内部访谈与调研。

访谈的对象涉及高层主管领导、中层管理者和基层执行人员，从高层领导处了解他们对业务运营的期望与目标，从中层管理者了解他们对业务运营的需求，从基层执行人员那里收集对产品使用层面的需求。然后综合竞品分析、内外部访谈和资料研究等方面的结果，梳理出一份产品功能的需求列表。对需求进行标注，哪些是显性的需求，哪些是隐性的需求，哪些是需要进一步挖掘的需求等。再根据ICE（Impact、Confidence、Ease）等评估方法对需求进行打分排序，输出新产品的路线图。

3、设计

接下来就进入了产品设计阶段。这里的套路就是一些比较常规的产品设计路线，是做产品设计的常用流程。从MVP定义开始，再是产品的整体架构设计、前后台产品框架设计、技术架构设计等，然后输出产品的PRD文档，设计原型界面和UI方案。PRD文档、原型和UI方案按序评审后就可以进入下一道工序了。

4、开发

最后一步是开发，意味着进入到产品从纸面上的图形模拟进入实际的代码开发阶段了。首先，B端产品经理要与技术开发相关负责人敲定产品开发的排期，明确时间节点和输出物、责任人等。产品开发的工作至此就转入到了技术支持团队手中，技术开发相关负责人需要组织技术人员进行产品实现的技术方案设计与评审，再将开发任务分配到前端、后端、数据库等技术人员手中，规定具体任务和期限，然后就是各方面的技术人员分头去开发落实了。当技术开发到可测试的程度时，B端产品经理就要协调各方面进行联调测试和灰度测试，这些测试通过后才可以进入到最后的上线发布。当然，如果产品测试没有达到要求时，还需要技术开发人员反查问题、及时优化，直至满足要求才可部署上线。

以上是对B端SaaS产品从0到1的流程与步骤的大致介绍。实现从0到1只是万里长征的第一步，当然，也是至关重要的一步。

 

动词 （verb的缩写）交互式设计

 

1.设计目标

 

基于之前的产品目标，我们需要细化交互设计师应该遵循的设计目标。

 

我们经常使用KANO模型来整理设计目标，这可以帮助我们确定可以增强用户体验的需求点。

 

下面我将详细谈谈如何使用KANO模型:

 

横轴表示用户满意度，横轴表示功能满意度。

 

这个需求点满足后，用户满意度有明显提升，但是不满足，用户满意度也不会很低，我们把这种需求叫做兴奋型需求，也可以理解为人打了兴奋剂一般，但是不打，人也能正常生活。

 

这个需求点满足后，用户满意度有明显提升，但是不满足，用户满意度也会明显下降，我们把这种需求叫做期望型需求，也可以理解为一种正比关系。

 

这个需求点满足后，用户满意度提升不明显，但是不满足，用户满意度却会明显下降，我们把这种需求叫做基本型需求。

 

这个里面基本型需求和期望型需求，都是客户的刚需，必须要满足的，不然客户就会很不爽，而兴奋型需求则是交互设计师需要努力挖掘的点，提升转化的发力点。

 

这个需求点满足后，用户满意度没有任何变化，可有可无的感觉，我们把这种需求叫做无差异型需求，这种需求就是可以直接抛弃掉做减法了。

 

这个需求点满足后，用户满意度反而明显下降，我们把这种需求叫做反向需求，这种就可以理解为禁区了，同样也是要直接抛弃掉做减法了。

 

通过KANO模型整理出产品的交互设计目标后，可以根据产品迭代的进度将目标拆分成不同的版本。

 

2.需求分析

 

仔细阅读产品经理输出的需求文档，用交互设计师的思路分析需求。

 

比如分析需求范围、功能点、权限描述、字段表。如果交互设计师在协助阶段充分参与以上步骤，这里的工作会更简单，进一步把握产品业务，逐渐让自己成为一名业务顾问，在项目推进的时候更好的回答下游成员的问题。

 

如果交互设计师不参与协助产品，只需要对照需求文档分析需求范围、功能点、权限描述、字段表即可。

 

如果需求文档不清楚，也可以亲自和产品经理沟通这些细节。

 

3.竞争性产品分析

 

竞争性产品分析首先需要分析我们产品的直接竞争对手，比如和我们做类似产品的老竞争对手和新竞争对手。

 

其次，我们需要分析一下我们产品的间接竞争对手，他们可能和我们同行业，但是产品不一样，不能保证以后不会做我们这个领域。

 

最后是行业巨头的竞争。这里的主要目的是看看我们的市场规模是否足以吸引巨头加入。

 

因此，我们应该努力把重点放在SaaS产品的细分上，这样市场天花板就在那里，巨头们就不能小看这么小的利润。

 

推而广之，我想详细说说如何为SaaS产品打造护城河。b端产品不同于C端产品。

 

随着行业的深度积累，新的竞争对手门槛很高，俗称护城河。我从以下几个方面来谈谈如何为SaaS产品打造护城河:

 

1)重置成本

 

客户一直在使用我们的产品。如果有一天他们被竞争对手的销售成功逆转，转而使用他们的产品，客户会发现更换成本非常高。

 

首先是数据迁移的成本，需要将我们系统中的所有数据迁移到新的服务提供商；此外，业务理解的差异会导致数据结构的不同，这可能会导致许多数据丢失或无法迁移。

 

其次，客户培训的成本。旧系统可能花了很多精力，用的很巧妙。现在要切换系统，系统用户要花很多精力去学习新系统。

 

2)品牌效应

 

在某个领域或行业获得了一定的声誉，解决了客户的一些痛点，受到客户的欢迎，从而形成了自己的品牌感。

 

3)网络效应

 

客户的上游和下游已经习惯了使用公司的系统。虽然客户不使用这种产品，但为了方便与上下游合作，他必须使用它。

 

这就是所谓的网络效应。比如C端，你的朋友用微信。如果不用的话，是不是不方便联系他们，就要用。

 

具有网络效应的产品正处于疯狂增长期，大量新客户不得不用你的产品。

 

4)关注子行业

 

能量有限，很难做到大而全，尤其是很多大厂虎视眈眈的时候。如果我们能专注于一个非常细分的行业，我们的利润上限就那样，大厂也不会因为看不上这个市场而和你竞争。

 

另外，其他新的竞争对手也因为你的专注而不敢挑战你，所以你可以在这个领域继续发展。

 

5)总结

 

说了这么多，其实moat最根本的还是服务好客户，给客户带来价值，让客户不断更新收费。

 

无论开发团队多么强大，如果没有客户愿意为生产出来的产品买单，那就毫无意义。

 

重点是公司的战略要控制大方向，产品经理要控制详细方向，包括业务价值、客户价值、客户体验。

 

4.交互模型

 

如果前三步都是准备工作，那么交互模型阶段就是交互设计的正式开始。

 

我总结的交互模型方法挺好用的，就是用户，场景，目标。

 

用户，指使用这个项目或产品的都是些什么人。B端行业，我们面对的是客户，但是客户作为一个企业，里面也有形形色色的个人，这些具体的人也就是用户。

 

用户可能有很多，需要找到我们的目标用户，对应的我们可能会有用户画像或者客户画像。

 

我们常说的以用户为中心，或者以客户为中心，基本就是以此为基础。中国经济的下半场也越来越注重B端行业的客户体验了。

 

继续深挖下，我们可以有用户体验地图以及用户旅行地图，而这两者的区别主要在于体验。

 

体验地图主要是针对所思、所做、所感；旅行地图则针对所做。场景，大公司有很多基于场景化的B端设计方法，我们需要去挖掘可能存在的用户场景，常用的方法有故事板，用讲故事的方式把场景描述清楚。很多用户体验设计以及情感化设计也是基于对场景的挖掘为基础。

 

目标，也可以理解为任务，用户或者客户使用这个系统要做的事情，或者我们也可以理解为用户的痛点以及期望，我们设计这款系统就是为了要解决客户的这些问题。

 

关于目标，深挖下，我们有用户目标和商业目标，两者平衡下，得出产品目标或者业务目标，设计师可以根据业务目标提炼出设计目标，当然这个目标一定是可量化，可验证的，我们只有准确知道了目标完成的如何，才好安排迭代的方向。

 

交互模式主要是让我们先对产品的整体框架有一个了解，最后我想深入挖掘用户。事实上，在SaaS产品的设计过程中，我们需要非常了解客户。

 

这里，我想分两种情况。如果是0比1的产品，肯定需要把线下的业务搬到线上来解决。

 

因此，我们需要对客户的线下痛点有一个清晰的认识，比如客户目前存在哪些无法解决的痛点，在无法解决之前用了哪些替代方法来解决。

 

另外，要把客户线下的业务流程梳理清楚，以便区分不同的用户和场景。

 

如果是已经上线的产品，无论迭代到哪个版本，这一次我们都处于产品优化阶段。

 

如果还处于发展阶段，此时的战略目标是进一步扩大新客户数量，保证老客户更新换代，产品设计需要围绕这个目标进行。

 

如果处于成熟阶段，此时客户可能会觉得我们的产品没有创新，新客户较少，部分老客户开始不续费，或者产品不符合目前的客户市场。

 

这时候的战略目标是优化产品，可能是提升用户体验，也可能是调整产品的功能方向。

 

要了解优化中的客户，主要是要找出客户目前在线的痛点，精细梳理用户流程，找到优化的方向。

 

5.信息架构

 

在我看来，信息架构设计其实就是从用户的角度来设计之前的功能架构图，主要是设计产品的导航系统。

 

还有一点就是为正式绘制页面原型打下基础。有的交互设计师得到需求后直接开始画原型。

 

其实这是非常错误的，不仅效率低，而且返工率高。正确的做法是详细分析后画出原型。这种思维方式不仅清晰，而且节省时间。

 

6.任务流程

 

根据上面分析的交互模型，我们需要针对不同场景下不同用户的不同任务进行精细设计，尽量覆盖所有用户任务流程。

 

任务流程可以理解为多个节点，每个节点都是一个或多个页面，这样主体的页面原型框架就出来了，也可以为后面绘制原型打下基础，但只是为了不漏掉一些细节页面和边界页面，提高原型绘制的准确性。

 

7.页面原型

 

随着信息架构和任务流程的准备，页面原型阶段自然会省去很多麻烦。这里我主要想说一下画原型需要遵循的一些原则。

 

除了格式塔原理和菲茨定律，还有四种交互设计策略，即组织、删除、隐藏和转移。

 

组织——可以理解为分组，相近和相似原则，对产品的信息架构进行设计。

 

删除——少即是多原则，精简用户看到的界面，提高用户解决问题的专注力。隐藏——不是很重要的信息，都隐藏起来，当用户需要时，可以通过操作找到。

 

转移——给用户简单的体验，把复杂的东西转移到后台；另外一些设置参数的，也是尽量转移给后台，给用户一种简单的操作。

 

交互设计的方式有很多，关键看你怎么用。

 

我们的最终目标是希望用户看到页面就知道如何操作。经过系统反馈，用户知道如何进行下一步，从而形成流畅的操作体验，进一步使产品自动化、智能化、人性化。

 

8.互动评论

 

我觉得互动复习之前有一些准备工作需要提前完成。原型绘制完成后，需要与产品、技术boss、boss沟通达成共识，然后补充交互描述，输出交互文档，再用交互文档与关键人物再次沟通。因为我觉得如果交互评审只是把交互文档传达给下游UI、开发、测试等人员，阻力会小很多。

 

另外，如果在设计过程中有一些疑惑，也可以找相关人员确认，这样可以提高整体设计效率。

 

正式互动审核流程如下:

 

1)介绍产品背景

 

在解释的开始，有必要简单描述一下这个产品建立的大致环境，比如为什么制作，怎么制作，产品背景。

 

2)说出问题

 

我们的总体商业愿望是什么？这次我们解决了哪些用户痛点？我们的产品目标是什么？而交互设计的目标是什么？说明以上问题，告诉大家在开始做交互设计之前做了哪些准备。

 

3)如何解决问题，说说设计过程

 

如果有数据分析，可以说作为前奏，没有数据分析也没关系。

 

此时，您可以从头到尾解释整个交互式文档。原型设计的一些关键点可以详细讨论。为什么要这样设计？前面的推导过程是可以描述的，或者是竞争性的演示，多方案的选择等。

 

另外可以谈谈设计策略，如何解决问题，解决过程中发生了什么。

不及物动词设计着陆

 

设计落地主要是指交互评审通过后，交互设计方案如何有效落地。

 

1.设计进步

 

这时，下游合作伙伴开始按计划工作。在这个过程中，我们需要回答关于UI、开发和测试的业务问题。作为产品的业务顾问，应该有很多工作要做。

 

当被问及时，我们也可以阅读交互式文档来整理我们的想法。得到交互文档后，UI也会开始UI设计，交互设计师需要控制UI的输出，协助UI设计师进行UI审核。

 

如果UI最终效果不好，会影响产品的体验，所以交互设计需要控制这些细节。

 

作为产品需求的执行者，在测试阶段，除了控制交互测试，还要保证交互文档中的细节能够完美实现；同时要控制好需求测试，确保产品实现效果符合需求设计。

 

2.可用性测试

 

在测试工程师稳定了功能之后，交互设计师需要领导可用性测试过程。我个人对可用性测试有一些看法。

 

可用性测试是在产品功能稳定后，在测试环境中寻找一些真实用户来完成核心用户任务流，从而验证投入产出比，解决产品易用的问题。

 

在用户测试之前，可以设置一些指标，比如完成率、完成时间，也就是有多少用户可以完成流程，用户花了多少时间。

 

通过对用户感受和最终数据结果的现场观察，可以得出以下结论:

 

产品是否解决了用户的业务痛点，是否是自己想用的产品，可以理解为是否可用。

 

体验流程过程中，用户的操作和系统反馈是否顺畅，不进行培训用户上手的难度如何以及培训后用户操作的流畅性如何等，可以理解为是否易用，同时也可以提前知道后期培训用户的成本会有多大。

 

产品的视觉美观度如何，部分用户可能会提一些好不好看的问题。

 

产品的品牌传播效果如何，通过以上的结果，可以自己挖掘到该产品以后去推广时，品牌传播效应如何。

 

3.漏斗分析

 

项目上线后，我们需要收集用户使用反馈和数据分析，根据反馈结果和数据分析结果进行版本迭代设计，不断优化产品的最终体验效果。

 

关于数据分析，我们经常使用漏斗指标。根据用户的任务流程，可以选择核心流程，查看每一步的用户流失率。

 

比如第一步用户数是10000，第二步是8000，最后只有100人完成这个过程。此时转化率只有1%，亏损99%。

 

过程中损失较大的步骤也可以作为改善用户体验的分析点。漏斗分析也可以作为A/B检验的数据证明。

 

总结

 

如何利用用户体验点来判断产品最终的体验效果。简单来说，用户体验好的产品有什么特点？

 

1.从五个层次的经验来看

 

1)业务水平，符合业务目标

 

即需要满足产品开发的战略目标。我们做的所有产品都是商业商品，所有产品首先要满足自己的商业价值。

 

当然，我们需要平衡业务价值和用户价值，不能只关注业务价值，而不顾用户。时间长了，用户就会抛弃这个产品；同理，不能只关注用户价值。

 

这样产品就没有商业闭环，无法盈利，最终会因为供给端的成本而崩溃。

 

2)函数层，减去函数

 

这个减法的主要意思是突出产品的核心价值，而不是一下子把所有的功能都做了。

 

有句话叫“多即是少”，功能都有。找不到关键点就什么都没有了，也不会体现出对用户的价值。

 

因此，我们需要遵循“少即是多”的原则，精简产品功能，突出核心价值，把解决用户痛点放在首位，以后不断放大这个核心价值。

 

3)流程层，针对不同用户的不同场景进行精细设计

 

首先，用户需要分层，这个用户可能属于不同的组织。简单来说，首先要梳理用户的层次。

 

常见的是老板、经理、员工这三层。其次，基于这些分层的用户，梳理出可能出现的场景，比如老板在什么情况下会使用这个产品，有哪些痛点。

 

有了以上的梳理，我们就把任务流程细化，尽量把所有可能的流程梳理出来。

 

4)认知层，页面具有良好的认知属性

 

这主要是针对页面的使用成本，可以考虑四种交互策略的原则，即整理、删除、隐藏、转移。

 

设计整体页面架构，降低页面使用成本，提高产品的反馈能力。

 

5)视觉层，视觉美感好

 

产品外部形象好，吸引用户，有很好的情感设计。更高的视觉层次是产品有品牌感，作为用户喜爱的品牌在市场上推广。

 

2.从用户流程优化的角度来看

 

前一种方法可以用来设计从0到1的产品，也可以作为从1到n的产品进行优化，这里只针对后期优化的产品，但是需要公司把用户体验提升到战略层面。

 

1)降低用户的认知成本，使产品自动化、智能化、人性化

 

这个和上面的认知层差不多，但是还需要更进一步。我们需要产品更人性化。人是群居的，人总是喜欢和人打交道。

 

如果产品足够人性化，用户使用产品就像与人打交道一样简单，似乎可以超出用户的预期。

 

有句话叫好产品会说话，就是这个道理。

 

2)减少场景切换，分离简单场景，拆分复杂场景

 

这里主要关注用户场景的优化。场景很多。在产品开发后期，需要进一步细化体验，所以需要进一步优化场景。

 

尽量让用户在一个页面上完成一个功能，而不是做一件简单的事情，你需要来回切换页面。

 

如果是复杂的功能操作，可以将操作分为多个步骤，然后每一步都是独立的，类似于将大事化小，大大降低了用户的运营成本。

 

3)优化用户行为

 

在产品开发的某个阶段，通过数据分析可以获得用户的很多行为。如果我们希望用户做一些事情，我们也可以设计用户的行为，让用户按照我们的期望来操作。

 

B端SaaS产品运营：“三分法”

关于B端SaaS产品的运营，笔者总结为“三分法”，即产品分阶段、目标分解化、运营分步骤。

 

1、产品分阶段

按照产品的生命周期，将其分为四个阶段：产品探索期、产品增长期、产品成熟期和产品衰退期。每个阶段有相应的认定标准，各个阶段要聚焦的目标各有侧重，相应的产品策略和运营思路也会有差异。

2、目标分解化

按照产品的战略目标与规划，将产品的目标分解到四个阶段中。再将每个阶段的目标进行指标化和数量化。产品探索期的主要目标是找到PMF（Product Market Fit，产品与市场的契合点），这个阶段的关键指标是种子客户数、留存率等；产品增长期的主要目标是快速扩张客户规模，此阶段对应的关键指标是新增客户数、目标客户渗透率、MRR等；产品成熟期的主要目标是提升客户价值，此阶段对应的关键指标是LTV、复购率、ARPU等；产品衰退期的主要目标是延长客户生命周期，此阶段对应的关键指标是客户流失率、产品使用时长等。

3、运营分步骤

所谓运营分步骤是指SaaS产品的运营分为四个步骤：获取客户、服务跟进、付费转化和客户维系。这四个步骤映射到产品生命周期的四个阶段后，就会形成相应的思路和举措。比如，在产品探索期的主要获客举措是借助高层领导的影响力，推动与甲方领导的高层互访，按照三步曲来走，即高层拜访——邀请客户参观考察——签订战略合作协议。同时，推进线上渠道获客，利用百度大搜、官网、EDM、seo等手段收集销售线索。

 

还需要说明的是，在产品的不同生命周期阶段，产品运营的侧重点也会有所差异，也即是投入到获取客户、服务跟进、付费转化和客户维系中的资源会有所不同。比如，在产品增长期应将主要精力聚焦在获取客户上，在产品成熟期则应将主要的精力放在付费转化和客户维系上。

 

作者：产品找北