“稻谷”——产品背景

企业级知识管理系统“稻谷/DocGood”是面向组织内部（B 端用户）知识沉淀与员工能力成长的轻量化知识社区 SaaS 平台，为 B 端用户提供知识积累与传播互动的学习型社区，解决组织发展过程中知识体系分散难输出、知识协同低效难赋能的管理痛点。

“稻谷”按产品规划分为 3 个阶段：

1. 多维度文件存储与内容转化，为组织建立既安全又灵活的线上知识仓库；

2. 用知识地图将分散的 knowledge points 组织成有序的知识链路，“一学就会、一点即通”；

3. 打造企业知识社区，在知识的互动与分享中为组织赋能。

当前正处在第 2 个产品规划期内，为提升系统使用时长和周活跃度指标，尝试在个别模块内部增加一些互动行为，同时为第 3 个规划期的产品方向做铺垫。

产品文档 —— 知识互动子模块

由曾烧麦创建，最后修改于:2021/03/11

文档修改历史

需求背景

在“知识地图”模块上线后，客服连续受到用户反馈，在使用知识地图的过程中会遇到一些专业性强且生僻的知识点或内容片段，希望能得到内容创作者的进一步解释和说明，同时帮助更多人学习和掌握；同样也有一部分内容创作者也向客服反馈，有用户会通过“稻谷”的站内私信向自己就某一知识点寻求解惑，有时同样的问题会向多人重复解答，不仅浪费了宝贵的工作时间，而且以站内私信方式来传播知识的效率太低。

产品目标

以真实的用户需求为输入，结合当前产品规划期内的价值目标和方向，可以判断当前正是在“稻谷”产品中引入知识互动的好契机；在“知识地图”模块内增加“知识互动”的相关功能就是既能迎合用户需求又能带动用户活跃度指标的好方法。

• 产品价值

• 为用户提供相对轻松的知识话题交流场景，作为与专业知识地图配套的知识服务体系，降低普通用户对于知识地图的消费门槛。

• 产品指标（上线 1 个月后）

• 新创建的知识地图中话题比例不少于 1:1，即 1 个知识地图有 1 个知识话题，上线前创建的知识地图中话题比列不少于 1:0.3，即 1 个知识地图内 0.3 个知识话题；

• 各租户总停留时长提升 10%，各租户的每周活跃用户数提升 5%。

术语解释

• 知识地图

• 可以理解为一个「知识专栏」。用户对某一知识领域内的知识点（概念）以图形化的方式进行绘制，系统基于图谱技术对图形链路上的知识点与租户内部存储的相关资料内容之间建立索引，形成既有概念又富含内容的学习路径；知识地图用来帮助用户快速掌握企业内部的知识结构和相关内容，提高员工培训的效率。

• 知识专家

• 知识地图的创建者即为此专栏的所有者，人人都可以将自己擅长的领域或专业绘制成知识地图，并长期维护迭代，成为某一领域内的「知识专家」。

• 订阅用户

• 对某个知识地图感兴趣并成功订阅此知识地图动态消息的用户，如果知识地图有绘制更新或发布新话题，订阅用户会收到站内推送消息。

• 普通学员

• 在知识地图中获取知识并参与互动的学员用户，人人都是知识学员，某一知识地图（专栏）的专家可以是其他知识地图（专栏）的学员。

• 知识话题

• 每个知识地图内部都可以发起相关领域的话题讨论，可以是专家分享，也可以是学员提问。

相关角色

• 话题发布人

• 创建和发布知识话题的用户 —— 只要具备知识地图的阅读权限就可以在此知识地图内创建和发布话题，可以是知识地图的作者「知识专家」，也可以是知识地图的订阅用户，还可以是普通进入此知识地图浏览学习的知识学员。

• 互动参与人

• 参与到话题中进行互动的用户——只要具备知识地图的阅读权限就可以在知识地图内的话题中参与互动，知识地图的专家、订阅用户、普通学员都可以话题参与人。

相关利益

• 用户方

• 知识专家在自己的知识地图领域内发布知识话题并分享专业经验，对用户提出的问题做出解答，能够对自己所维护的知识地图做进一步说明，有助于提升知识点的接受度和传播力，也能为专家收获一定的成就感。

