SaaS产品的交互设计流程

D.cheerful 2023-07-29 16:49:44

一、前言

近几年国家提出的新基建，给我们带来了很多新概念，比如5G、大数据、云计算、物联网、区块链等，而SaaS产品其实是属于云计算中的一种服务类型。云计算则依次包括：IaaS基础设施即服务、PaaS平台即服务、SaaS软件即服务。

二、背景知识

关于SaaS产品的商业发展，可以有两种类型，即橄榄型和哑铃型。

橄榄型，即头部窄，中间宽，尾部窄的结构。对应商业发展，就是头部大企业很少，中间中小型企业很多，尾部小微企业很少。大企业的业务比较复杂，并且在具体的行业里有标杆性，我们做一套SaaS产品可能很难覆盖全大企业的业务需求，大部分都会要求在这个标准化产品的基础上进一步定制化。从大企业那里获取到的行业规则又可被SaaS标准化产品吸收，进一步提升中小型企业的业务满足度。所以说，橄榄型商业结构很适合SaaS产品发展。
哑铃型，即头尾很大，中间很小的结构。对应商业发展，就是头部企业很多，中小型企业很少，小微企业很多。这种模式其实不是很适合SaaS产品的标准化发展，大企业定制化需求多，小微企业喜欢免费产品，就算开始花钱用了，可能后面倒闭就不再续费了，市场价值很低。

关于SaaS产品的分类，可以分为通用型和行业型。

通用型就是指不限于某个行业的产品，所有行业都可以用，比如CRM、HR、OA、ERP系统等。
行业型就是指只针对某个垂直行业来做企业的信息化产品，比如生鲜行业、餐饮行业、金融行业等。

随着SaaS产品的发展，目前我们还可以分为工具型和商业型。

工具型就是指我们只是给企业提供一个信息化的工具，可以给企业增效降本，但是具体如何操作，需要企业自己去摸索，就好比某个人肚子饿了，我只负责提供餐具和炊具，至于如何解决肚子饿的问题，管不了。
商业型就是我们需要让企业成功，需要深入到企业的业务里面去，帮助其打通上下游链路，最终帮企业创造价值并获得商业成功。比如企业是一个药店，我们需要帮助药店提升利润，帮助其赚到钱。前面说的那个肚子饿的问题，在这里就是需要给那个人提供丰盛的食物，而不仅仅只是给他提供工具和食材那么简单了。

三、商业分析

关于如何分析SaaS产品的商业环境，有一个模型可以用，即波特五力模型：

现有竞争者——就是你选择的赛道，目前跟你一起跑的产品。
新入竞争者——新加入你这个赛道的产品。
替代品竞争者——就是客户可以不用你这个产品，改用其他解决方案，同时有其他产品可以提供这种解决方案。
供应商议价能力——这个其实是指做这个产品的成本，主要还是人力资源成本。
买家议价能力——客户购买你这个产品的意愿，关键还是续费的动力。

前期需要对负责产品的商业环境进行充分了解，可以询问高层及其他决策人员，也可以直接问产品经理。

四、协助产品

这个过程主要是协助产品经理完成一些工作，包括参与对需求进行分析等。

1. 梳理产品目标

目标是第一位的，有了正确的方向才好沿着正确的道路一直走下去。

我们可以先了解行业背景，比如我们的产品是属于哪个行业的，或者是针对多个行业的通用产品。另外可以了解下我们服务行业的上下游全链路，我们是处于末端环节、中间环节、还是头部环节。有了这些准备工作后，开始重点了解目标了。

目标其实有很多，企业在不同的发展阶段，其目标也是不一样的，比如某年的目标，以及拆分到季度和月度的目标，另外还有3到5年的战略发展目标等，这个目标我们也可以理解为商业目标。我们的用户也有用户目标，就是用户希望通过使用这个产品达到一个什么期望。有了这么多的目标，也不是全部都要遵守的，这个时候产品经理需要去平衡商业目标与用户目标，最终得出产品需要遵循的目标，即产品目标，以此作为后续工作的指导思想。

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

2. 梳理业务流程图

这里需要分两种情况，如果是0到1的产品，我们需要分析线下的实际业务流程，先梳理出来，然后考虑要是搬到线上解决时，应该如何来设计业务流程。

如果是1到N的产品，应该已经有了业务流程图，我们要做的就是去熟悉，了解产品的业务流程；如果没有，我们要做的就是对照实际系统去梳理出业务流程图。

做这个工作的最主要目的还是帮助我们先有一个全局的产品感觉。

3. 梳理功能架构图

