阿拓带你飞：读这篇文章的两个理由：第一，弥补需求到原型之间的“断层；第二，教你怎么样构建产品的逻辑框架图，”玩转”app。

需求到原型是跳跃的，本文重点论述中间被忽略的过渡层，提出一套明确的方法论。首先描述“实体”，然后描述实体之间的关系，最后描述实体的组织呈现。这样就能非常深刻的去理解一个app了。

引子一

歌单实体中的变量描述了歌单是由哪些元素组成，一个歌单拥有歌单名、封面、介绍与评论。当然一个歌单也会有创建者、属于此歌单的歌曲与收藏该歌单的用户这些元素，不过它们本身也是实体类型的(创建者属于用户实体，歌单的歌曲属于歌曲实体，收藏该歌单的用户属于用户实体)，因此它们被称作实体变量。实体变量的表示方法是在变量名之前加上括在中括号里的实体类型，比如“[用户]创建者”。

操作描述了歌单实体的操作集合，歌单可以被收藏、评论、分享、播放与下载。当然还有一个被大括号括起来的操作，这说明执行此操作是需要条件的。在歌单例子中，管理歌单与 编辑歌单封面、介绍是需要条件的，因为只有歌单的所有者才能执行这些操作。

描述实体关系

描述了app中的各个实体，我们就能清晰的知道app是由哪些部分构成的，但是实体是静态的，事实上这些实体之间往往有着复杂的关系，它们是彼此联系彼此依赖的，一个的变化往往可以引起另一个的变化。形象的来说，可以把实体和实体关系类别成公交站点与公交路线，实体是公交站点，而实体关系，就是描述了这些站点是如何连接起来的公交路线，只有明确了站点与路线一个公交系统才算规划好，同样明确了实体与实体关系，才算描述好了一个app系统。以网易云音乐为例，下图描述了歌曲实体与歌单实体的关系：

歌曲可以被添加到歌单，而用户又可以使用“歌单管理歌曲”的功能管理歌曲。比较特殊的是系统自带歌单“我喜欢的音乐”，用户点击歌曲的“喜欢”图标就能将歌曲加“我喜欢的音乐”这个歌单。此外，实体自己对自己也可能会有关系，比如：

描述实体的组织与呈现(制作原型)

这一步事实上就是我们平常的制作原型，不过利用前面两步的分析成果，制作原型的过程就可以认为是“描述实体的组织与呈现”，这将会带来很多好处。如果直接按照传统的“根据需求制作原型”，我们心里也许会有把握全局的模糊意识，不过一旦陷入页面布局、内容摆放等原型制作的细节里(如果使用axure还要做一些编辑与交互)，由于缺乏通盘考虑，很容易使自己迷失。更多的情况是，没有一个对全局很好的描述(缺乏对实体与实体关系的解析)，我们在设计详细页面的时候就没有一个清晰的框架约束，可能设计出的各个部分间会存在逻辑的不顺畅甚至彼此矛盾。而如果我们前期已经在全局上分析了app系统的实体与实体关系，那么制作原型的过程相当于将这些已经分析思考比较全面的实体“放”到具体的页面上呈现，这就像我们在旅游某一个景点的时候身上一直带了一张地图，感到有所迷失的时候，就可以打开地图去查找自己的位置，迅速理清思路，也就是你在设计某个页面的时候心里一定清楚它属于全局框架的哪个部分，它与其他页面之间存在着怎样的关联。实体、实体关系与原型的关系可以总结成下图：

下面举一个网易云音乐中“我的音乐”页面的具体例子(印证以上的关系图)：

写在最后的话

如果想快速上手一个app，那就可以用分析app的实体与实体关系的方法在脑中建模，形成一个全局感知。这种建模不用太精细，在大脑中形成一个提纲挈领的印象即可。不过在设计app的场景下就需要落实各个细节了，从顶层设计开始，逐步分析系统的实体与实体关系，然后再在这个基础上去组织构建app原型，这将大大提升你的工作效率。

因为篇幅和可理解性等原因，木柄把网易云音乐app所有的实体图放在自己的网站http://mubing01.cn/?p=76下，有兴趣的同学可以点过去一看。这篇文章算是近期木柄的心血之作，之后木柄还会从产品经理技能的角度出发，写一系列产品方面的“纯干货”，如果你也是执着于互联网产品设计的同路人那就不要错过了。

原文作者：木柄，文章来源于：产品中国