需求到原型是跳跃的，本文重点论述中间被忽略的过渡层，提出一套明确的方法论。首先描述“实体”，然后描述实体之间的关系，最后描述实体的组织呈现。这样就能非常深刻的去理解一个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是由哪些部分构成的，但是实体是静态的，事实上这些实体之间往往有着复杂的关系，它们是彼此联系彼此依赖的，一个的变化往往可以引起另一个的变化。形象的来说，可以把实体和实体关系类别成公交站点与公交路线，实体是公交站点，而实体关系，就是描述了这些站点是如何连接起来的公交路线，只有明确了站点与路线一个公交系统才算规划好，同样明确了实体与实体关系，才算描述好了一个app系统。以网易云音乐为例，下图描述了歌曲实体与歌单实体的关系：

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

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

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

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

　　写在最后的话

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

晋城龙鼎 - 晋城网站建设为您解答！