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