同上，这里也需要分两种情况，0到1的产品，可以先对需求文档进行分析，将里面的功能点提炼出来，绘制功能架构图。如果需求文档编写还没有开始，则可以参与对需求进行处理，并细化成功能点，然后再绘制功能架构图。

关于需求搜集，我们一般是把零散的需求丢进需求池进行管理。关于需求处理，则可以用需求四象限法则来处理。这个方法需求分析师和产品经理用的多，主要是对需求池里的需求进行优先级排序，十字轴里面纵向代表紧急程度，横向代表重要程度。重要又紧急的自然是优先处理的，以前很多体验问题都被放在不重要不紧急的尴尬位置，随着体验时代的到来，体验估计会被提升到战略高度。

1到N的产品，功能架构就比较简单了，对着需求文档或者对着实际系统去梳理出来就行。目的就是让自己对产品的整体功能点有个大致了解。

4. 整理权限说明、字段表

我个人觉得，在需求文档中，这部分内容属于底层的部分。可以对产品写好的需求文档进行分析，提炼出权限说明和字段表。如果产品写的需求文档中没有此部分内容，则需要找产品经理面对面沟通了，这样做主要是了解产品的底层逻辑。

5. 协助完成PRD文档

如果产品经理已经完成了PRD，我们就用自己专业的交互方法去协助产品经理优化PRD文档。如果产品经理没有开始写PRD，就可以用以上几步去协助产品经理来编写PRD文档。

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

五、交互设计

1. 设计目标

基于前面的产品目标，我们需要提炼出交互设计师要遵循的设计目标。关于设计目标，我们常用KANO模型来梳理，此方法可以帮助我们找准可以提升用户体验的需求点。

下面我会详细聊聊如何使用KANO模型：

十字轴里面纵向代表用户满意度，横向代表功能满足程度。

这个需求点满足后，用户满意度有明显提升，但是不满足，用户满意度也不会很低，我们把这种需求叫做兴奋型需求，也可以理解为人打了兴奋剂一般，但是不打，人也能正常生活。
这个需求点满足后，用户满意度有明显提升，但是不满足，用户满意度也会明显下降，我们把这种需求叫做期望型需求，也可以理解为一种正比关系。
这个需求点满足后，用户满意度提升不明显，但是不满足，用户满意度却会明显下降，我们把这种需求叫做基本型需求。
这个里面基本型需求和期望型需求，都是客户的刚需，必须要满足的，不然客户就会很不爽，而兴奋型需求则是交互设计师需要努力挖掘的点，提升转化的发力点。
这个需求点满足后，用户满意度没有任何变化，可有可无的感觉，我们把这种需求叫做无差异型需求，这种需求就是可以直接抛弃掉做减法了。
这个需求点满足后，用户满意度反而明显下降，我们把这种需求叫做反向需求，这种就可以理解为禁区了，同样也是要直接抛弃掉做减法了。

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

2. 需求分析

把产品经理输出的需求文档仔细阅读，并用交互设计师的思路来进行需求分析。比如分析需求范围、功能点、权限说明和字段表，如果在协助阶段，交互设计师充分参与了以上步骤，这里的工作也会比较简单了，进一步掌握产品业务，逐渐让自己成为业务顾问，以便项目推进时可以更好地去解答下游成员的疑问。

如果交互设计师没有参与协助产品的工作，在这里只需要对照需求文档，去分析需求范围、功能点、权限说明和字段表，需求文档不清晰的，也可以当面找产品经理去沟通这些细节。

3. 竞品分析

竞品分析首先需要分析我们产品的直接竞争对手，比如跟我们做类似产品的老对手、新加入的对手等。其次需要分析我们产品的间接竞争对手，可能是跟我们同一个行业，但是做的产品不同，不能保证他们未来不会做我们这个领域。最后是行业巨头的竞争，这里主要是看一下我们的市场规模是否足够吸引巨头来加入，所以说做SaaS产品还是尽量专注于一个细分领域，这样市场天花板在那里，巨头看不上这种小利的。

引申一下，我想详细谈谈如何打造SaaS产品的护城河。B端产品不同于C端产品，随着行业深度的积累，对新竞争者有很高的门槛，我们俗称护城河。下面我从以下几个方面来聊聊如何打造SaaS产品的护城河：

1）替换成本

客户一直用我们的产品，如果某天被竞争对手的销售成功策反了，转而改用他们的产品，这个时候，客户会发现，替换成本很高。

首先就是数据迁移成本，需要把我们系统中的数据全部迁移到新的服务商那里；另外业务理解上的差异会造成数据结构不同，由此可能会造成很多数据缺失或者无法迁移过来。

