一、什么是产品原型图画好原型图是产品经理必备的基本功，本文对如何画好原型图做个分享，希望对你有所帮助。
老规矩，先上个人理解的定义：原型图是产品经理对某一需求抽象思考的具象表现。
首先它只是一个表现形式而已，主要内容其实是对需求的思考过程。只是说，为了后续的交流方便，使用画图工具将其绘制出来的成果。
二、原型图的作用有哪些主要有两大作用：
一、用于指导后续的UI设计、开发、测试工作
到现在，在To C的互联网软件公司，已经不再严格对照《需求规格说明书》进行开发了。所以一份详尽的产品原型图，已经充当需求说明书的职能来指导下一阶段的需求评审、开发工作。
只是不同角色对原型图的关注点不太一致。UI关注整体页面元素、排版布局，开发关注产品功能、规则，测试关注异常分支，用于后续用例编写。
二、用于需求调研阶段的快速确认定稿
同时原型图也可以用于需求调研，在一些外包的软件项目中（一般To G/B项目），为了与客户需求快速达成一致，现场需求采集人员可绘制原型草图，与业务方进行需求确认。
这样做的好处在于在开发团队还未正式启动前，业务方可通过原型图预见软件交付上线时的样子，模拟后续真实操作交互，可以有效的减少需求变更。这在工期要求严格的工程项目中，显得格外重要。
三、常用的原型工具常用的原型工具有Axure、Sketch、墨刀，还有近期老罗代言的MasterGo等等。
我个人之前画后端，Axure用的比较多。但画小程序或者APP时，我更喜欢用墨刀。墨刀有很多现成的组件，直接拖拽使用，连线式的交互也非常直观。缺点就是费用不低，对未升级企业版的朋友来说，项目文件无法跨账户拷贝，对产品经理离职后资产的交接比较恶心。
就工具本身而言，看个人喜好，方便易用就好。
四、具体如何绘制前文所述，原型图绘制的主要工作量其实在业务梳理的过程，最终画原型只是临门一脚的事情。需求梳理清晰了，画图其实非常快。
从收到需求到原型出图，我的思考路径如下，供参考：
一、分析需求故事的目的
切记，别一拿到某个需求，就开始无脑的画图。不论这个需求是否简单，先思考下这个需求的目的是什么？给谁用？解决了什么问题？能产生什么价值？
在分析需求的过程中，多问几个为什么，深入思考用户底层的诉求是什么。这个过程中，5why工具法可以参考，就是对你的用户提的需求，问5个为什么，可能他的底层诉求就出来了。
想清楚了为什么做此需求后，至少后续的产品设计方向上不会有太大的偏差。否则你做出来的东西可能就会反复推倒重来，代价非常大。
二、梳理业务流程及功能框架
这一步是需求分析的主要过程。对轻量级的用户故事，可能不涉及此环节。如作为一个统计员，我需要增加一些查询条件来满足XX统计的需要。
但对于一些稍微大一点的用户故事，那么你可能得先梳理相关的功能框架/功能清单以及业务流程图，以便你更深入地理解需求。
在梳理功能框架时，需要注意功能与功能之间的关系，同时系统功能应该是同业务流程相对应。至于业务流程图的画法，可以参考我之前的文章《产品经理新人必看 如何绘制业务流程图》。
三、然后把图画出来
经过前面两个步骤的梳理，最后的画图工作已经非常简单。
在不同场景情形，未必需要完整规范的原型图。在敏捷团队，如果各方对业务需求已经高度同频时，也许一张白板上的草图，这项开发工作已经可以得到推进。
同样对画图，我给出一些建议，基本可以屏蔽掉大部分新人的许多问题：
注意考虑功能的完整性：增删改查基本是一体的，看业务需要，有些可以不需要修改功能，比如微信中已发票的朋友圈。注意考虑异常及分支情形：主流程往往不会有大问题，出问题的往往是在异常及分支上，碰到每一个提交按钮都要进一步思考，什么情形无法提交，需要给出什么提示；注意校验每一个输入项的规则：该不该必填，输入格式要求是什么，有没有联动输入的校验问题，比如文本框，最多允许输入多少字符，比如图片输入，有没有大小限制等等；注意本需求相关的功能影响：当你每新增一个需求时，你需要思考这个需求有没有相关的业务或功能受到影响，如果有，请逐一遍历它。比如某一业务功能我需要新增一个字段A，那么这个字段应该同样出现编辑/详情页面上。总结最后总结下，画原型图只是需求梳理过程的结果体现，所以要想画好一个原型图，本质是要学会需求的分析。
至于要不要高保真这种问题，我是不会去浪费这个时间的。