编辑导读：刚入行不久的产品新人，总是会遇到这样的情况：尽管自己已经考虑全面，但是总是会在开发的时候遇到各种各样的问题。画原型时，经常会漏掉很多的使用场景，应该如何改进呢？我们在天天问和小伙伴共同探讨了这个问题，一起来看一下他们是怎么说的吧~
作为产品经理，不是在画原型就是在画原型的路上。
而作为一名新人，总会遇到这样的情况：
画完原型，评审完，自以为没啥问题了，但是到前后端开发的时候，还是会出现各种各样的问题或者自己没有想到的一些情况。
为什么会这样？是自己能力不够的问题还是正常情况？需要怎么去改进？
针对这个问题，我们在天天问展开了一场讨论，一起来看看小伙伴们是怎么说的吧~
【天天问每周精选】第146期：画原型时，经常会漏掉很多的使用场景，如何去改进？
文章内容部分来源于@我爱芋儿鸡 @北北北北 @小胖纸 @仓前吴彦祖 @冰雨幻天 @冬至 的精彩回答。
一、从自己入手
拿到需求以后，不要第一时间画原型，第一步是确认了解需求；在确认了解需求的基础上进行需求调研和竞品分析，竞品分析和需要调研完成接着画功能清单和业务流程图，最后才画原型；原型是最后一步也是非常重要的一步，不能急于求成。
产品需求文档是否考虑得全面，会直接影响到后续的开发进度以及实现的效果。
如果碰上比较严谨负责的团队开发，他们会提醒那些我们忽视的问题。但是很多开发只是按部就班，未提及的细节就默默地处理，或者是不做了，直到我们验收版本时才发现问题，不仅项目延期，开发对我们的信任感也骤然降低。
以下是容易被忽视的十个细节：
1）默认值
大多数用户比我们想象中的还要懒，所以需要在涉及到个性化选择功能时，设置默认选项或者是默认值时，同时满足小白用户与专家用户的需求。
2）上下限
任何功能都需要设置上限值和下限值，避免产品出现失控。
比如说文字输入限制，发图片数量限制，就是为了界面整体的协调性，保证文字不会越界，同时考虑是否允许换行，并且最多允许换几行。超过字数限制后会怎样显示，是直接省略还是滚动显示。
3）误操作提醒
对于一些不可逆转的功能，比如说举报、加入黑名单、清空数据、放弃保存等等，必须要给予确认提醒，防止因为误操作而触发该功能。
4）网络状况
网络状况会影响数据的拉取，所以要考虑在断网或者是弱网环境下的使用。比如客户端内置默认图片，在拉取到数据之前保持界面的完整性，还要考虑到数据缓存机制，减少网络状况的不稳定，对产品的体验影响及时给予用户网络状态提示，并引导用户重新连网。
5）权限禁用
产品的功能需要调用系统的权限，而一些手机品牌对于权限的限制比较严格，所以会出现安装之后某些功能无法使用的情况。
比如我们的产品需要调用摄像头权限，而小米在第三方应用中默认禁用这个权限，所以很多小米用户反馈无法拍照。后来我们添加了权限禁用时的提示弹框，引导用户去设置里开启权限。
6）无响应状态
有一些功能运行时，会占用比较大的内存，对于性能较差的手机就会一直出现在loading界面，用户只能强制刹掉进程。所以要设计无响应状态提示用户程序仍在运行，需要耐心等待，也要给用户返回上一层的选择空间。
7）多语言配置
如果你的产品有可能会推广到海外，那么最好提前考虑多语言配置的问题。为了减少安装包的大小，必须要精简资源库，尽量使用能够复用的图片素材减少文字类图片。分享功能可以使用集成SDK，保证国内海外的用户都可以使用。
8）规则后台可控
很多规则在制定时，我们也不能保证说是最佳的。如果把规则写死在客户端，上线后数据反馈效果不佳，那么只能通过发布版本来调整，费时又费力。如果把规则做到后台可控，虽然在开发时会多投入一些工作量，但能够做到快速灵活的调整。
9）数据统计埋点
要验证功能上线后是否达到设计目的，就必须通过统计来进行分析，这也是衡量产品经理能力的一个指标。可以用友盟这种第三方统计平台，如果想要更详细的数据情况，就需要搭建公司内部的数据后台。比如界面的停留时长，点击转化率，用户路径等等。
10）运营扩展
产品和运营是密不可分的，所以在设计每个功能时都要考虑到是否有运营扩展的可能，比如限制某些功能的使用需要达成某种条件再解锁，或者在界面中设计一些预留广告位，为流量变现做准备。
多看看前辈的文档，多写写通过实操练手。只有踩过才知道哪里是坑，无他但手熟尔。每次工作完成后，多对自己遗漏的东西复盘吧，避免下次再犯同样的错误。
最后，做个原型设计自查表，在自己设计完了之后可以自查一下，看看哪里有没有问题。或者也可以原型设计完了之后，写需求文档，在写需求文档的时候再梳理下自己写的内容。
二、从其他人入手
需求评审所有参会各方未反馈出问题，但实际开展中发现各种问题，这说明除了产品经理外，团队各个职能的小伙伴都存在可改进之处。
产品：
前期需求调研不够透彻、业务场景理解不够深入、边缘关联业务了解不足。也就是说，设计的产品方案是没有形成闭环的或者是细节设计颗粒度不够。
此外还有一种可能是评审时需求沟通不够彻底，阐述的需求不够细致。有些同事不会仔细去看你做的需求，评审会议是他们获取信息的最佳途径。也就是说，他们以评审中获取的信息评估没问题，不意味着根据需求文档评估没问题。
技术：
评审参与度专注度不够深或者前瞻评估度需要提升。
需求评审的目的之一是技术理解需求内容以评估可行性和开发周期。实际开发中，发现评审时未提出的问题需要去分析到底是什么原因导致，毕竟开发中产生问题会非常影响开发进度且不是一个健康的项目状况。
其他：
同理，后续开发过程中出现的问题可能是产品向/技术向/业务向，评审中如果还有运营/业务参与，他们也应当担当一定的方案评估角色。
测试涉及到全需求测验，对整个产品/技术了解度相当深，正向的团队测试同学如果在评审中有异议也应该提出。
总体而言，开展过程出现问题产品和技术需做最大反省并为之改进。
三、结语
需求梳理很难一步到位，在任何环节都有可能产生疏漏。画原型时产生问题也很正常，原型本身也是产品，需要迭代。
产品经理要做的，就是一步步试错，快速迭代，降低出错概率。
关于“画原型时，经常会漏掉很多的使用场景，如何去改进？”这个问题，你有什么想说的呢？一起来聊聊吧~
戳：http://996.pm/zrEB6
#天天问神回复#
「天天神回复」是天天问的一个新栏目，致力于发现天天问小伙伴的精彩语录。抖机灵，大伙儿也是认真的！如果喜欢，记得点击问题链接，和TA一起互动吧，我们也在这里期待你的发言哟~
如果产品经理统领地球，世界会变得怎么样？
@夜漫产品：
程序猿分分钟告诉你什么叫“猩球崛起”
如何看待“代码能跑就不要动”？
@小小小白：
要运行1+2+3+4，有A, B两个代码。
A代码：1+2=2
B代码：3+4=8
运行1+2+3+4=A+B=2+8=10，结果正确，皆大欢喜。
有一天一个程序员看到了代码A，发现了问题，修改A：1+2=3
那么再次运行1+2+3+4=A+B=3+8=11，结果错误，而错误的B代码藏得很深，根本找不到。
修改了某一个代码可能会像蝴蝶效应一样影响其他代码，导致大厦倾倒。
浅显理解，欢迎指正。
想不出需求了怎么办？
@lee：
你想，或者不想，需求就在那里，不增不减。
去找客户，或让客户来你这里，好好沟通，敞亮通透。
我们从不创造需求，更不臆想需求，我们只是需求的发现者、分析者，我们只是需求的转述者、搬运工。
多一个产品经理不多，但如果少了一个会思考的产品经理，整个世界的效率就又下降一点点。
#相关阅读#
【天天问每周精选】第145期：知乎VS百度知道，问答产品需要设置“采纳”功能吗？
【天天问每周精选】第144期：除了降价和送礼品，线上促销还有没有新玩法？
【天天问每周精选】第143期：看到差评就不想买，那为什么不取消差评？
【天天问每周精选】第142期：明知道用户不喜欢广告，为什么还要花钱四处投放？
【天天问每周精选】第141期：直播带货主播：销售导购 or 帅哥美女，应该先用哪个角色亮相？
【天天问每周精选】第140期：众筹了几句互联网情话，我笑yue了
素材来源：天天问话题精选
「天天问」为人人都是产品经理社区旗下的互助问答模块，致力产品、运营、营销等领域知识的学习交流。
本栏目由@Darcy 整理编辑发布，欢迎大家踊跃提问，一起交流。
题图来自Unsplash，基于CC0协议