产品经理提需求太随意，老让设计试试怎么办？ - 推酷
产品经理提需求太随意，老让设计试试怎么办？
笑天涯说：做产品的过程中，不可避免经常遇到改交互的情况，设计师们，你们有没有遇到提需求相当随意的产品经理呢？
知乎提问：产品经理提需求太随意，老让设计试试怎么办？
问题补充：经常遇到一个这样的问题：
1，产品经理提出好几种交互方案，说要全部做出来放到线上快速测试看效果。
2，交互设计师和视觉设计师针对他的想法的一一做了相关分析并且反馈最终建议的方案，但是产品凭借自己的主观感受坚持自己的方案，或者所有的都实现，找理由说要“小步快跑，快速试错，多做几种方案试试看”。
3，但是我觉得这样很浪费资源啊，而且觉得产品经理很不负责，我会让他们提供相关的数据和证据来支撑他们的需求，但是他们提供不了我也没办法否掉这个需求；
-------------------
不要光评论对错或者只是喷PM，说说你觉得作为当事人应该怎么办？
看了一下其他答案，好像都不太到点。题主的问题应该是在交互层面，对方案中的某些要点，产品经理和设计师都没有充分的客观依据去证明其合理性，而产品方面要求进行多方案的测试，这个时候应该怎么做？
恰好最近我也在思考这个问题，并提出了一种设计方法。虽然这是一个初步的想法，未通过实践验证。但我觉得它还是有一定可行性的，欢迎大家讨论。
在此把全文贴出来。有点长，凑合着看（原文链接：
-----------------我是分割线-----------------
## 不要说「我觉得…」
很多设计师习惯用自己的经验和主观感觉去提出方案，但经验和主观感觉很可能是错误的。以用户为中心的设计，需要以用户心理、用户行为相关的客观事实为依据去执行，而非以设计师的「自我参考」去执行。
使用「自我参考」方式的设计师，经常会陷入多个选项的纠结中，这样会浪费大量的时间和精力。若以事实为依据去设计，我们应该收集足够的数据、用研和测试结论，并根据这些事实去进行决策。这么做能够让我们不浪费时间而做出正确的决定。
团队成员对设计的讨论和挑战，通常也是「自我参考」方式的。这个时候如果没有客观事实为依据，设计师很容易陷入被动的状态（这让很多设计师产生了「领地意识」的可笑观念），甚至与团队其他决策产生冲突，影响合作效率。而如果这个设计是依据某个事实结论得出的，那么这些质疑便也不足为惧了，设计师也能更好地与其他人协同工作。
所以，以事实为依据的设计是我们追求的目标。但是在实际执行中，我们会发现 设计师获取事实依据的资源非常有限。 已掌握的数据和信息很多时候并不足以对一个新的需求提供充分的依据，在前期进行严谨的用户研究和测试又会耗费过多的时间。
那么在整个过程中，我们如何高效地收集事实依据呢？
受软件开发中 Test-driven Development 的启发，我想到了一种激进的设计过程，叫做 Test-driven Design ，可供尝试。
在传统的设计方法下，设计师会花很多的时间在自己的方案上。但 Test-driven Design（测试驱动的设计）需要我们 逆转思路，将 90% 精力转到寻求事实依据的过程上，将剩下的 10% 用于快速迭代方案 ，做到零纠结、零争论，将时间省下来放到多方案、迭代和验证上。
## 用最短的时间做原型
我们的目标是用尽可能短的时间构建一个最小可用化原型（Minimal Viable Prototype，由精益创业的理念启发），以便在设计验证中使用。千万不要在这个阶段输出完整的、包含所有细节的文档性方案（即使这样看起来会比较「专业」）。
How to do?
首先要快。 使用自己最擅长的工具，维护一个高复用性的个人模版库，建立效率最高的 workflow 和工具协作体系，保持设计文件内部的干净和组织性（例如：Visio 的元素分组、PS 和 Sketch 的层次和图层命名），以便后续的快速迭代修改。
遇到自己不能确定的设计点，或者与其他人有不同意见的设计点时，首先寻找是否有已有的数据和事实支持。若没有，则 避免过多讨论，快速输出多个可行方案 ，然后准备投放到下一步骤的验证过程中。避免任何双方都无法被说服的争吵，事实依据才是解决一切的钥匙。
站在客观的角度， 避免「自我参考」或者「老板参考」的设计。时刻提醒自己：「我所知道、所观察到的，并不一定是对的」。
避免过度深入地探究未确定的细节。 要记住：现在需要的并不是一个完整的方案文档，而只是一个用于测试和验证的原型。过于精细可能是有害的，这点需要设计师通过主观的判断去平衡。
在我的经验中，通常交互设计可以在1-2小时内完成多方案原型的快速构建。对于小规模的需求，这个时间可以被缩短到分钟级别。对于视觉设计，耗费的时间会久一些，但最长不要超过一个工作日。
原型最好是动态的、可操作、高保真的。不过这也视具体的需求而定。
## 边做边验证
设计师需要接触数据、专家和用户，对多方案的质量进行验证和评估。设计验证需要穿插在方案过程中，作为对方案的即时的有力支持。
数据搜寻是最简单的获取事实依据的方法，能够解决很多纠结点。设计师应有一定的数据分析能力，熟悉自己产品的后台数据系统，并且经常去那里寻找有用的信息。
我们可以使用成本最低的 启发式评估（Heuristic Evaluation） ，通过专家和设计 leader 对方案进行筛选和建议。启发式评估能给设计师一个公开解释和辨析方案的过程，并且能发现一些可能忽略掉的要素。
但启发式评估依然是主观的。在很多时候，我们依然需要客观的用户研究方法。 这些用研方法之所以可行，是因为我们将原来用在纠结方案细节、进行无效讨论的时间节省了下来 。
使用快速、低成本、易执行的用研方法，例如用户访谈、原型测试等。
需要以对比的方式去执行用研和测试，不仅可以对比设计师的多个方案，也可以对比竞品。
测试要围绕着有与需求目标紧密相关的针对性指标进行，例如：某个流程耗费的时间、某个分支的短时间PV统计等等。方案在针对性指标的表现能够作为直接的决策依据。
在设计验证完成后，利用得到的事实依据修改、精化方案。如果方案内还有分歧点，那么就进行一轮小型迭代，准备下一次的设计验证。每次的设计验证应该越来越轻、越来越快，直到分歧点全部被消灭，我们就得出了理想的方案。这就是 Test-driven 的快速迭代过程。
Test-driven Design 与传统的设计方法不同的地方在于： 方案不再是用研的目的，相反，用研是方案的目的 ，就像编程中的 Try & Catch。方案是工具，不是目标。 目标是掌握事实，得到整个需求在用户体验层面的 insight ，方案不过是在这个过程中的附属品。
## 长期研究
既然我们已经把眼界从方案的层面提升到 insight 的层面，那么我们就能看出：设计师的工作并不是一时的内容，而是贯穿在产品生命周期中持续的工作。
那么在设计方案经过开发实现并发布后，我们还能做什么呢？
观察数据，看看之前得出的设计方案是否成功？如果没有成功，反思是哪些元素导致的？这些元素是产品上的，市场上的，还是其他方面的？
开始从各种渠道进行 长期用户研究 ，如：A/B 测试、数据观察、路径分析、用户反馈、社交媒体舆情等等。
试着发现新的问题！
在整个过程中，我们所做事情的核心在于：对产品和用户形成越来越完善的 insight。每一个用研、每一次辨析，都会让我们对产品的 insight 加深一分，都会让我们对需求和方案的把握加强一分。
我们发现： 有了足够的事实依据和 insight，方案只是顺其自然的结果！ 这就是 Test-driven Design 最强大的一点：这不仅是一种设计方法，而是一套机制，让设计师产生 insight，让解决方案顺其自然出现的机制。所以我们也可以称其为 Insight-driven Design。
这是一个初步的、激进的想法，尚未通过实践验证。但现在的设计师们需要快速对陌生领域建立认识，需要边打边走、边做边学的自我更新和协同心态。传统的、以方案为核心的方法已经不再适用了。而 Test-driven Design，绝对是一种值得尝试的工作方式。
本文整理自：
，转载请注明原作者
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致我做产品经理这些年，所遇到过的问题--百度百家
我做产品经理这些年，所遇到过的问题
分享到微信朋友圈
做产品的这几年来大大小小遇到的问题不计其数，大到整个产品的方向，小到一个图标的像素与颜色值，今天我就来说说我这几年来所中过的枪，所踩过的翔。
下面所说的问题如果你也中过，踩过那就与君共勉，没中没踩者请做好防弹准备。
一、无从下手问题
我接下来该怎么做，这是我在产品群里面听到的与我刚开始做产品时遇到的一个问题，而遇到这个问题的产品汪们一般有一个共同的特点就是，入行不久的野蛮生长型产品汪。野蛮生长型产品汪是之前一个同行定义的，我觉得野蛮生长这几个字形容的很贴切，野蛮生长型产品汪有这些特点，没有经验、没人指导产品工作、大多数奋斗在创业公司，而且还是挑大梁的，对产品知识的强烈渴望。在这个APP泛滥的年代，这类产品人员会越来越多。
对于一个没任何经验，也没人指导，还要去做决策与把控一个产品的人来说，有一种凌乱和无力感。有这种感觉的原因是因为所做的决策没有足够经验或者足够产品知识去支撑。也就是说没底气。而现在书上说的东西看了会觉得很虚，不实用。前段时间我的一个朋友刚入行做产品没多久，公司交给了他一个项目，他要我推荐一些书给他看，我就把我刚入行所看的书推荐给他，他说这些用户研究，用户体验，信息架构什么的讲的太虚了，不实际。看了还是不知道怎么做，问我有没有像工具书那样，教你第一步怎么做，第二步怎么做的书，现在是有很多这种方法论方面的书籍，但这些书对于没有任何项目经验的人来说看了，只知其表，不明其理啊，会造成天天用户体验什么的这些专业名词挂在嘴边。
第一个问题，感觉产品知识很虚，虚的原因归根结底还是没有经历一个从0到1的完整的产品流程，只有经历了，书上所讲的知识才会引起你的内心共鸣，没有经历过的脑袋当中很难有这些概念或者说这些概念不强。
第二个问题，很迫切的想要知道接下来该怎么做，产品知识比较广而杂，遇到问题后很难从杂乱的知识储备当中拟定有底气的解决方案，光凭自己看书或在网上看文章博客获取知识很难吧这些知识串联起来，形成一个自己的产品知识体系。所以前期要做的是把所获取到的知识归纳整理，形成自己的产品知识链条，再次获取到新的知识的时候。把这部分的知识对号入座的归纳到你的知识链条下并加以分析与理解，当你的产品知识达到一定的储备量的时候，你再遇到问题的时候你的思路就比较清晰了、不会像之前那样漫无目的毫无头绪的瞎抓 。这里推荐用思维导图的方法去整理知识，好处谁用谁知道。
二、团队配合问题
当时在小公司小团队时这个问题不显著或者说不严重，后来到大团队时我发现这个问题就比较严重了，主要的就是，各自做各自的，不相配合，有两个方面。
第一个，产品团队内部工作流程混乱，不管是小型项目也好，大型项目也罢，多多少少会出现以下的一些情况，没有产品规划，团队成员不知道为什么要做这个产品，也不知道下一阶段要实现那些功能，产品的目标用户群是谁也不知道，或者对目标用户群比较模糊，需求评估，优先级定义，等这些需求分析必须要做的工作没有按照需求分析的流程走，当然，苦逼的产品经理有时候会身不由己，大家都懂得。产品成员各自有分工，各自会负责一些功能模块或者独立的产品，没有考虑到功能模块之间的耦合度和关联关系，都只负责自己的事，没有站在全局的角度去思考问题，有关联的模块事先也没沟通好，导致的后果就是改需求，严重的会导致产品出问题。在写产品文档的时候，一些很重要的功能没有与开发商量，自己理所当然的就往下写了，结果在开发过程中需求频频出现问题。
第二个，产品团队与其他团队配合的工作流程混乱，产品团队与，开发团队，运营团队之间配合出现问题，主要的点有这些，1，开发按照自己的想法进行开发，产品也没有及时去评审开发结果，直到上线时才发现开发出来的东西与自己想要的差得太远 。2.因为产品团队事先没提运营方面的需求或者双方沟通的不够，上线后，运营团队准备不足，导致发布后效果不佳等问题。总结发现，很大一部分问题是因为团队之间沟通不够与协作不畅导致的。目前国内外有一些不错的团队协作工具，如trello、effevo等，可以利用这些工具把各个团队链接起来，其中effevo中很赞的是缺陷管理功能很灵活，字段与流程都可以自定义，适用性很强。这样测试、产品、开发等团队把任务、计划等都记录在这个上面可以很好的提高效率，辅助沟通，帮助记录，从而避免因沟通与协作不够而出现的问题，例如：开发把任务写在上面，这时就很清楚的知道每个需求完成的时间点，从而对每个需求进行跟踪检查，这样就可以很好的保证产品质量。
三、沟通问题
主要遇到的沟通问题是，信息不同步，信息传达不准确，偏重口头沟通。
信息不同步
主要是有的成员知道，有的成员不知道，有可能出现的问题就是不知道的成员做的一些工作有可能白费了。最近就遇一个比较典型的问题，在开发过程中，因为时间原因开发计划有小变动，而这个变动没通知到测试（自以为测试知道了），庆幸的是没造成工作白费。
信息传达不准确
主要是对信息理解的偏差，按照自己的理解和想法去执行，也没有与信息发布者进行反复确认，从而导致工作返工，造成资源浪费。
偏重口头沟通
经常遇到的就是有些需求没写到需求文档中去，或者是漏掉的，在开发过程中就口头与开发讲解，有些逻辑复杂的需求，在口头讲解的现场是无法想得很全面的，也没有及时更新到需求文档上面去，会造成需求实现有偏差或者隔了几天都忘了这事了。解决这个问题的方法就是永远不要“我以为”加沟通、沟通、沟通重要的事情说三遍。
四、需求变更频繁问题
需求变更频繁问题在团队中是一种司空见惯的现象了，貌似到了变更是正常的，不变更就不正常了的一种境界了。变更可以原谅，但不要频繁。
变更的原因可能是因为外部或者内部的原因。外部原因是指公司环境，市场环境，老板的决定等原因，这些原因可能是无法抗拒的，但内部原因是可以避免，如：尽量避免自己的逻辑不清晰，加强对文档质量的把控，不清晰或者不确定的地方多与团队成员沟通，不要抱有到时候再说的想法等。
以上是对自己刚入行所遇到一些问题的归纳与反思，希望对你们都有帮助。
本文系作者@杰森森 授权发布。
分享到微信朋友圈
在手机阅读、分享本文
还可以输入250个字
推荐文章RECOMMEND
阅读：4146
阅读：1092
阅读：10万
热门文章HOT NEWS
Uber无人车正式在旧金山运营，这是9月份Uber公司的无人车...
百度新闻客户端
百度新闻客户端
百度新闻客户端
扫描二维码下载
订阅 "百家" 频道
观看更多百家精彩新闻当前位置：
运营如何提需求？不要只想着靠产品经理！
运营如何提需求？不要只想着靠产品经理！
&产品需求的分类产品需求可以从以下几个维度来划分：1.外部需求和内部需求：前者来自各个渠道收集的用户反馈，如微博、微信、QQ群、客服邮箱、客服电话，以及产品自身的反馈渠道（如论坛的客服专区、在线即时咨询窗口等）；后者来自公司内部，如老板和其它部门提出的需求。这些反馈通常都不会很明确，需要运营同学进行整理挖掘、沟通调研进而提炼出需求。如果不经整理提炼就统统丢给产品跟研发同学去处理的话&&会被鄙（qia）视（si）的&&2.改进型需求和新建型需求：它们俩是从1到10和从0到1的区别。我个人的建议是已有的产品如果改进优化后能用，尽量不要另起炉灶，除非是原有的产品从定位到风格全都跟新需求不一致。这里一方面关系到效率，能否快速运用已有产品达到业务目标，而不是只能等着新产品上线错过宝贵的窗口期；另一方面关系到借势，是否能够借助已有的流量或者品牌优势来加速业务目标的实现。这就要求运营对公司内部现有产品定位跟功能了如指掌，对公司外部可以利用的现成平台和资源也非常熟悉，从而能够根据需求制定出合理的问题解决方案，有时甚至可以不需要产品改动和新增就能达到目的。比如：做一个媒体，先以微信公众号起步，就比直接开发一个App实际地多；要推广一个新产品，是自己从零开始建一个产品官网一步步做内容做流量拉用户来得快，还是和能够直接接触到该产品潜在用户的渠道合作来得快？最怕的是拍脑袋就做个产品，不考虑是否能利用已有的平台资源，导致留下一堆半截子工程，说能用也凑合能用，但又缺乏清晰的定位和维护，后期运营推广也不好做；同时系统里留下很多冗余代码，如果负责人一离职就再也没人能说清这产品的来龙去脉，于是又推倒重来一遍&&对人力物力都是极大的浪费。3.笼统型需求和精确型需求：前者如：「现在这个编辑器太难用了换一个吧，好多代码格式都不支持」；后者如：「需要一个除现在支持的代码格式外，还能够支持markdown语法的编辑器」。很多用户反馈的需求就是前者那样的，必须深入了解分析，否则过于笼统不具体的需求，是无法实现的。即使勉强上马，也一定会因为需求不明确而导致工期延误和反复修改，最终应付了事，所有参与人忙得够呛都不开心，宁可早期多用一些时间把需求搞清楚。4.解决问题的需求和提高效率的需求：例如：「我需要一个能给用户群发邮件的后台」和「我需要能够自己导出符合某些特征的用户邮箱列表给他们群发邮件」。不过后者需要评估使用频度，如果是高频使用需求，开发一个还是有必要的，否则每次都要找研发同学给导出邮箱也确实麻烦如果是为了某个临时性的项目用，或者一年也用不了几次的低频需求，那就没必要开发一个专门的功能了。为什么要从这些维度来划分呢？因为实现产品需求的资源通常是有限的，因此必须对需求的合理性和优先级做出明确判断，并以此来决定开发的资源投入以及排期先后。另外有些似是而非的「产品需求」，实际上并不是需求而是bug，bug和产品需求的区别及处理方式的不同如下：产品需求：&针对还不存在的功能提的&解决的是「不好用」的问题&实现周期通常较长&发给产品经理处理（这个要看具体团队构成和分工，是否有专门的产品经理来处理需求，如果运营兼负责产品那就由提出需求的同学自己处理了）产品bug：&针对已经存在的功能提的&解决的是「不能用」的问题&解决时间视bug严重程度，通常要求尽可能快地处理&可直接发给研发人员解决产品需求描述产品经理通常需要把收到的各路需求整理成产品原型文档，但对于运营同学来说并没有那么严格的文档要求，只要让产品同学能够明白你的意思就可以；不过为了提高沟通的效率，有必要参照一定的格式来描述你的需求，这里举个我现在团队的例子：1.需求名称：产品名称+功能+提出时间，如「编辑后台改进产品需求-」2.目的：有助于产品同学充分理解你的需求的必要性和重要程度，如「为了提高编辑发稿的工作效率」或「为了统一网站整体风格而进行UI重新设计」。3.优先级和时间要求：这个也很重要，因为产品经理通常会收到大量的需求，如何安排优先级处理顺序？如果你在需求里有明确的说明，那么处理效率会高一些。如「第一优先级，需要六月15日前完成」。4.需求描述：说明用户身份（外部用户和内部用户的处理方式有区别），页面需要包含哪些元素，期待的布局和风格，排列顺序，是否必选项，有何特殊要求，是否需要查询及查询条件设定，是否需要权限管理等信息，尽可能详细，最好给出参考案例或类似竞品截图。什么情况下需要提产品需求如果以上你都已经烂熟于心，对于如何提产品需求应该是没有问题了。但是且慢，知道怎么做只是最基础的，对于合格的运营来说，更重要的是判断要做什么和不做什么。用户的需求永无止境，运营不能只是需求的传声筒，需要深入分析用户需求背后的目的和隐藏的问题，如果能够用已有的产品达到的，就尽量不要重复建设做新产品；如果能用运营的手法解决的，更不必兴师动众地动用产品和研发；如果能够利用已有成熟的渠道跟平台借势推广的，又何苦非要做一个「自己的」独立平台一切从零开始呢？做加法永远比做减法容易，另起炉灶似乎也比在原有基础上修补改进要痛快（某些情况下，也被看做是业绩的体现）。但是资源永远都有限，无论是人力还是时间，即使你有一组强悍的产品和研发同学 24 小时无条件配合，仍然要评估需求真实的价值有多少，衡量投入产出比。运营的强项在于给你一个产品，你能够发掘它的一千零一种用法（玩法）并将其传递给用户来满足业务的需求，如果一接到新需求就要做个新产品，而不是先看看运用已有的产品是否能够解决问题，运营自身的价值何在呢？案例一：数据分析后台曾经有同事负责运营一个垂直专业领域的群组，提出要做一个数据分析后台，能够根据加入群组用户填写的个人信息自动生成各种维度的分析图表，「就像专业的数据分析报告那样」，他说。这并不是一个实现起来很简单的需求，虽然对用户的数据分析是有必要做的。但是该群组目前的注册用户只有几千人，且新用户增加速度非常缓慢，用户数据分析的时效性并不是非常高。因此最终解决方案是导出用户数据到 Excel 中，运营自己根据统计需求，利用 Excel 生成分析图表，至于是否像专业报告，那就看自己的 Excel 造诣啦~如果未来用户量和增长速度达到一定规模，人工统计无法满足，才是需要开发数据统计后台的时候。案例二：大会报名 App我所在的社区运营团队曾经负责组织公司的开发者大会报名，通过社区各个渠道向开发者用户进行宣传，使用的是社区的活动报名系统，可以汇聚各个渠道的报名数据到后台数据库。有同事提议说开发一个大会报名 App ，以后组织大会都可以让用户通过 App 报名，这样推广时只要通过 App 推送提醒就可以啦~~~我说你这个创意不错，你先想法让用户都装上这个 App ，然后。。就没有然后了&&总之收集到需求后，先问自己以下几个问题：&目标足够明确吗？&已有的产品确实无法满足工作要求吗？&已有产品的缺陷已经极其影响工作效率吗？&成本是否合适？&如果答案有任何一条是否定的，那就需要重新审视这个需求的合理性，并且和需求方积极沟通确定最终解决方案。什么情况下需要提产品需求&需求表述明确，沟通清楚，提交流程规范：该自己做的一定要做到位&按流程提交需求后最好再当面跟产品经理沟通，尽快落实需求并启动&必要时要舍得砍需求，确保快速上线&充分利用各项资源来达到目标：平时和产品设计研发同学搞好关系，甚至必要时通过老板推动都是方法（但此大招不可常用）&产品改进通常落后于业务需求，这是正常现象&互联网产品改进伴随整个产品的生命周期，不是一次性的&产品改进通常是由运营驱动的，由产品（不了解运营）驱动的多半失败&再好的产品，不重视运营也是白费&对内容运营和社区运营来说，产品是辅助手段，不是目标&具备一定产品能力的运营会有更多的职业发展机会&文章来源：鸟哥笔记文章作者：张媛
分类：| 发布：| 查看： | 发表时间：
原创文章如转载，请注明：转载自人人都是产品经理、产品经理、互联网产品经理学习交流平台　
本文链接：
| Power By Z-Blog 1.8 Walle Build 100427.