可以的话，每次写文章都配一张自己画的图··（简书会封这种小黄图么）
每次在车间里面，一个人撸图的时候，都会碰到“产品经理”飚过来说“喵啊，XXX页面要做一个弹框，是给用户XXX的，你准备一下哈~”然后又准备飚回去，每每还没等他溜走，就立马按住他，掐死在座位上坐下来跟他好好的掰扯一番：这是谁提的要求？为什么要加这个功能？然后内心过一遍（这个情况典型么，加了用户都会开心吗？不加用户会守影响吗？）确认需求没有问题之后，再思考满足需求的处理方式（请听题：除了弹框咱还能有点出息吗?），最后交付需求+后期跟进验证。
这算是个老梗，但还是值得拿出来说道一番~
产品上去后，我们车间全体开始了紧张的填坑阶段，产品投入市场在接受受众的检验中，由于场景分析不彻底，业务逻辑不完善以及客户PM附体等诸多因素，造成的后果就是不停地目睹各种新需求的诞生，所以就出现了上面我跟“产品经理”的日常，这次要说的话题就是关于处理需求的正确姿势。
还是上面的那个日常，之前从其他设计博客中取经的时候，也看到很多同行都有说过工作中做设计的自我修养问题，设计向来并非简单执行，把事情做完和把事情做好中间差了一万遍沟通和交流，同事、客户提上来的设计需求，如果没获取到充分的信息，了解到这一份设计需求的所运用的具体场景，就难免要反复修改，一次次修正自己的设计方向（还顺带骂一句客户煞笔），所以接到需求该问的内容，一点都不能少。
问：用户+场景+任务（此段配上大写加粗效果）
这是我被“产品经理”逼急眼后自己憋出来的固定句式，后面才发现像kentzhu、纯银、飞哥几位前辈，他们自己都提过关于这三个维度的需求观点（恩，反正人蠢多读书就好了），我抛砖引玉分享一下自己是怎么运用到日常的。
1.定义需求：目标用户在使用场景下的具体任务
接到需求后，把这个需求运用到的具体情形描述一遍，是什么客户（是否目标用户）在什么场景（归属主场景还是特殊场景）进行的具体什么业务（归属主要任务还是次要任务），基本问过这一遍后，能够基本的了解到这个功能具体情况，最好和协同的伙伴们也都沟通好这样的交流方式，具有场景感，才能让整个团队都对产品有深刻认知（因为每次我一问完，“产品经理”基本又回去确认一遍信息后才给答复…/黑人问号）
2.筛选需求：资源应该集中在最核心的需求上（人少功底薄不能任性）
车间人少地少事情多，几条业务线基本把全体忙的一愣一楞的，本着好钢用刀刃的勤俭节约好传统，需求定义出来后，再分清轻重缓急：什么客户出于什么目的提出来的需求，能否成为开发团队优先开发的理由（某车间以客户钱多为导向决定需求优先，唉····）
3.分析需求：关于做和做好
场景往往是连续的，满足需求之后产品，在完整的任务路径内应保持良好的贯通性，样式相关、逻辑一致，我原来弱鸡的时候（你现在也弱鸡啊）面对突然冒出来的需求：需要补充模态弹框，做出来的效果就整个是一种画面的脱离感，不知道还以为弹了个广告出来，沉浸式的工作状态被生生打断，这样的体验很不好，在需求合理，产品需要的时候，要把完完整整的做好，才算是好好抓住了一次让产品变好的良机。
欢迎私信交流产品，聊聊设计~ 又不要钱~
网友评论