最近，当我和朋友做另一个项目时，沟通需求的过程中，对需求文档结构进行了深入的讨论。在几轮讨论中，我发现我写了一篇相关的文章——MDVC框架：产品文档最优雅的结构——产品文档相关框架的不足和漏洞，因此，补充一篇，特此纠正。

在前一版中（1.0）讲述的 MDVC 模型主要涉及:模型:（Model）——数据（Data）——视图（View）——交互（Controller）等内容，框架版本升级（2.0）还包括对 1.0 版本中的内容不仅调整了产品需求文档内容的结构，还增加了背景（Backstage）以及后端（Back-End）部分逻辑；此外，还涉及到描述文档内容的逻辑。

本文主要由以下部分组成：

   MDVC 框架不足PLUB 框架介绍

让我们开始吧！

就像任何框架或理论早期都有一定的局限性和不足一样，MDVC 框架无法避免，仍存在一定的不足和局限性。当然，这也是我对自己阶段性认知的总结，也证明了我一年前提出的 MDVC 框架显示了他们自己的缺点。我也希望在这次调整中，我希望能激励你，同时整理我自己的想法。

MDVC 框架的适用范围问题

核心问题：太窄。

MDVC 框架结构易于与开发沟通，但不利于与设计师和其他相关人员沟通。考虑到工作范围，不适合第一次接触项目和产品文件的人。例如，外包团队的设计师、开发人员、产品经理等。MDVC 框架不能让非相关人员在短期内，较快的了解项目和产品。

举个例子，MDVC 框架只从功能的角度介绍产品逻辑，但不从界面数量介绍项目和产品。与外包设计甚至内部设计师沟通时，这部分工作会带来一些不必要的沟通成本；例如，外包设计师不知道界面的数量和界面中的相应状态。优秀的外包设计和内部设计师可以帮助您梳理，但糟糕的设计师，特别是外包设计，基本上是根据页面的数量收费的。可以想象，不详细的界面数量和相应界面的提示状态会导致一定的时间成本和资本成本的消耗。

再举户端开发和后端开发为例，MDVC 框架介绍项目和产品需求分散，不从功能的角度出发。在满足客户端开发需求的基础上，也考虑了后端开发和背景需求，导致功能需要与客户端和后端沟通。

MDVC 框架的逻辑条理

核心问题:混乱，不清楚。

在适用范围的基础上，逻辑组织问题得到了延伸。由于一个项目和相应的产品需求，在大多数情况下，每个界面或多或少都会交叉。由于交叉，对文档的逻辑要求相对较高。MDVC 框架没有很好地解决这个问题。一个功能的某些逻辑甚至所有逻辑都会在文档中重复。这个问题不仅给产品经理带来了很多问题，也给项目和产品的相关人员带来了不必要的麻烦。

逻辑混乱和不清楚的另一个表现是产品文档结构。对相关人员来说，理解和掌握需求也非常重要。MDVC 框架中产品需求的结构是采用模型-数据-视图-这种交互方式灵活性差，在实际应用中需要在各个环节之间有更多的跳跃。这样，就很难连续阅读和理解产品需求，有时也会出现错误。

MDVC 框架的维护成本

核心问题：维护难度大。

结合以上两个问题，我发现 MDVC 框架在当前和未来的维护需求和文档中存在很大的隐患。一方面，由于框架的适用范围和框架的逻辑组织，后期维护人员需要花更多的时间了解项目和需求；另一方面，在跨部门（公司）合作过程中，沟通成本也很高。

基于以上 MDVC 框架存在的问题，我调整了框架，提出了 PLUB 框架。

P = Page

解决 MDVC 框架中界面（页面）的数量，方便相关人员从整体情况中了解整个项目。同时，设计师可以开发和了解设计界面和界面中相应的所有状态，并评估相应的工作量。此外，需要提到的是，由于界面的独特性，在规划过程中不会或尽可能减少界面中相同或相似逻辑的存在，可以减少工作中的交叉逻辑。

L = Logic

解决 MDVC 框架中的结构关系，并添加集中的逻辑关系描述。介绍界面和界面之间的逻辑关系，包括核心和非核心逻辑关系。

       核心关系包括：登录/未登录状态下各界面对应状态；各界面各状态的触发逻辑；当达到/未满足相关条件时，相应的处理方法；是否需要后端/后台配置；是否需要通过后端/后台控制显示（云控制）等。非核心逻辑关系包括：界面中UI，是否需要通过后端/后台配置某些元素，如需要频繁更换的 Tab icon 及名称；点击界面中的跳转关系(交互)；点击界面 icon 相关的交互展示；等等。

U = UI&UE

这部分不需要像 MDVC 同样，需要在逻辑部分的核心和非核心逻辑中介绍单独的结构。单独提出，希望考虑根据逻辑部分的调整，在编写产品需求文档时随时调整规划 UI/UE调整 。

B = Back-End&Backstage

MDVC 框架中只简要提到了数据源，但不深入；同时也影响了对文档相关项目和产品的阅读和理解。

