对于模块的功能进行一层一层框架化的搭建

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

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

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

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

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

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

01 为什么要做功能框架

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

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

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

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

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

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

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

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

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

2. 容易产生功能遗漏

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

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

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

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

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

直接设计功能：

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

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

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

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

先设计功能框架：

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

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

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

可参见以下范例：

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

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

02 怎么设计功能框架

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

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

1. 业务类

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

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

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

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

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

以下用CRM模块来举例：

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