SaaS 产品设计的原则

老于 2023-07-22 04:59:38

01

我们先看看看产品需求阶段的原则。

原则一：产品需求阶段首先要考虑到产品使用场景，满足用户需求

B端产品基本上是将「线下已有需求」系统化，回归场景是一切的基础。「不以用户场景为基础的设计都是耍流氓」，深以为然，产品经理在设计原型时，要考虑的重要因素之一就是「用户场景」，甚至在拿到一个需求的第一时间，就需要在脑海中思考用户在不同场景下的需求能否被满足，该如何满足，以此来进行需求的初步筛选，「场景思维」的重要性可见一斑。

现在我们部门沟通交流的过程中，除「需求」外，高频出现的另一个词就是「场景」了，在平时工作中，产品与研发伙伴对接需求时，也常常会被抓耳挠腮的研发大哥问到：你这个需求的场景是什么？

对「场景」这个词来做解释的话，其实就是什么「人」在什么「时候」在什么「地方」出于什么「目的」做了「什么事」。场景是设计和验证原型时最重要的依据，也是减少产品和开发矛盾的润滑剂。

我们来想象一个画面，一个上班快迟到的人在到达公司的时候打卡，这时候他一定不希望迟到，打卡操作越简单越好。这个画面就是场景，也是在设计产品或验证产品可用性时的重要参考依据，从整个产品宏观来讲是这样，具体到单个的页面也是这样。

SaaS 产品设计的原则

再来看看「完美工事」这款打卡的app，验证这个产品设计就可以得到比较符合这个场景，打开程序直接就是打卡页面，用户操作非常简单。

原则二：好的产品满足用户价值并带来商业价值

你首先要知道你的用户是谁，如果你不知道用户是谁，就好像你是一个篮球运动员，你不知道篮筐在哪，你不知道要面向谁去做你的产品。

然后再思考能给用户创造了什么价值。B端软件思考用户价值的时候一定要从两方面考虑，首先是给企业带来什么价值，比如提高效率，降低成本等等，还要考虑为决策人带来什么价值，比如是否能提升 KPI、话语权或者掌控力。

大家常说的用户体验并不是用户价值，提升用户体验固然好，但是B端软件核心是解决问题，是否能创造用户价值，只有这样才能带来商业价值。

商业价值的判断，第一个是盈利，第二个是持续的盈利，第三个是持续的更多的盈利，所以产品模式必须是持续正向增长的，需求理解->解决方案->客户成功->客户数量增长形成正循环。

02

产品设计阶段有以下几个原则：

1. 功能需要满足所有角色核心场景下的需求

SaaS 产品要确保业务链路每个角色的核心场景都能跑通，如果有一个角色无法正常使用，那该功能就不算完整，会导致整个链路上的每个角色都没法正常使用。

以「完美访客」小程序举例，来访用户可以扫码登记，管理员可以生成访客码，还可以添加子管理员协助来访统计分析。麻雀虽小，五脏俱全，虽然是一个简单的程序，但是能满足所有角色的使用。

SaaS 产品设计的原则

2. 每个客户都应该都独立、个性化的

传统软件流程是把软件卖给客户，客户自己要出钱部署，买服务器存储，搭建网络环境，还要用运维的人员。而 SaaS 软件现这些都不用了，硬件由供应商自己出，放在公有云上，以服务的方式租给客户，所以叫卖服务。SaaS 本质上是由卖软件改成卖服务，帮助用户降低成本。

但是客户的使用的方式还应该是一样的，每个客户之间不应该有交集，还要适当的满足企业个性化配置，对于大客户可能还需要定制化开发。不过尽量的降低定制化开发比例，如何降低定制开发的比例，我认为还是取决于产品对行业的理解深度，产品本身的成熟度。

「完美工事」从开始就设立了微服务的软件架构，把企业的个性化需求在微服务上实现，内部多用API的方式互通，不影响主产品的升级迭代。给一个企业做的定制化的功能，有时候还能同时提供给其他企业使用。

3. 低耦合，高内聚

低耦合：指产品结构内不同模块间的联系弱，关系简单。修改一个模块不会影响到另一个模块。

高内聚：指产品结构中单个模块内各个元素联系紧密。简单来说，就是一个模块内的代码只完成一个任务，即单一责任原则。

低耦合，高内聚会给产品带来什么好处呢？

从短期来看，并不会给产品带来明显的好处，甚至会使开发周期变得更长。但随着产品迭代，你会遇到更多复杂的需求。如果产品耦合度高，则牵一发而动全身，轻易不能改动功能，因为会牵涉到产品架构层面的问题。