• 订阅用户和普通学员在学习过程中就某些知识点向专家提问，或者参与其他知识话题的讨论，通过与专家和其他学员的交流能够收获浓厚的学习氛围，激发学习热情，避免一个人学习的枯燥与乏味。

• 产品方

• 促进客户续费留存。

界面图集

• P01.互动列表页
  

• 展示某个知识地图内的所有话题列表，进入话题详情/参与讨论的入口

• P02.创建话题页
  

• 创建一个话题或问题

• P03.话题互动详情页
  

• 展示话题的详细信息，参与话题讨论或点赞感谢

• P04.创建评论页
  

• 对话题内容发表评论，参与互动讨论

• P05.评论详情页
  

• 展示某个评论的内容及互动回复内容

• P06.创建回复页
  

• 对评论内容进行回复，参与互动讨论

知识互动-界面架构图

原型演示

请戳这里原型演示

知识互动-页面流向

业务流程

知识互动-业务流程图

概念模型

知识互动-概念模型图

用例图

知识互动-用例图

用例

UC01.话题发布人创建「话题」

UC02.互动参与人评论「话题」

UC03.互动参与人点赞「话题」

UC04.互动参与人回复「评论」

UC05.互动参与人点赞「评论」

非功能需求

• 性能需求

• 响应时间：页面跳转时间≤2 秒

• 超时概率 ≤ 0.1%

• 出错概率 ≤ 0.05%

• JVM 内存使用率 ≤ 80%

• 可用性

• 7x24 小时不间断服务

• 安全需求

• 数据传输加密

• 数据合法性验证

• 用户权限越界验证

• 防跨站点脚本攻击（XSS）

• 防跨站点请求伪造（CSRF）

• 防 SQL 注入

研发评估

• 研发工作量：评估需 16 个开发工日

• RN 前端 10 工日

• JAVA 后端 6 工日

• 研发周期：10 个工作日

• 编码开发 8 工作日

• 测试回归 2 工作日

• 研发资源：前后端各 1 人（中级）

风险

• 产品对于话题内容仅作基础合规性检查，没有对内容本身的质量审核把关，再加上产品设计的原则是用户在某个知识专栏内自由发布话题互动，话题一旦发布除非自己主动删除，否则很难监管。低质量的互动话题内容极有可能对「专栏创建人」造成困扰或伤害，肯定会对产品目标（提升用户的学习效率和活跃度）起到反作用。

• 预计解决方案 1：授予「知识专家」对专栏内所有互动话题的「删除」权限，由「专栏创建人」来维护小社群内部的知识内容质量。这个方案提升了「知识专家」的时间和精力成本，还需要考虑被删除话题用户的情绪和心态；

• 预计解决方案 2：提供内容「举报系统」，任意用户发现低质量内容时都可以向「内容审核用户」举报，由「内容审核用户」来判定内容是否需要删除。这个方案需要在产品中引入新的「角色」，这样做肯定会提升 B 端客户的应用难度（设置虚拟的专职人员），同时增加了用户在知识互动过程中的参与压力。

• 产品希望通过知识互动来提升用户活跃度，在用户「评论」「回复」「点赞」行为产生时设计了推送消息的系统提醒机制，在上线初期会帮助用户快速上手并理解产品逻辑，但随着互动频率提升相应的消息也会增多，用户会逐渐感受到阅读和处理消息的压力，直到难以承受放弃使用，“通过系统消息的方式提升用户互动频次”的产品设计理念就完全没有意义了。

• 预计解决方案 1：站在消息接收方的立场思考，因用户的多样性差异，应该让用户自己决定希望接受的信息源，可以通过「消息订阅」的模式让用户管理自己的消息来源渠道

• 预计解决方案 2：站在消息推送方的立场思考，自己的某个互动行为是否需要必须马上就传达对方，也应该由用户自己决定，可以通过在触发互动行为后让用户选择“是否需要发送消息通知对方”来指引用户的行为路径，而非系统强制；但这个设计思路又与在互动内容中 @行为有一定的业务冲突，还需要进一步的思考完善