首先，我们要明确原型图是画给谁看的，通常是以下几类人：开发、部门领导、UI设计师和测试，一个完善的产品流程离不开着几个角色。

开发通常最关心的是有多少功能，功能的复杂度怎么样，边界条件是什么，异常情况怎么处理等。设计师通常关心元素之间的关系，排版和布局。而跟主管汇报，由于主管的事情是很多的，他们通常最关心功能整体的流程、原型的易读性，以及价值体现。而测试则关心产品需求用户，辅助他们写测试用例，以及是否穷尽考虑到各个场景。

那么，怎么样的原型图才算是专业的原型图呢？小编总结了工作以来画原型图的经验，总结出了以下经验。

一. 清晰的视觉层次

突出重要元素，弱化次要元素

页面是由元素组成的，这些元素包括线、颜色、按钮等，要做到层次清晰，就要把重要的元素进行强化，次要的元素进行弱化，比如可以通过颜色的饱和度来突出重要元素，通过面积突出重要元素等，引导用户聚集视觉焦点到重要的元素上。如下图，通过对比颜色和区域面积的大小，来突出重要元素。

格式塔原理

将相关的元素组织在一起，让用户知道这些元素在任务、数据和工具上是相关的，通常用位置表示。相关的元素位置上相近，不相关元素用空间隔开。如下图，第一个图为反面例子，信息距离上下一致，用户无法区分中间的信息是属于上方还是下方。第二张图是airbnb的截图，红色线框部分明显与下方隔开一定距离，在视觉上体现为跟上方相关。

二. 视觉流结构

什么是视觉流？

视觉流是指视觉焦点形成的轨迹，由于眼球生理结构限制，人眼在某时刻只能产生一个焦点。人的这一视觉特性使得人的视线运动通常表现为点到点的跳跃式扫描（saccade），而不是平滑移动。人在阅读时，一行通常包含4～7个跳动――定位（jump-fixation）的动作，注视持续时间为200～600ms。 因此用户在对界面持续关注后会留下一系列的视觉焦点，这些视觉焦点的轨迹称为视觉流（visual line）。

平稳的视觉流结构能帮助用户快速理解逻辑路径，减少用户的认知成本。平稳的视觉流有两个原则：

视觉焦点不宜过多。

视觉焦点的路径逻辑尽量简单。

如下图，同为软件教程详情页，左侧的视觉焦点过多，视觉流向路径复杂，而右侧的视觉流向路径简单，容易理解。

三. 功能预见性

看到一个功能，就知道该功能如何使用，称为功能预见性。

如，lofter底部导航栏在改版前，只用图标表现功能，没法清晰知道每个图标的含义。改版后，用「图标+文字」，直接解释每个图标的含义，减少认知负荷。

如下图，为途虎养车某个门店的评价截图，该门店提供三个服务，分别是轮胎、保养、美容和安装，红色方框内为各个服务的得分。当第一次进入这个页面，默认「轮胎」评价高亮红色，其他为灰色，潜意识里不知道点击是可以切换查看对应评论列表的，即切换查看功能感太弱。

四. 视觉的焦点为信息的焦点

每个页面都有一个核心功能，这个核心功能不应该被其他功能所覆盖，特别是当功能越来越多、越来越复杂时。那我们怎么判断页面上哪个功能是信息的焦点呢？如果针对竞品调研，页面上颜色饱和度最高，或者功能占据区域最大的即为页面的核心功能，即信息焦点。当设计自家产品功能，要从主流用户的主流场景，或者功能的商业价值、使用频率等维度进行分析，一个页面的信息焦点不宜过多，过多会影响视觉流的稳定。

如下图，图1为《风起长林》中的剧集截图，图2为点击后的效果，图3刻意把进度条拖动方块变小。我们先来分析进度条的使用场景：查看进度、快进、拖动进度条。当把进度条变小，如图3，进度条不再成为信息的焦点，视觉效果被弱化，用户在查看进度、快进时要自己看才能看到当前进度，拖动滑块时要小心翼翼才能点中。

再看一个生活中真实的例子，有一天点了外卖，配送员说已送达，于是去公司的前台找（前台有很多外卖），找了三遍没有找到，第四遍终于在仅剩2份没有人拿的外卖中找到了。

如下图，我们先来做个场景分析，去找外卖，一般人大多数情况时寻找自己的名字/电话，可是这份外卖单子把骑手的姓名和电话号码打印得很大，客户（我）的名字没有打印，只留了一个小小的号码，造成了很难找到，然而我又不会刻意去记住骑手名称和电话。

五. 把简单留给用户

复杂度守恒定律（Law of conservation of complexity）由Larry Tesler 于1984年提出，也称泰斯勒定律（Tesler’s Law）。根据复杂度守恒定律，每个应用程序都具有其内在的、无法简化的复杂度。