Saas是把卖软件变为卖服务，放弃一次性收入，按照客户是否使用来收费，就必须把软件产品真正做到客户喜欢，持续满足绝大数客户需求，SaaS 产品结构及呈现方式必须可延续、可扩展。而低耦合，高内聚会给产品带来更好的扩展性，灵活性，复用性，可维护性。建议在产品开始设计时考虑好产品未来的长期规划，避免后期产品难以迭代，需要重构。多和架构师沟通，防患于未然的同时，留给未来更多可能。

4. 权限控制尽量细致

SaaS的产品业务相对复杂，面对的企业客户规模和业务方向都不同，权限诉求也不一样，根据不同公司业务权限设计需要设计的尽量细致。

处理权限是一个比较麻烦的事，设计阶段如果没有考虑好后期再改成本是非常大的。一个账号在一个系统可能对应多个角色，部分产品可能还涉及到不同地区不同分公司。那么根据业务需要在角色定义层或权限分配层，先确定好集团、地区属性，再确定数据权限、菜单权限、功能权限等等。

权限控制方面可以参考一下RABC模型：基于角色的访问控制。

RABC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。模型认为权限控制的过程可以抽象概括为：判断Who是否可以对What进行How的访问操作，即将权限问题转换为Who、What、How的问题。Who、What、How构成了访问权限三元组，Who，What，How分别对应着用户，资源，操作。RABC的核心在于通过为用户分配对应的角色进而将用户与对应的操作联系起来，已实现用户对资源的操作。

5. 产品要保持一致性，拒绝设置专业门槛

一致性包括视觉一致性、交互一致性、文案一致性、跨平台一致性。

对用户来说，一致性可以降低用户学习成本，用户在不同页面之间不会感到陌生，提升用户体验，更容易展现独特的品牌感、品质感。对团队来讲，利用一套风格统一的视觉、交互组件能提升设计作品的一致性，团队之间沟通对接也会更有效率，不会出现风格不统一的情况。

不要设置一些专业门槛，以文案举例，之前看到过我们开发的产品有一处提示信息「企业id不能为null」，虽然开发能看懂，但是我相信很多用户都会不理解，这句话可以改成「企业不能为空」或者「需要加入企业」等等。类似的专业文案有很多，比如 PV 改成浏览量，UV改成用户访问量等等。

6. 按照优先级顺序去迭代

无论在哪家公司，我相信技术资源都是非常紧张的，所以在进行需求排期时的沟通就非常重要了，可以按照下面的优先级去迭代。

我们先保证有稳定的功能，满足所有角色使用，如果功能不能正常用了，其他任何都是扯淡；
是否有竞品打动决策者的功能，能让客户转用另一家产品的功能必然是好功能，就是很好的买单功能；
跟客户收入直接挂钩，客户能用来增加营收、缩减成本的功能。哪怕别的地方做的一般，能给客户省钱，客户也是接受的；
是否提升软件使用者的工作效率，用户每天都在频繁使用的产品功能，需要能高效操作，能少一步操作是一步；
是否易用，易用指的是别让我思考，我看一眼就知道该怎么操作，这一点利于商务对使用人培训。这一点有时候不太好评判，开发难度可能也比较大，优先级排在后面了；
最后是好看，当你做了前面所有的，如果有资源，尽量让页面好看，而不是一味追求好看。

03

产品研发阶段也需要注意几点原则。

（1）首先保证系统的稳定性新，增或定制功能，要最大程度避免系统改造和重构，能够稳定迭代

对SaaS服务商来说，系统稳定性的保障一直是一个非常复杂的命题。通常情况下，业界比较优秀的服务商，系统稳定性一般能做到99.9%，相当于全年无休。系统不稳定对品牌口碑影响很大，还会直接带来经济损失。比如某盟就2020年2月23日出现删库事件导致系统几乎瘫痪，数据到月底才逐步恢复，对客户造成了很大的损失，对公司也造成了很大的影响。

这里的关键是业务和技术层面，需要产品和技术共同努力。产品经理要有对业务逻辑的深入理解和未来业务的预判性，并且对业务产品的各个维度组成有抽象化能力。

可以从用户维度、商业维度、需求场景、功能服务维度多去考虑；用户上把 SaaS系统的几类角色好好分析下，商业上把付费模式、增值模块好好构思下，凡事多想一步，让团队各成员心里有数，落地执行时多做少做心里也有底，在把产品方案传递给技术研发时，整体架构上也便于预留扩展，做到系统的耦合或内聚的决策更加精确，业务模块的复用性更好。

（2）技术架构上要考虑服务化、分层化、可配置化、自动化。还要要考虑架构高可用性、伸缩性、可维护性等。