做新模块前，为什么要先做“功能框架设计”？

前言

3年以上工作的产品经理，在日常工作中，一定遇到过这样的两种情况：

• 基于公司现有情况，要在当前已经在使用的产品中添加一个新的模块；
• 将现有产品中多个功能独立成一个单独模块。

这个时候，产品小伙伴通常有两种解决方式：

• 一种是直接开始画原型；
• 另一种是先设计一个功能框架，然后再来做原型设计。

这两种方式看上去似乎都是同一个结果，但实际上，结果却截然不同。

今天我们就来聊聊，为什么要做模块的功能框架以及怎么设计功能框架。

01 为什么要做功能框架

功能框架，就是我们对于模块的功能进行一层一层框架化的搭建。下面我们先来说一说不搭建功能框架的风险。

1. 功能分布零散，关联性和衔接性差

相信很多小伙伴在工作中都经历过这样一个情况，产品设计的时候考虑了各种细节，觉得这个产品上线肯定是既有效又好用。

到了真正上线使用了，每个细节上确实是非常完美，可连起来使用的时候，往往总觉得有些别扭。

我们来想想以下这种场景：假如微信的聊天功能和朋友圈功能是完全独立、无法相互跳转的，这样会有什么样的结果呢？

当我们在朋友圈看到一个好友说自己做了一道美味的菜品，这道菜恰好自己总是做不好，想要去跟他聊一聊这道菜做法的时候。

我们需要退出朋友圈，在底部导航栏点到“微信”页面，再点开搜索，去搜索这个朋友的昵称，找到这个朋友再去聊天……

这样的路径是不是非常长？这就是我们不设计功能框架时最容易出现的问题，即将每个功能分布得太过零散，功能与功能间的关联性和衔接性会做得比较差。

这样就会间接导致功能上线之后，每个单独的功能都很好用，可是连接到一起则非常难用。

2. 容易产生功能遗漏

不提前设计功能框架的第二个问题，则体现在功能遗漏上。

我们拿到新的模块就开始吭哧吭哧设计具体功能，难免会出现思维的局限性。

即我们经常围绕自己想到的那个点来进行设计，也通常只围绕这些点来进行发散。

这样就会使我们局限在细节的问题上，而无法从整体考虑模块所应该安排的功能，从而产生功能的遗漏。

我们用设计一个CRM模块来试想一下这两种方式的差别：

直接设计功能：

这种情况下，我们会先想到CRM是一个客户管理系统，所以我们会填充客户信息管理功能。

发散一点，我们会想到客户签约有一个跟进过程，所以会设计客户维护功能。

再往外发散一点，我们可能会想到客户签约前的线索功能、商机功能、报表功能等。

但是除此之外，我们很难通过这个点就发散到相应的配置功能、活动运营功能等。

先设计功能框架：

这种情况下，我们会先通盘考虑一个功能框架会涉及到几类的功能。例如“业务类、数据类、运营类、配置类”等。

有了这个大的层级，我们再慢慢往下进行拆分：

• 业务类涵盖客户信息管理、维护管理等。
• 数据类涵盖客户报表，销售人员业绩情况报表等。
• 运营类涵盖活动管理等。
• 配置类涵盖业务的配置、通知配置等。

可参见以下范例：

从上面两种方式的对比可以看出，先设计功能框架能够站在一个更广阔的层面来进行思考。

从而拓展我们的思维，让我们不至于在设计具体功能的时候出现功能的遗漏。

02 怎么设计功能框架

设计功能框架最重要的要点，是将模块下的功能按性质进行拆分和整合，将相似度高或关联度高的功能放在同一个类目下；将相似度低或关联度低的功能拆分开来，以方便后续进行拓展。

设计框架时，一般可以将模块的功能拆分成以下几类：

1. 业务类

业务类功能是整个模块需要达成的核心需求。即围绕模块主题所做的一系列功能。

例如CRM模块中，围绕客户关系产生的客户信息管理功能、客户维护功能、商机功能等。

通过业务类功能，我们可以将业务的全过程放到线上来进行管理，让我们后续的管理、查询和分析更为精准方便。

因此该类型功能的设计会跟模块本身属性比较相关，不同的功能模块拆分都比较不一样。

但是根本原则就是只在该分类下放置业务相关的功能，且各功能间尽量独立，可以相互引用，但是不要在一个功能中实现太多用途。

以下用CRM模块来举例：

CRM模块：CRM模块的业务类功能可以拆分为客户信息管理、客户维护管理、线索管理、商机管理等。