无论在产品开发环节还是在用户与产品的交互环节，这一固有的复杂度都无法依照我们的意愿去除，只能设法调整、平衡。在交互设计中，体现为把复杂留给系统，尽量把简单的界面呈现给用户。

如，我们在百度上搜索图片，输入关键词—点击搜索—出现图片，整个过程是一个非常简单的过程，即白盒部分是非常简单的。黑盒部分，在用户输入关键词后，系统进行需求识别，识别出来大量图片，然后将些图片继续排序，检索出用户最可能希望看到的图片，然后才会显示出来，用户看到的结果系统往往需要进行大量的计算。

比如，你在家里点外卖和在公司点外卖，无需每次都定位和选择收货地址，系统会自动检测你当前的地理位置，从而给出合适的收货地址。但是快递的收货就不一样，有可能在家里下单，收货地址选为公司，或者在公司下单，收货地址选为家里，这个时候就不能根据用户当前的地理位置进行自动选择出收货地址。

其他的还体现为默认给出分类、选项、填空内容等，由输入变为选择。显性显示用户最关心的信息，比如在美团上点了外卖，很多人很关心外卖的送达时间，会好几次进入订单详情查看，美团干脆直接把送达情况展示出来，无需进入详情页查看。

根据《简约至上》，可以大大简化页面上的功能。

1. 删除

关注核心功能：增加价值始于改进核心体验。

砍掉残缺功能：不完美的功能不如不要。

删除掉可能对用户带来负担的细节，如干扰的文字、可有可无的选项。

排定功能优先级：产品的价值不是由功能的多寡来决定的，而是看能否满足用户的最高优先级目标。

删除干扰项。

选择聪明的默认值，减少用户选择。

避免视觉混乱，让用户保持专注。

2. 组织

分类。

利用网格，呈现页面布局。

利用大小、位置、分层、色标等进行实际组织。

关注用户的期望路径，而不是逻辑。

3. 隐藏

隐藏不常用但不能少的功能。

渐进展示：展示核心功能，隐藏扩展功能。

阶段展示：随着用户深入界面而展示相应的功能。

适时出现，不打扰用户，隐藏的目的不是为了藏，而是更好的展示。

让功能方便找到，不能藏得找不到。

4. 转移

把复杂性转移给擅长的一方，如用户、后台系统、其他设备。

创造开放式体验，降低用户受到的约束。

六. 考虑到边界条件

产品经理或者交互设计师，在做功能时，很容易遗漏一些边界条件，出现遗漏的原因，主要是在设计功能时只考虑到了主流场景，只做了主流场景下的设计，异常场景或者边界条件很难考虑到。这里教大家一个小技巧，写产品需求用例。在构建产品架构雏形时，用例往往能起到帮助确定功能界限的作用。

用例包括以下内容：

用例名称：此产品/功能的名称

用例编号： 此产品用例的编号

角色：操作/执行该功能的角色

简要说明： 最简化的内容对该需求功能的描述

前置条件：执行该功能的前提条件

后置条件： 该功能执行完毕后的结果条件

主事件流：该功能角色所执行的主要正常过程

异常和分支事件流：该功能角色所执行的次要异常过程

如在一个图片素材网站下载图片的用例：

如果不写产品用例，很多人可能只考虑进入详情页—点击下载按钮—下载成功这个流程，很容易遗漏用户未登录状态下的提示，无权限下载该图片的提示，甚至是图片下架后无法下载图片的提示。

六. 原型图标注，画开发看得懂的图

首先明确原型图标注是给谁看的，谁最关心原型标准呢？一般而言，开发和设计最关心原型图标注，开发最关心的是边界条件、页面跳转关系，而设计最关心有页面和功能遗漏，如反馈状态和空页面。画出功能的所有交互状态，清晰的显性化表示交互状态是作为交互或产品的基本功。一个好的标注满足以下几个条件：

标注点的含义，发生的事件

用脑图梳理所有对象和逻辑关系、状态

模块化区分和标记

定义好每个标注点的含义和事件

在做交互稿标记之前，定义规范好每个标记的含义，形成统一的规范，使得团队成员易于理解。如，我比较喜欢用水滴表示标注的功能，用圆圈+箭头的形式来标识页面跳转关系。

用脑图梳理所有对象和逻辑关系、状态

下面的原型图标注以在饿了么商家详情页结算订单为例，先用思维脑图梳理功能状态，这样能避免遗漏一些边界条件。

模块化区分和标记

梳理好状态后再在原型图上写产品用例，每个功能做成一个模块，有利于往后的维护和迭代，例如下面是饿了么的订单结算功能。

七. 在同一个页面展示所有的交互状态

