产品经理前期经过对产品的分析研究，头脑里渐渐形成了产品概念。概念的东西，毕竟只是想象和抽象的。
要生产出面向市场的产品，最终还得落实到实处，于是，产品原型就成了实现概念的产物。
有了产品原型，产品经理和团队成员的沟通就有了共同的频道，研发们根据产品原型逐一实现需求，测试们根据产品原型逐一验证需求是否真正实现。个人认为，结合Confluence、Jira里的产品需求，加上产品原型，已经足够形成完整的产品需求文档。
从无到有，从MVP开始
如果给我1个小时解答一道决定我生死的问题，我会花55分钟弄清楚这道题到底在问什么。一旦清楚它到底在问什么，剩下的5分钟足够回答这个问题。
——爱因斯坦
MVP，即最小化可行性产品，其作用是采用最小的代价，快速在市场验证想法的可行性。因此产品最初的原型设计，按照《精益创业》的说法，就是以实现MVP为目的的。
大体的思路是，围绕用户需求里优先级最高的、能解决用户痛点、形成闭环的需求，来设计产品最基本的功能和流程。
但是在动手绘制原型之前，应该先系统性地想想，产品未来3~6个月，或者6个月到1年的产品形态是怎么样的，从MVP开始，怎样进化到未来的形态。
如何思考MVP
这里，我虚构个例子，为了验证某种订阅服务的在线Web产品（命名为FastX吧）是否可行，在设计MVP原型的时候，应该只考虑实现这个服务所需要的、最简单的、但必须是完整的闭环。
如此一来，基本功能就必须包括了用户账号（不然用户如何订阅），服务的核心流程，用户支付（用户付费了才能使用服务）。
用户账号可以自行开发，也可以接入第三方账号，看具体需求；用户支付，分国内国外用户，看产品面向的用户。至于服务的核心流程，一般而言，应该是用户登录、服务流程、流程结束的过程。
服务流程可能有3种，流程1、流程2、流程3，每一种的步骤也可能有区别，我们先考虑最常见的流程1，该流程有3个步骤。这样的话，产品FastX的服务流程应该是这样的：
用户登录——选择流程1——步骤1——步骤2——步骤3——流程结束
通过以上分析，我们确定了FastX MVP的组成部分、核心流程、行为闭环。
用户场景下的MVP
产品经理最重要的是洞察用户，在设计原型过程中，个人的体验是，代入用户的角色（好吧，我知道很难）去审视设计的每一步。
把自己当成小白用户，去想象当一个用户在使用产品时，他们的心理、认知处于什么状态，他们的视觉焦点和操作行为，是否符合设计的预期。
因此确定了MVP后，开始制作原型之前，通过纳入用户角色的思考，我们还需要进一步深入FastX服务流程的思考，即，用户在真实场景下，是怎么使用产品的，可能会遇到什么问题，遇到问题后，产品该怎么跟用户交互。
可以从预期行为、异常、边界限制、默认值考虑。
1、预期行为
用户使用流程1的时候，可能有几种路径。如果流程复杂、路径多，有时候需要画流程图描述，以免遗漏某些细节。
接着思考每一种路径下，用户操作的每一个步骤下，信息的指引和交互的反馈，以帮助用户顺利结束流程。如果服务涉及到工作流，还要考虑状态的类型以及转化的条件。
用户预期行为通常是我们设想的、用户使用产品的理想情况，从起点A开始，到终点Z结束，一路经过B、C、D，每个步骤下如何操作，都在我们的期望中。
2、异常
设计原型时，这类情况是更需要考虑的。因为不管产品经理如何共情，毕竟不是用户，更何况处于验证产品阶段，很多用户的行为根本无法预测。因此设计的时候，要尽量预设各种异常，以及相对应的处理方式。
回到刚才例子，我们预设用户的路径是从A开始，经过B、C、D、到Z结束。
但如果用户不这么来，在C的时候，返回到B、A，又折回到C，这个时候，整个流程涉及的状态和信息将怎么变化？
又比如说，用户到了D，然后就把浏览器关闭了，等他下次登录的时候，能不能看到之前的这次流程？如果能，需要怎样引导用户进行后续的操作？
另外要注意的是网络情况，网络慢、与服务器连接中断之类的情况等。用户使用产品时，尤其是一个流程进行到一半的时候，遇到这些情况，产品该如何表现？
优雅降级是一种处理方式，即功能优先，去除多余的UI信息展示，以保证服务能够继续。
一种是信息的渐次展示，只显示当前用户操作需要的信息，等用户需要另外的信息时，再逐渐显示给用户。
另一种是实时保留数据，这样的话不管网络状况如何，总能保留用户最新的数据，但也因此加重服务器的压力。
3、边界限制
一个提供服务的在线产品，同一时间能够承受的服务数量是有限制的，即时是只服务单一的用户，也需要考虑所能提供的边界值。
MVP阶段，只能同时满足有限的几个用户，但要预留大并发量的情况下如何应对，以便程序员们做好技术选型。
涉及到文档上传的，要考虑文档格式、大小、页数等的限制，超过这些阈值，产品应能友好告知用户，而不是直接一来就404。
免费用户和付费用户，权限是有区别的，除了要明确告知用户，更进一步的，当免费用户因为权限不足而导致流程没法进行下去时，要考虑引导用户后续操作，等等。
4、默认值
设想MVP时，很多时候，产品经理总会构想已经有了很多用户、很多数据的场景，却往往忘了一个刚刚发布的产品，一个用户都没有的情况下，整个产品的信息设计会是怎么样。
我们经常说信息列表，展示用户的历史行为记录，里面会有各种信息，时间、行为、状态、操作等，但如果用户还没开始使用产品，仅仅是注册进来的，那么他看到的信息列表，会是什么？
默认为空是通常的方式，但可以更近一步，设计一个“推”的动作，诱使用户说：开始使用吧！这样会不会更好？
比如一个社交产品，用户关系是核心。作为产品的第一个用户，如果进去后只看到空荡荡的页面，会是什么感受？所以很多产品会询问是否导入通讯录，又或者给用户推荐几个值得关注的人等等。
结语
以上，是产品经理动手制作原型时需要考虑的种种，具体产品有不同的细节点，但大的思路就是通过原型，迅速开发出MVP，以验证产品概念的可行性。
MVP一旦推出市场，必须是可用的，而不是一个半成品。这就要求产品经理在构思MVP原型时，不但要考虑用户正常的使用操作，还要考虑各种异常、边界限制和默认值。