本文以知识库系统的搭建为例,从需求出发,进行功能拆解、落地方案的分享,建立知识库型内容产品设计思路。

当没有线上知识库时,信息传递方式分散,内容混乱。
比如经常被采用的是邮件下发文件和群里资料共享的方式,这些常用的方式弊端主要体现在以下几点:
因此大模块可以按上述分析拆分为两个,由于在实际应用中针对不同的端都要采用知识库的能力;
因此我们抽象出公用的能力将知识库内容编辑发布做成底层公共服务,供给上层各个应用端。

分析应用层各端披露的内容。
先分析应用层需要具备展示哪些内容,再看底层服务需要支持哪些功能;应用层的使用可以参考同类产品。
微信广告-帮助中心


头条广告帮助中心


由此可见,应用层各端的能力主要体现在以下几方面:
明确了应用层需要的功能,接下来,我们需要考虑底层服务应该具备哪些能力?

明确有哪些核心阶段:内容编辑-内容审批-内容发布,上下游是否有相关流程的依赖。
比如内容编辑时,需要明确这个用户编辑内容的范围,因此在流程上,要先对用户、系统进行后台的统一管理,因此补充为“后台管理-内容编辑-内容审批-内容发布”;
再确认这些核心阶段具体是哪些业务中的角色在做,再将这些业务的角色抽象为系统角色;
暂定为系统管理员、内容编辑人员、内容审核人员、内容审核人员,在一期方案中可以将一些流程和角色进行简化。

将业务中具体的实体进行梳理,比如知识库这个案例中,实体有文章、标签、目录、用户、系统、审批流等,分析每个实体对应的属性,明确多个实体之间的关系。
这里要考虑后续业务的发展方向,落地方案的可扩展性。
比如之前接手的一个陈年老系统,用户都是以QQ号作为主键的,后来需要支持微信登录,所有的和用户相关的表都需要进行升级,工作量巨大;如果当时考虑用户用userid作为主键,QQ号仅作为一个属性,升级成本就会小很多。






明确了底层实现方案后,可以将具体功能模块化,并从业务优先级和实现依赖两个角度考虑产品的迭代节奏,一期建议只做基础的核心功能,小步快走,逐步迭代。
因此一期没有考虑审核模块,前期通过用户权限控制,只将文章发布限制在内部核心同学上,各应用端自行保障文章质量,在编辑方式上也仅支持了对前端展示比较友好的Markdown的编辑方式,而没有支持操作便捷却对前端兼容性要求较高的富文本编辑器。
产出具体原型图时,需要重点考虑页面逻辑和交互的细节,比如浏览页面是否需要加水印,水印展示哪些用户信息等。
涉及到B/C两端的产品,功能分析由C端到B端;
产品方案思考思路:
免责声明:本文版权归原作者所有,文章系作者个人观点不代表蜗牛派立场,如若转载请联系原作者;本站仅提供信息存储空间服务,内容仅为传递更多信息之目的,如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈!
]]>