SaaS 全称是 Software as a service，软件即服务 ，当用户需要这个产品时，可以在 *** 环境下随时租用，而不需要承担更多的开发成本和人力成本等。这就是初期 SaaS 产品带给用户的工具属性的价值。

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

01

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

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

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

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

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

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

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

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

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

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

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

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

02

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

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

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

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

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

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

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

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

3. 低耦合，高内聚

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

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

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