其次是客户培训成本，老系统可能当时花了很多精力已经用的很熟练了，如今要切换系统，系统使用者又得花很大精力去学习新的系统。

2）品牌效应

在某个领域或者某个行业内有了一定口碑，解决了客户的某些痛点，受到客户欢迎，由此形成了自己的品牌感。

3）网络效应

客户的上下游已经习惯了使用某个公司的系统，虽然该客户没有使用这个产品，但是为了方便与上下游协作，也不得不使用该产品，这就是所谓的网络效应。举个C端的例子，微信的使用，你的朋友都是用微信了，如果你不用，是不是不方便去联系他们，所以你也不得不使用。

有了网络效应的产品，正是疯狂增长的时期，大量新客户不得不使用你的产品。

4）聚焦细分行业

精力有限，很难大而全，特别是很多大厂虎视眈眈的。如果我们可以聚焦某个很细分的行业，本身利润天花板就那样，大厂看不上这点市场，自然不会与你来竞争。另外其他新进竞争者也由于你的专注度望而生畏，不敢去挑战你，故而你可以在该领域持续发展。

5）总结

说了那么多，其实护城河最根本的也是服务好客户，给客户带来价值，让客户保持续费。

开发团队不管多厉害，要是做出来的产品，没有客户愿意买单，等于一无是处。关键的点还是得公司的战略去把控大的方向，产品经理去把控细节的方向，包括商业价值，客户价值，客户体验等。

4. 交互模型

如果说前面三步都属于准备工作的话，那交互模型阶段则是正式开始交互设计了。

我总结而来的交互模型方法还是挺好用的，即用户、场景、目标。

用户，指使用这个项目或产品的都是些什么人。B端行业，我们面对的是客户，但是客户作为一个企业，里面也有形形色色的个人，这些具体的人也就是用户。用户可能有很多，需要找到我们的目标用户，对应的我们可能会有用户画像或者客户画像。我们常说的以用户为中心，或者以客户为中心，基本就是以此为基础。中国经济的下半场也越来越注重B端行业的客户体验了。继续深挖下，我们可以有用户体验地图以及用户旅行地图，而这两者的区别主要在于体验。体验地图主要是针对所思、所做、所感；旅行地图则针对所做。
场景，大公司有很多基于场景化的B端设计方法，我们需要去挖掘可能存在的用户场景，常用的方法有故事板，用讲故事的方式把场景描述清楚。很多用户体验设计以及情感化设计也是基于对场景的挖掘为基础。
目标，也可以理解为任务，用户或者客户使用这个系统要做的事情，或者我们也可以理解为用户的痛点以及期望，我们设计这款系统就是为了要解决客户的这些问题。关于目标，深挖下，我们有用户目标和商业目标，两者平衡下，得出产品目标或者业务目标，设计师可以根据业务目标提炼出设计目标，当然这个目标一定是可量化，可验证的，我们只有准确知道了目标完成的如何，才好安排迭代的方向。

交互模型主要是让我们先对产品整体的框架有个认识，最后我想把用户再深挖下，针对SaaS产品的设计过程其实我们需要做到很懂客户。

这里我想分两种情况，如果是0到1的产品，我们肯定是需要把线下的业务搬到线上来解决的，所以需要对客户线下的痛点摸得很清楚，比如客户目前存在哪些无法解决的痛点、无法解决时以前又是通过何种变通方法来解决的。另外需要对客户线下的业务流程梳理的很清楚，可以区分出不同的用户和场景。

如果是已经上线的产品，不管是迭代到第几个版本了，这个时候我们属于对产品进行优化的阶段。如果是还处于发展期，这个时候的战略目标是进一步扩大新客量以及保证老客户续费量，产品设计需要围绕这个目标去开展。如果是处于成熟期，这个时候客户可能觉得我们的产品没有创新了，新客户变少以及部分老客户开始不续费了，或者是产品不满足目前的客户市场了。这个时候的战略目标就是优化产品，可能是用户体验的提升，也可能是调整产品功能方向等。优化时的懂客户，主要是需要把客户目前线上的痛点给找出来，并对用户流程做精细化的梳理，找到优化的方向。

5. 信息架构

在我看来，信息架构设计其实就是把前面的功能架构图按照用户视角来设计，主要是设计产品的导航体系了。另外一点就是为后面正式画页面原型打下基础，有一些交互设计师在拿到需求后就直接开始画原型，其实这是很不对的，不仅效率低，返工率也很高，正确的做法还是进行详细的分析后，再来画原型，这样思路不仅很清晰，反而节省了时间。

6. 任务流程

