分析：如何理解描述一个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节目。下面举一个歌单实体的例子，如图：产品经理干货，APP建摸：一套描述app的方法论，互联网的一些事歌单实体中的变量描述了歌单是由哪些元素组成，一个歌单拥有歌单名、封面、介绍与评论。当然一个歌单也会有创建者、属于此歌单的歌曲与收藏该歌单的用户这些元素，不过它们本身也是实体类型的(创建者属于用户实体，歌单的歌曲属于歌曲实体，收藏该歌单的用户属于用户实体)，因此它们被称作实体变量。实体变量的表示方法是在变量名之前加上括在中括号里的实体类型，比如“[用户]创建者”。操作描述了歌单实体的操作集合，歌单可以被收藏、评论、分享、播放与下载。当然还有一个被大括号