很多的开发和设计，没有很多耐心看原型图上的各种标注，特别是时间一长，标注就非常多。如果是做版本的迭代，一定要做好标注的版本区分，让他们第一眼能看到当前版本要做的事情。如果是特别复杂的功能，尽量在一个页面上显示出所有的交互状态，避免在看原型图时有遗漏。有时候测试验收阶段的很多坑，各种状态遗漏，其实是由于前期没有做好标注引起的。

下面以微信消息列表页为例（梳理思路用脑图是一个好习惯），先用脑图画出所有的状态，补齐所有交互状态，后面再画的时候效率会高很多。

如下图，为微信消息列表页所有交互状态的列表呈现：

八. 页面跳转图（不要做孤立的设计）

页面跳转图，从用户的视角，系统化看流程的合理性。页面流程图有助于梳理页面之间的关系。交互设计师或产品经理在工作中，很容易把一个功能做成「孤岛型功能」，即这个功能跟其他功能没有建立联系，跟其他功能是孤立的关系。

如在「美啊教育」中要增加一个评论功能，那么评论机制应该怎么与现有系统对象建立联系？在分析这个问题之前先看看评论和教程的关系，如下图：

教程中可以看到相关评论，评论系统与教程之间已建立联系，但只是单线的关系。

我们再看看美啊这个产品中，还有什么对象是可以跟评论建立联系的？假如，为了刺激用户去评论，我们可以用积分奖励的方式，当用户评论教程后，可以获取一定的积分，即教程—积分通过评论建立了联系，跟现有的积分兑换优惠券、商品也是有联系的，于是建立了用户—教程，教程—积分，用户—积分的关系，整个积分体系不再是孤立的功能。

用户—教程

用户去评论教程。

教程的得分可以帮助用户筛选出更优质的教程。

教程—积分

通过评论教程可以获得积分。

积分可以免费兑换观看教程。

用户—积分

积分可以刺激用户去评论。

用户用积分可以获取商品，如优惠券等。

于是整个评论体系的页面关系图为（补充了部分可能存在的需求）：

九. 流程图，梳理业务逻辑关系

画流程图是产品经理的基本功，产品需求也是流程上的需求。画流程图的目的有以下几点：

确保产品流程的合理性。

有效传达需求。

检验异常分支。

在画流程图过程中，切勿遗漏异常状态，产品经理一般比较关心主要流程，可是开发同学在写代码时，要做条件边界判断，这个条件边界即为异常情况。测试同学在写测试用例时，要穷尽所有的场景，包括正常场景和异常场景，否则出了问题，是要背锅的……为了避免开发和测试同学不断询问你边界条件，最好在交付交互稿之前用流程图梳理出来。

常用的流程图分为单向流程图和泳道图（涉及到多个角色），单向流程图一般描述单一角色完成某个任务的整体过程，如登录注册过程、支付流程、填写资料等。

流程图包含以下内容：

事项：用户要完成什么任。。

角色：分别有哪些人会参与到流程中。

信息传递：信息在整个过程中是如何传递的。

异常：有哪些异常情况，如何处理。

如快手的登录注册流程，先来梳理思路：

事项：用户要完成快手的登录注册。

角色：普通用户。

信息传递：在触发登录注册框时，获取用户的注册信息，检验手机验证码，关联通讯录数据，获得第三方登录数据。

异常：最近登录过该如何处理？手机号无效该如何处理？手机号已注册该如何处理？

泳道图

除了要明确事项、角色、信息传递、异常等内容，在画复杂的泳道图之前，要明确参与角色，再梳理出不同的角色要完成的任务，各个角色之间的交接，整个流程的阶段划分。

如天猫的退货流程图作图思路：

1. 明确角色

参与角色有：买家、系统、卖家、客服。

2. 各个角色要完成的任务

买家：买家收到商品不满意，可以在天猫上发起退货，填写退款申请。如果卖家同意退货，买家可将商品寄到卖家的收货地址，寄送方式可选择自行寄件或者上门取货。如果卖家收到货后，拒绝退款，买家可以申请客服介入。

卖家：处理买家退款申请。如果订单满足退货条件，将退货地址发给买家。卖家收到商品，退款给买家。

系统：判断买家收货状态；检测买家的退款申请的原因、金额等，生成退款记录；判断是否平台先垫付退款；将卖家地址发给买家；系统将买家上门服务申请发送给合作的物流公司；变更退款状态。

客服：客服介入，判断双方责任。

3. 角色交接

买家将退款申请发送给系统，系统发送给卖家，卖家处理退款申请，卖家将退货地址发送给买家，买家寄件给卖家，卖家收货退款。如卖家拒绝退款，买家申请客服介入，客服处理买家或卖家的责任。

4. 阶段划分

为了方便理解整个流程，小编把流程分为5个阶段：

买家发起退货申请。

系统处理买家申请。

卖家处理退货申请。

买家寄件给卖家。

处理退款。

整个泳道图如下：