在 PLUB 框架中，B 部分也集成在逻辑结构中。当介绍界面中的某个功能时，可以从头到尾全面介绍该功能。后台和后端部分包括协议（接口）和后台产品的规划逻辑。

在 PLUB 框架结构文档的开头，可以适当增加版本和界面逻辑关系图，这样无论是对项目和产品的初步了解，甚至是跨部门(公司)的合作，都会为你节省一定的成本-时间和资金。当然也会让你和合作伙伴收获无形资产，建立良好的合作关系。

接下来，我适用 PLUB 框架，给大家举个例子:

实例介绍

产品钱包界面及相关逻辑。

进入钱包界面时，检查用户是否登录：

1、个人信息区

   显示未登录的用户logo并提示引导用户登录，提示文案第一次登录发送红包，最高 200元哦！；未登录，点击个人信息区域，从下到上推出登录界面；登录界面见界面20；登录状态显示默认头像和用户昵称，昵称处理为手机号码第一4-7如：132****4147；登录状态下，点击个人信息区无跳转界面

2、现金、金币、徒弟区

   未登录状态下的相应数据表示0.00、0、0；点击现金、金币和学徒的任何位置，从下到上推出登录界面；（界面20）显示当前用户现金、金币和学徒数量；点击现金区域，跳转到收支明细现金界面；（界面9）点击金币区域，跳转到收支明细金币界面；（界面9）点击学徒区域，跳转到我的学徒界面（界面13）

3、签到打卡

   未登录状态显示连续登录红包，显示每次登录应获得的金币金额；登录按钮处于亮点状态；未登录状态点击登录按钮，从下到上推出登录界面；登录界面见界面20；登录状态显示最新的连续登录次数，显示您已连续登录 x 天空。登录状态未登录，登录按钮为登录状态，用户可点击登录按钮；登录状态已登录，登录按钮为登录状态。

每次登录完成后，如果是金币，提示用户在当前界面登录获得金币弹出窗口，与有效阅读信息奖励弹出窗口一致，并显示获得的金币奖励，3s然后消失；如果是红包，登录完成后，在当前界面提示登录红包弹出窗口，登录红包奖励弹出窗口，点击关闭，弹出窗口消失；点击赚取更多，跳转到主页（界面2）。用户点击登录，您已连续登录 x 1 天，签到进度也增加了一个。

奖励用户：

   每天获得一次奖励奖励；每天连续签到获得下一次奖励；非连续签到，不获得下一次奖励，从第一次开始计算；签到每7天循环一次；奖励类型和奖励金额可在后台配置。如果是金币，前端显示数量，如果是红包，前端显示红包图标。

(3)整点红包

当活动未打开时，按钮位置显示下次活动打开的倒计时，不点击；

当活动开始时，在有效时间内（有效时间为10分钟，后台可配置），按钮显示为抢红包状态，如果超过10分钟，则显示下一个倒计时。

   未登录时，点击抢红包按钮，从下到上推出登录界面；登录界面见界面20；登录时点击抢红包按钮，提示获得限时红包奖励弹出窗口。

红包时间、奖励类型和奖励金额(现金金额为一个范围，金币为10倍)可在后台配置。

   如果是金币，显示金币弹出窗口，3s然后消失；如果是红包，显示红包弹出窗口，点击关闭按钮，关闭弹出窗口；点击赚取更多，跳转到主页（界面2）。

奖励用户：

(1)晒收入奖励

   未登录，按钮状态为立即干燥，点击按钮，从下到上推出登录界面；（界面20）；已登录，如果用户当天收到奖励，按钮状态显示已收到，不能点击；如果用户当天未收到干燥收入奖励，按钮状态为立即干燥，点击按钮，跳转到干燥收入取金币界面；（界面11）；需要判断用户是否有效完成干燥收入，如果是金币、金币弹出窗口，3s消失，如果是现金，弹出窗口告诉用户，点击关闭，弹出窗口消失，点击赚取更多，跳转到主页界面2；干收入奖励类型和奖励金额，背景可以配置。

(2)额外阅读奖励

当天有效阅读信息或视频内容（奖励次数）次数达到后台配置次数时，给予用户奖励，后台可配置奖励类型和数量。

   未登录状态下，文案显示“今天累计阅读30次可领取xxx金币/xxx元，按钮状态为立即接收，点击按钮；从下到上推出登录界面；登录界面见界面20；登录状态，判断用户当天的阅读次数是否符合背景配置的要求： 如果没有，副本显示再次阅读xx第二，你可以得到奖励。来吧，按钮显示继续阅读； 点击按钮跳转到主页(界面2)。如果已经达到，文案显示恭喜你完成xx第二次阅读，立即获得奖励，按钮显示立即获得3s消失，如果是现金，弹出窗口告诉用户，点击关闭，弹出窗口消失，点击赚取更多，跳转到主页界面2。

注：界面 数字：表示在整个界面数量中的位置