我们从案例出发来想一想，CRM中的客户信息管理和客户维护管理这两个功能，看上去似乎关联非常紧密，但其实只会在某些场景中，这两个功能才会关联较为紧密。

例如：新找到一个客户，一次性要填好客户的信息和本次的维护记录。这个时候这两个功能关联比较紧密。但其实在更多的场景中，这两块功能提供的服务区别是很大的。

例如客户信息可以拓展延伸到客服模块，以便于客服跟客户沟通的时候能够更好贴近客户的情况。

而客户维护功能则可以拓展到客户签约路径功能中，用以分析客户是如何跟我们签约的，经过了哪些必要步骤，如何缩短客户的签约路径等。

由此可以看出，业务类的功能一定要考虑每个功能的本质和可能的拓展方向，将不同性质的功能独立分开是非常重要的。

2. 数据类

数据类功能主要是模块相关的数据，通常以报表或图表的形式展现。包含业务类功能直接产生的数据，以及衍生数据。例如业务量趋势图等。

数据类的功能一般分为对外和对内的两块：

• 对外的数据主要是用来指导现有业务增长，和及时解决业务出现的问题。
• 对内的数据更多是为了提升内部工作效率，达成降本增效的作用。

数据类功能：数据类功能可以从对外和对内的报表来进行区分，一层层拆解下去。

在数据类的功能中，需要注意的就是根据功能所起到的作用，将对外的数据和对内的数据区分开来。

对于这两块数据本身没有特别需要区分的内容，仅需针对后续分析便利来进行拆分即可。

3. 运营类

运营类功能主要是我们通过各种运营的方式来影响用户决策的功能。

例如淘宝的优惠券功能等。这类功能可包含B端和C端两类，具体根据公司业务决定。

我们可以通过使用这类功能，来促使用户完成我们想要的行为，并以此来提升公司业绩。

运营类功能：运营类功能通常根据功能的作用来进行区分，例如常见的运营类功能有活动管理、广告位管理、消息管理等功能。

根据功能的作用来拆分运营类功能够适应的场景比较广泛。以淘宝为例：

• 活动管理主要是管理平台发起的活动，包含对商户发起的活动和对购买用户发起的活动。
• 广告位管理主要是针对于平台的广告进行维护管理，包含常见的开屏广告，banner，信息流广告等.
• 消息管理则更多包含平台想要用户知晓的通知内容，也会包含商户和购买用户的两方面内容。

由此我们可以看出，在运营类的功能上，需要以功能作用来进行拆分。

这样也便于我们做功能间的关联和衔接，可以将同一个功能跟不同的功能进行关联，使用在更多场景中。

4. 配置类

配置类功能主要是以上3类功能的辅助型功能，例如消息通知配置等。

这类功能主要是为了使系统的灵活性增加，避免每次参数调整都要经过开发修改代码，更快速地响应可以让我们更容易抓住市场机会和更快速消解用户的不满情绪。

以短信通知配置举例：例如在电商中，我们一开始配置短信通知的时候，配置的是用户每领到一张优惠券则会发送一条短信通知。

在用户使用过程中我们会发现，这样发短信的频次太高，让用户产生厌烦情绪，这个时候我们就可以通过配置功能马上调整，将用户的短信通知频次改为1天1次或1星期1次。由此来快速响应市场反馈。

配置类功能：配置类功能包含很多，跟运营类功能相似，配置类的功能也需要根据作用进行划分。

常见的功能包括消息通知配置、功能配置、业务配置等。

配置类功能的拆分原则跟运营类功能比较相似，就不在此过多赘述。

03 总结

通过今天的文章，我们可以知道在做一个新模块或是将多个已有的功能整合成一个模块时，一定要先设计模块的功能框架，再来动手设计具体功能。

这样能让我们设计的模块中，功能与功能的关联性与衔接性更强，且可以避免功能遗漏。

功能框架的设计通常将同类型或关联性强的功能放在一起。

做功能框架前，我们要根据模块的功能性质区分成4个类型，业务类、数据类、运营类、配置类。

这4个类型有各自的不同点：

• 业务类功能贴合模块的业务性质最紧，所以不同的模块业务类功能都不同；业务类功能切记要考虑每个功能的本质和未来的拓展性，将功能尽可能拆分得更细。
• 数据类功能一般是以报表或图表类型展现，包含对内和对外的所有数据。
• 运营类功能和配置类功能则一般是以功能的作用进行划分。以便于能更好地跟其他功能关联，复用到更多场景中。

做新模块前一定要做功能框架，你get到了么？

作者：蜂蜜乌龙茶；微信公众号：产品旅程

本文作者 @蜂蜜乌龙茶

版权声明

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