APP建摸—一套描述app的方法论
引子一:
一个产品的生命周期中需要产出MRD(市场需求文档),然后根据市场需求文档画出产品原型图并输出PRD(产品需求文档)。在许多产品经理教程或者书籍里,大家肯定没少看到与需求、原型相关的论述,不过在工作实践中往往会感觉“从需求到原型”还是跳跃的,仅仅明确需求就去构造产品原型会不清晰,中间需要做很多的过渡工作,只是这些工作不像明确需求与建立原型那样被广泛提及,它们并没有一套明确的方法论。正是因为需求到原型存在“断层”,而之间的过渡体并没有被提出明确的概念,因此笔者将在此文中来论述如何在需求与原型之间搭建起一座桥梁,这个“桥梁”是如何工作的,从而顺畅产品原型的输出。
引子二:
一个极客用户(需要深度体验各类app的产品经理就算这类用户)需要来回翻转整个app来理解这个app的设计理念和机制,因为没有明确的方法论去告诉我们怎样去深度体验app,很多时候大家会感到迷茫和低效。这是因为我们往往抓其一隅,陷在细节里不可自拔,只有当你有意识从全局上去分析整个系统的设计,从app的各种页面去构建出一个逻辑框架图的时候,你才开始“玩转”这个app。那么,有没有一套方法可以帮助我们迅速在大脑中建立app模型?答案是可以有,我们要做的就是翻转页面,然后把这些页面解构、重组,形成一个逻辑(功能)框架图。当你的大脑中有了这样一个整体的概念,再细入到每一个具体页面的时候,你看到的不再只是这个页面,你会知道它处于整体的哪一个位置,它在整个app中扮演了怎样的一个角色,它与其他页面之间的逻辑关系是如何的。
尽管这两个引子切入角度不同,但是大家可以发现它们在描述同一个事实:我们需要一套方法论去为app建模,从而帮助我们去更好的理解、设计app产品。这种描述一方面在设计的时候为需求与原型之间做缓冲,另一方面在准备深度体验app的时候,能真正从全局上去理解该app的设计思想,而不仅仅是“只见树木不见森林”。
“他山之石可以攻玉”,笔者受到UML类图以及数据库原理E-R(实体-关系)图的启发,发现采用类似方式去描述一个app的逻辑框架非常的有效。首先从概念上来说,app的“实体关系模型”就是把app理解成有许多不同的实体组成,而且这些实体之间又有各种关系,实体们相互影响相互变化。具体的页面就是把不同的实体按一定规则的呈现,而页面之间的关系也透露出各个实体之间的关系。所以,描述一个app就是首先描述“实体”,然后描述实体之间的关系,最后描述实体的组织呈现。这样就能非常深刻的去理解一个app了。当然没有听明白的小伙伴们也不要紧,下面笔者用一个实例(网易云音乐app)去说明怎样使用实体-关系的方式去为一个app建模。
描述实体
实体可以理解成“概念类”,比如在网易云音乐中我们可以抽象出这些“概念”实体:歌曲、歌单、用户、歌手、专辑、DJ节目。下面举一个歌单实体的例子,如图:
页面-我的音乐 |
|
组成部分(各个实体) | 关联(操作) |
下载音乐
已下载/下载中 [歌曲]下载的歌曲 [歌手]下载歌曲所属歌手 [专辑]下载歌曲所属专辑 |
除DJ节目外的下载操作 |
最近播放
[歌曲]最近播放的歌曲 |
歌曲播放操作 |
我收藏的DJ节目
[DJ节目]我收藏的DJ节目 |
DJ节目下载、收藏操作 |
我创建的歌单
[ (特殊歌单) 歌单]我喜欢的音乐 [歌单]我创建的歌单 |
新建歌单操作 |
我收藏的歌单
[歌单]我收藏的歌单 |
收藏歌单操作 |
页面全局:
我的音乐页面包含操作:导入音乐、新建歌单、管理歌单 |
写在最后的话
如果想快速上手一个app,那就可以用分析app的实体与实体关系的方法在脑中建模,形成一个全局感知。这种建模不用太精细,在大脑中形成一个提纲挈领的印象即可。不过在设计app的场景下就需要落实各个细节了,从顶层设计开始,逐步分析系统的实体与实体关系,然后再在这个基础上去组织构建app原型,这将大大提升你的工作效率。
因为篇幅和可理解性等原因,木柄把网易云音乐app所有的实体图放在自己的博客网站http://mubing01.cn/?p=76下,有兴趣的同学可以点过去一看。这篇文章算是近期木柄的心血之作,之后木柄还会从产品经理技能的角度出发,写一系列产品方面的“纯干货”,如果你也是执着于互联网产品设计的同路人那就不要错过了,敬请关注我的公共号mubing01,个人博客网站mubing01.cn。
前来学习,木柄牛逼。
一股浓厚的数据库气息扑鼻而来。。。
哈哈,本来就是做技术出身的。。