在充满“互联网+”这个词的时代里，产品经理这个职业已经成为这个时代的热门职业。所以在这样的一个时代里出现很多各行各业转做产品的“产品新人”。我也是其中一个！那么作为产品新人在刚入门产品这个行业的时候，工作中接触最多的就应该是PRD文档，和画产品原型图了。
有些公司因公司需求可能不会要求写详细的PRD文档，而是直接将产品的需求规则写在原型上面，便于技术、设计等人员使用。因为对于程序猿哥哥们一边看文档一边看原型操作起来不是特别的方便，增加了开发人员的操作时间成本。因此产品新人如何“正确”的输出一份产品原型变得极为关键。下面说一些关于我自己在一年内产品工作中画原型上遇到的一些小问题和总结。
流程清晰，草图先行
我不知道大家有没有过这样的尴尬经历？当需求确认后，直接打开Axure开始着手画原型，画到一个页面的时候，就在那抓脑袋停下来想下一个跳转页面的布局问题。想着想着，画差不多了，又感觉似乎之前有些地方的流程和逻辑有点不正确，又需要从新确定一遍流程…..。这样断断续续的画原型，可以暂定是效率低下的表现，这样的表现还会影响你自己对后续做产品工作的一个心态。
首先我们的明确一个观点：软件只是一个“帮助你实现的工具”，它并不会使你的结果变得多么的神奇。
这个观点让我自己在做任何事情的时候都会习惯去先画一个草图，如需要用到软件的时候才会使用。就像考试数学一样当一个人还没有绝对把握把正确答案填上去的时候，都需要经过多次的草稿计算。产品原型设计也是一样，在逻辑和流程确定好之后，需要你先用草图快速的将页面画出来，将每一个页面中需要放入的一些元素快速组合表现出来。这样做的好处就是：它不会一开始就把一些细节性的东西在草图阶段就考虑进来，比如说我这个字体放多大合适，这个按钮放左边好还是右边好。当出现逻辑错误时，也可以快速将其修改。“减少纠结，提升效率”。
相同文字、样式统一
对于产品新人在初次画原型的过程中，文字样式的统一也是容易犯错的地方。同样的一段文字，在不同的原型页面出现时可能是不一样的内容和不一样的表达意义。例如：在一个订单详情页面中，这个“金额”的文字表示“订货总计”，而在订单列表中你将它改为“下单金额”。
这样的错误其实只是一些小细节的问题，但是对于程序猿哥哥们来说他们只会执行你最终的需求，所以他们会按照自己的理解去开发，开发完成后你才发现结果和实际需求是不一致的。当这样的问题出现时其实就已是要“更改需求”了。
在互联网企业中产品因更改需求被程序猿喷成狗的例子经常发生，所以心理承受能力有限的童鞋尽量避免犯这些小错误。当然对于这些小毛病也是有一些解决方案的，比如万能的“母版”啊！多使用“ctrl”C+“ctrl”V！等等。“凡事多注意细节”
实际场景中的真实数据
我自己在从事这一年的产品工作中，遇到过两次这样尴尬的场景。当产品上测试环境后发现真实数据比想象中的多出几十倍，页面放不下，打开页面加载速度超级慢的情况。并且更可怕的是你还没在需求原型中备注说明要求“分页加载”。
在这个时候你就会为你画原型的大意来买单了，你会跪求程序猿哥哥们帮你改需求，跪求都还得看脸色。想想这个场景，是不是都害怕了！如果你不想这样就不要偷这个懒，在画原型的过程中尽量使用现实场景中会出现的真实数据，并且合理的将这些数据进行归类。在进入需求评审前，可以多次模拟自己的产品操作流程。最简单的方法就是拿一份准备好的真实数据，对着你的原型走一遍大流程看看是否能走通、是否还有遗漏的地方。
清晰明了的文件夹
在我们公司产品进入需求评审前，我们都会提前2小时将产品的原型发出来给技术人员们先看看原型，然后才进入需求评审。这样做的目的是为了在会议前给大家一点时间来了解一下会议的基本内容会议中就可以减少一些沟通的成本。
所以递交一份文件架构清晰的产品原型也是非常有必要的，因为对于程序猿哥哥们来说，有些相同的页面都是可以重复利用的，所以在原型文件中，一些没必要的页面都可以隐藏掉。比如“查看”页面，和编辑页面内容都是一样，没有必要单独画一个“查看”的页面，只要你备注清楚就行。（当然这个也因公司而异）。
还有一点值得注意的就是，画错了的页面千万不要直接删掉。因为有些东西说不定就是一时没想明白就做了错误的举动，如果你没保存纪录直接删除后在想找回时，你就得从新开始画了。
为了避免这种情况的发生，因此我个人习惯还是做个备份的文件夹“作废”，将所有删除的页面都放在这个文件夹中，当有需要的时候在去里面找出页面。这样做不仅可以节省一些不必要的时间，也可以看到你在原型制作过程中原型更改的纪录。如果原型更改纪录过多也会证明就是你在原型之前的工作没有做到位。
本人自身也是个刚入行小一年的产品小白，以上内容均属个人遇到情况，如有表达错误或表达不够清晰的地方还请各位轻喷。
