鹿鼎

首页|鹿鼎|首页(主管qq)SaaS的全称是软件即服务,软件即服务,当用户需要本产品时,可以在网络环境中随时租用,而不需要承担更多的开发成本和人工成本。这就是早期SaaS产品为用户带来的工具属性的价值。

有原则的人更容易被信任;产品有原则,更容易减少内部消耗,脱离情感和环境的影响,自觉选择最佳解决方案。让我们来看看SaaS软件设计的原则。

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

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

b端产品基本上系统化了“线下现有需求”,回归场景是一切的基础。“没有基于用户场景的设计是流氓”,深入思考,产品经理在原型的设计,要考虑的重要因素之一是“用户故事”,甚至在第一次需求,需要在你的头脑中认为能满足用户需求在不同的场景下,如何满足,初步筛选的需要,“场景思考”的重要性。

现在,在我们部门的沟通过程中,除了“需求”之外,经常出现的另一个词是“场景”。在日常工作中,当产品和研发合作伙伴满足需求时,我们经常被研发兄弟挠着头问:你们的需求是什么样子的?

“场景”一词的解释是“人”在“什么时间、什么地方、为了什么目的”做了什么。场景是设计和验证原型最重要的基础,也是减少产品和开发冲突的润滑剂。

让我们想象一下,一个将要迟到的人在到达办公室时打卡进来。他不想迟到。打卡越容易越好。在设计或验证一个产品时,无论是对于整个产品还是对于单个页面,这个屏幕都是场景和重要的参考。

SaaS 产品设计的原则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 高可用性即系统不依赖单点(一台服务器挂了不至于影响业务系统,一台数据库当了不至于数据丢失,被非法攻击了能很好地转移);
  • 伸缩性,好的架构在用户1万时你能支撑业务,用户突增至100万时能否简单加机器来解决等;
  • 可维护性,随着你业务的增加,技术复杂性增加,系统的自动化运维能否跟上,系统的发布回滚,运行时的监控、日志系统是否完善,自动预警和恢复,而不能简单堆人维护。

最后,本文从需求、设计和开发三个阶段总结了SaaS的原则:

在需求阶段,我们应该多思考,关注场景的使用,满足用户价值和业务价值;设计阶段应考虑不同角色的场景和需求;注意,客户是相互独立的;产品功能模块应低耦合、高内聚;权限控制尽量详细,产品保持一致性,没有专业门槛;按优先次序进行迭代;研发阶段要配合开发,保证系统的稳定性和可扩展性。

与您分享一些经验,祝您俩都是一个成功的SaaS产品。欢迎关注和共同交流。

发表评论

电子邮件地址不会被公开。 必填项已用*标注