SaaS 产品设计的原则

SaaS 全称是 Software as a service，软件是服务 。当用户需要该产品时，他们可以在网络环境中随时租用，而无需承担更多的开发成本和劳动力成本。这是早期的 SaaS 产品给用户带来的工具属性的价值。

有原则的人更容易被信任；产品有原则，更容易减少部门内耗，超越情绪和环境的影响，自觉选择最佳方案。让我们看看 SaaS 软件设计原则。

1

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

原则，产品需求阶段首先要考虑产品使用场景，以满足用户的需求。

B端产品基本上是将「现有线下需求」系统化，回归场景是一切的基础。「不以用户场景为基础的设计都是耍流氓」，产品经理在设计原型时要考虑的重要因素之一是「用户场景」，即使在获得需求的第一时间，也也需要考虑用户在不同场景下的需求是否能够得到满足，以及如何满足需求，以便进行初步筛选，「场景思维」可见一斑。

现在在我们部门沟通的过程中，除了「需求」另外，高频出现的另一个词是「场景」在日常工作中，当产品与R&D合作伙伴对接需求时，R&D大哥经常会问:你需要什么场景？

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

让我们想象一张照片。一个工作迟到的人到达公司时会打卡。此时，他不想迟到。打卡操作越简单越好。这张照片是设计产品或验证产品可用性的场景和重要参考依据。从整个产品的宏观角度来看，具体到单个页面。

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

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

你必须首先知道你的用户是谁。如果你不知道用户是谁，就像你是篮球运动员一样。你不知道篮筐在哪里，你不知道谁想为你的产品做。

然后再思考能给用户创造了什么价值。B在考虑用户价值时，端软件必须从两个方面考虑，一是给企业带来什么价值，如提高效率、降低成本等，以及它是否能提高 KPI、话语权或控制力。

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

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

2

产品设计阶段有以下原则

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

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. 按优先顺序迭代

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

我们首先确保功能稳定，以满足所有角色的使用。如果功能不能正常使用，其他任何事情都是胡说八道；是否有竞争产品给决策者留下深刻印象的功能，可以让客户转向另一种产品的功能必须是一个好功能，是一个好的支付功能；与客户收入直接相关，客户可以用来增加收入，降低成本。即使其他地方一般，可以为客户省钱，客户也接受；是否提高软件用户的工作效率，用户每天频繁使用的产品功能，需要高效操作，可以少一步操作是一步；是否容易使用，容易使用意味着不要让我思考，我知道如何操作，这有利于业务培训用户。这有时不容易判断，开发可能相对困难，优先级在后面；最后是好看，当你做前面的一切，如果有资源，试着让页面好看，而不是盲目追求好看。

3

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

1 .首先，为了保证系统的新稳定性，增加或定制功能，我们应该最大限度地避免系统的改造和重构，并稳定迭代

对SaaS对于服务提供商来说，系统稳定性的保证一直是一个非常复杂的命题。通常，业内优秀的服务提供商可以实现系统稳定性99.9%，相当于一年四季无休止。系统不稳定对品牌口碑影响很大，会直接带来经济损失。比如2020年2月23日某联盟删库，系统几乎瘫痪，数据直到月底才逐渐恢复，给客户和公司造成了很大损失。

这里的关键是业务和技术水平，需要产品和技术的共同努力。产品经理应对业务逻辑有深入的了解和对未来业务的预测，并对业务产品的各个维度的组成有抽象的能力。可从用户维度、业务维度、需求场景、功能服务维度等方面考虑；用户将 SaaS在系统的几个角色的良好分析下，在商业上构思付费模式和增值模块，多想一步，让团队成员知道，多做少做。在将产品方案传递给技术研发时，整体架构也便于预留和扩展，使系统耦合或内聚的决策更加准确，业务模块的重用性更好。

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

高可用性意味着系统不依赖单点（服务器不会影响业务系统，数据库不会丢失数据，非法攻击可以很好地转移）；可伸缩性，良好的架构可以支持业务，用户可以简单地添加机器解决；可维护性，随着业务的增加、技术复杂性、系统自动运行维护、系统回滚、运行监控、日志系统完善、自动预警和恢复，而不是简单的堆维护。

4

最后，本文从需求、设计和开发三个阶段进行了阐述SaaS几个原则：多思考需求阶段，注意使用场景，满足用户价值和商业价值。设计阶段应考虑不同角色的场景和需求；注意客户之间的独立个性；产品功能模块应低耦合控制尽可能详细，产品一致，无专业门槛；优先迭代；研发阶段应与开发合作，确保系统的稳定性和可扩展性。

和大家分享一点经验，祝彼此成功。SaaS产品。欢迎关注，共同交流。