从0到1的问答社区设计(2)-实体关系、全局说明和版本规划

实体关系图 当做的产品是从0到1时,为了让数据库的开发人员更快速的了解你的产品,实体关系图(E-R图)将会发挥很大作用,数据库的开发人员可以参考此图来做数据表结构的设计。
问答社区的实体关系主要涉及到用户、问题、回答、评论和访客。通过实体关系图可以看出他们之间的对应关系。
从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
问答社区实体关系图 此外,在实体关系图中还需要表现出各自的属性,即字段。


从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
回答-属性 从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
评论-属性 从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
问题-属性 从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
用户-属性 通过上面的E-R图,将会大大简化数据库的开发人员对设计的产品的理解时间和难度。
角色权限 涉及到角色和权限的,需要做一份全面的角色权限表格,方便开发人员参考。这是B端产品必须经历的一步,在C端产品中则异化为了用户的成长体系,如VIP的设计等。
在本次的问答社区设计中,在前期以MVP指导思想,并不涉及到角色权限问题。
这里举一个通用的例子
从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
角色权限图 业务流程图
通过业务流程图,可以在大方向上知道产品的整体逻辑,业务流程图拆解可以得到任务流程图,任务流程图拆解可以得到页面流程图。
因为问答社区设计的流畅简单,所以无需再用流程图说明业务,以免增加额外的无用工作量。这里举一个笔者之前设计的家居安装平台的业务流程图为例,给读者一个直观的展示。
从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
某家装平台业务流程图 全局说明 一些通用的控件、状态等,不需要每次都说明,比如空数据、网络异常、加载失败、刷新状态等等,只需说明一次即可。这里以空数据为例进行说明。
从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
全局声明 版本规划 版本规划是产品经理根据需求优先级和开发进度预估定出来的,即每个版本要做什么,重点是什么,研发时间,上线时间等。一般来说,项目每发布一个版本都应该有它的意义和主打功能。
结合实际情况,我的问答社区一共规划了三个大版本的更新迭代。运用思维导图可以很好的呈现思考的过程和版本规划的大致功能特点,是对外讲解时的重要工具。更详细的排期表则是在和研发人员沟通交流后敲定。更详细的说明则是在需求文档中体现。
第一个版本,主要实现问答社区的最基本功能,在APP端实现发布问题、回答问题、评论问题、点赞、收藏等基本操作,实现个人中心的信息管理,实现总后台的配置和信息管理。
从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
问答社区V0.10版本规划思维导图 第二个版本则是在第一个版本基础上增加了WEB端相关内容,嵌入知识库,连通更多数据,提高可用性和有效信息量,提升用户黏性。在APP端优化首页推荐算法,提高易用性。在总后台增加数据中心,通过埋点数据的分析,提高产品决策的准确性,也为第三版本的运营打下基础。
从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
问答社区V0.20版本规划思维导图 第三个版本侧重在运营层面,增加用户成长和激励体系。并且将问答社区向小程序和公众号移植,实现公司层面的微服务化。
从0到1的问答社区设计(2)-实体关系、全局说明和版本规划
文章图片
问答社区V0.30版本规划思维导图 在实际工作中,从0开始的版本规划只能保证未来产品的大方向不变,在实际进程中还需要不断优化改进完善,还有很多小版本的例如修改bug,优化用户体验等更新规划需要进行。




【从0到1的问答社区设计(2)-实体关系、全局说明和版本规划】PS:下一章节将开始实际的最重要部分,需求、功能和交互说明。

    推荐阅读