针对前面分析的交互模型，我们需要针对不同用户在不同场景下的不同任务做一个精细化设计，尽量覆盖全所有的用户任务流程。任务流程可以理解为很多个节点，而每个节点则是一到多个页面，这样主体的页面原型框架就出来了，同样可以为后面画原型打下基础，只不过在这里是为了不漏掉一些细节页面和边界页面，提高原型绘制的准确度。

7. 页面原型

有了信息架构和任务流程两个阶段的准备，页面原型阶段自然会省事很多，在这里我主要想说说画原型还需要遵循的一些原则。除了格式塔原理和菲茨定律，还有交互设计的四种策略，即组织、删除、隐藏、转移。

组织——可以理解为分组，相近和相似原则，对产品的信息架构进行设计。
删除——少即是多原则，精简用户看到的界面，提高用户解决问题的专注力。
隐藏——不是很重要的信息，都隐藏起来，当用户需要时，可以通过操作找到。
转移——给用户简单的体验，把复杂的东西转移到后台；另外一些设置参数的，也是尽量转移给后台，给用户一种简单的操作。

交互设计的方法有很多，关键看你怎么用了，我们最终的目标是希望用户看页面时知道如何操作，系统反馈后，用户知道如何走下一步，如此形成流畅的操作体验，并进一步让产品自动化、智能化、人性化。

8. 交互评审

我觉得在进行交互评审之前，有一些准备工作需要提前完成。原型画好后，需要与产品、技术老大、老板先进行沟通，达成共识，然后再补充交互说明，并输出交互文档，然后拿着交互文档与关键人物再沟通一遍。因为我觉得交互评审如果只是给下游UI、开发、测试以及其他人员传达交互文档，这样阻力会小很多。另外在设计过程中如果有一些疑问点，也可以找相关人进行确认，这样可以提高整体的设计效率。

正式的交互评审流程如下：

1）介绍产品背景

刚开始讲解时，需要简单说下这个产品成立的大环境，比如为什么要做，如何产生的，以及产品背景等。

2）说问题

我们总体的商业诉求是啥？本次我们解决了哪些用户痛点？我们的产品目标是什么？以及交互设计目标是什么？对以上问题进行讲解，告诉大家自己在开始做交互设计之前做了哪些准备工作。

3）如何解决的问题，讲设计过程

有数据分析的可以先说，作为一个前奏，没有的也不要紧。

这个时候可以对整个交互文档，从头到尾讲解。对一些关键点的原型设计探讨可以详细聊聊，为什么要这样设计，之前推导的过程可以说下，或者说下比稿，多个方案的选择等。

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

六、设计落地

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

1. 设计推进

这个时候下游的伙伴们都开始按计划开工了，这个过程中，需要解答UI、开发、测试的业务疑问，作为产品的业务顾问，这个工作应该是有很多的，当被问住的时候，我们也可以翻阅交互文档去理清思路。UI拿到交互文档后也会开始进行UI设计，交互设计师则需要把控下UI的输出物，并协助UI设计师进行UI评审。

UI最终的效果如果不好，是会影响产品的体验感的，所以交互设计需要去把控这些细节。作为产品需求的执行者，在测试阶段，除了要把控交互测试，保证交互文档中的细节都能完美实现；同时也要把控好需求测试，保证产品实现效果是符合需求设计的。

2. 可用性测试

测试工程师把功能测稳定后，交互设计师需要主导可用性测试过程，关于可用性测试，我个人有一些看法。可用性测试就是在产品功能稳定后，找一部分真实用户在测试环境走完核心的用户任务流程，以此验证投入产出比，解决产品易用的问题。用户测试前，可以设定一些指标，比如完成率和完成时间，即多少用户可以走完流程以及走完流程的用户一共花了多少时间。

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

产品是否解决了用户的业务痛点，是否是自己想用的产品，可以理解为是否可用。
体验流程过程中，用户的操作和系统反馈是否顺畅，不进行培训用户上手的难度如何以及培训后用户操作的流畅性如何等，可以理解为是否易用，同时也可以提前知道后期培训用户的成本会有多大。
产品的视觉美观度如何，部分用户可能会提一些好不好看的问题。
产品的品牌传播效果如何，通过以上的结果，可以自己挖掘到该产品以后去推广时，品牌传播效应如何。

3. 漏斗分析

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

关于数据分析，我们会经常用到漏斗指标。针对用户的任务流程展开，可以选择核心流程，看每一步的用户损耗比。比如第一步时用户数是1万，到了第二步是8000，最终走完流程的只有100人，这时转化率就只有1%，损耗了99%。流程中损耗很大的步骤，也可以作为用户体验提升的分析点。漏斗分析另外也可以作为A/B测试的数据凭证。