关于SaaS 产品功能设计，我的实践思考

在上篇文章《关于「产品架构设计」，我的实践思考》中，讲述了当时我们是如何做的架构设计。

但在实际工作中，我们更多的还是做功能设计。

如果说架构是骨，那么功能就是其中一块块的肌肉，而字段属于连接整体的经络，最后这个系统会像人一样运作起来。

在产品基础完善期（即生命周期的萌芽期）， SaaS 产品为了满足核心场景的需求，会不断的增加功能，满足对方的业务诉求。

如何高效完成 SaaS 产品的功能设计，这是我作为产品新人的主要工作，因此需要不断的积累经验，提高产品方案的质量。

接下来，我会与你分享关于 SaaS 产品功能设计的一些思路，希望对你有用。

01 这个问题，需要通过功能来解决吗？

我刚入行时，当面对一个业务问题的时候，首先想到的是我该用一个怎样的功能来解决它，流程是什么样的，以及原型该怎么画。

而实际上我提出的解决方案不仅解决不了本质问题，同时因为方案被无数次打回来，导致对自信心的打击很大，甚至那时候觉得自己不适合做产品。

那么，问题到底出在哪了？

经过这段的时间的沉淀，我发现之前自己「解决问题」的思路不对。

在分析问题时，应该「先定义，再发散，后收敛」。

而不是重复做「收敛」的动作，那样只会跟无头苍蝇一样乱撞。

因此我总结了一下，当面对一个问题时，应该先明确以下这几个点。

1. 确定问题与现状

最常见的方式就是提问，我们需要通过合理和高效的提问，围绕着问题去收集相关信息。

作为产品经理要时刻谨记一句话，对方说的往往只是解决方案，而非问题和现状。

意识到这一点，通常我会问这么几个问题搞清现状。

（1）你们遇到了什么困难？

要知道，当你用「困难」作为提问关键词时，对方的表达就不再是「我要怎么样」，而是会说「现在是怎样」。

因此以这个问题作为开头，对方会下意识回顾事情发生的始末，回答过程中也会连带出很多相关信息。

产品经理需要做的，就是基于对业务的理解，对流程、角色、利益关系等关键信息保持敏感，完成信息的初步采集。

（2）在系统上如何操作？

我们的目的，肯定是希望产品能够为对方提供完善的服务。

所以通过「问」和「看」对方在系统上的操作，不仅能确定问题在系统层面的不足，还能发现其他的一些操作问题。

（3）目前是如何解决的？

最常见的情况，就是系统还没有做相关的解决方案，也就是这部分业务问题在系统上是缺失的。

那么我们就需要做相关的业务调研，从功能的层面去解决这个问题。

2. 最简解决方案

我们都说做产品要做 MVP（最小可行性），其实做功能也是一样。

我们要以最简单的方式来解决对方的问题，方便日后的拓展，或是重做。

这里要切记「最简」不代表「缺失」，业务闭环是做 SaaS 产品基本逻辑。

（1）已有功能的优化

有的时候不是我们没有这个功能，而是这个功能对方不知道，或者是说用不起来。

作为产品经理，需要对当前系统已有功能非常的了解。

那么面对这种情况，可以选择先做系统层面的讲解，然后再去考虑如何优化。

（2）视觉或交互上的调整

这里的核心理念，还是用最小成本去解决对方的问题。

比如组织架构的树状展示方式，单击是选中，双击是折叠 / 收起操作，这就能解决他们查看对应层级人员的视觉干扰问题。

（3）利用通用功能（增删改查）来解决

这些功能既通用，认知成本又低，作为基础的解决方案正合适。

比如客户存在任务执行一半，要求不必再做的问题，我们需要先考虑「删除」这个功能能否解决问题，而不是上来就做一个「任务停用」的功能。

如果上面这些问题你都搞清楚、弄明白了，那么接下来就会进入到功能设计的阶段。

02 设计功能，满足客户的个性化需求

对于 SaaS 产品来说，客户的需求存在多样化，因此在设计功能时一定会考虑「可配置」。

这么做的目的，一是希望前端页面简洁高效、内容清晰，且能够满足不同客户的业务需求。二是对于后端的功能配置，能够做到归类清晰、不杂乱。

那么我们该如何去做呢？

首先我们需要判断，业务流程与现有方案差别的大小。

如果差别大，我们需要从系统层面来配置，比如线下教育行业的上课流程存在两种。

那么对于少数企业的情况，可以考虑在面对这些用户时，将系统逻辑后台写死。

但如果业务流程与现有方案差别小，那仅从功能层面进行配置即可，这种就很常见了。

然后就进入到具体的功能设计流程，主要分为 3 个步骤。

1. 找到对应模块

如果说每个模块是解决「一类业务问题」，那么每个功能就要对应解决「单个业务问题」。

例如我之前做的一家少儿编程机构的管理后台，主模块分为市场管理、销售管理、教师管理、教务管理等。

那么对于线索回海这个业务问题，肯定要在销售管理模块下做功能设计。

2. 判断是否做成可配置

先用一套四象限法则，介绍一套判断的方式。

上图来自网络

先说一下第二象限，对于 SaaS 产品来说，如果我们选择要满足企业的个性化需求，尤其是他们占比还比较小，那我们要重点考虑「商业价值」。

如果对方希望你能帮他解决，但不愿意付钱，那么就要提高警惕了，这个业务问题对企业来说不价值没那么大。

再说一下第四象限， 这里重点要从 SaaS 产品公司的 ROI（投入产出比）来分析，不能为了满足客户而忽略公司的生存。

最后就是第一象限和第四象限，这其实比较好理解，这里就不做过多赘述。

3. 设计它的默认设置项

这里需要产品经理能够从大量客户的个性化场景中，找到最核心的场景，并以此为依据将该选项作为功能的默认配置。

这样做的本质，是希望减少误操的可能性。

写在最后

当然，任何事物都存在两面性，实际中也不要将所有功能都作为「可配置」。

一来这样会降低系统的易用性。

要知道，客户要的不是你的可配置，而是能高效、简洁的完成自己的工作内容，而每个配置项意味着对方需要多一步思考。

过多的配置项不仅造成页面的不简洁，同时也会增加流程的步骤。

二来会带来极高的开发成本。

如果配置项中的另一种选择没有客户使用，这无疑也是在浪费开发资源。

而这个问题的起因，又回来到了产品经理对业务的理解能力不足，需要加强业务调研的能力。

以上就是我对 SaaS 产品功能的设计的理解，接下来就是希望你我在实践中，不断的理解与调整。

愿你我一起加油，共同成长~

作者：空；公众号：小木盒产品记

本文作者 @空

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！