在Facebook，我们以开放的企业文化而感到骄傲。我们每个产品研发阶段就进行产品内测（即Dogfooding），内测结果通过公开讨论反馈到开发团队，这就是一种开放式的交流。
这篇博客一开始我是写给内部同事的，主要想传达什么样的反馈能够提高产品体验。大多数的建议也适用于其他公司，你也可以给那些你未参与开发的产品提供建议和反馈。因此，我想更大范围地分享这篇博客。
当你给出了有价值的反馈，你是在...
· 展现一个被忽视的用例，或是报告一些设计时未预料到的情况。
· 和团队分享你的案例，这个过程如何，怎么结束的。
给予反馈的目的是通过提升产品来更好地服务用户。因此，
最好的反馈，最有可能建立起“同理心”，也最有可能促进产品的提升。
当你给予无价值的反馈时，别人会觉得你是在...
· 炫耀你有多机智。
· 打击团队积极性，即使带来了幽默。
· 代表整个世界在发言。
没有意义的反馈会让产品团队带有防御性，而不是更加有同理心。处于防御状态时，他们不太可能听你谈论，也不太可能会去优化产品。当你的反馈不可能提升用户体验时，说再多也没用，只是浪费大家的时间。
小建议
1. 用户场景输入
帮助产品团队理解哪一类的用户给出如此反馈。在你表达观点之前，先向团队阐明你的背景（并非你的日常工作——你的任期和专业水平与此并不太相干），当你体验某个功能时，你是哪一种类型的用户，这才是重要的；同时告诉大家，你当时正尝试着完成什么任务。
2. 为你自己代言，但不要太激动
客观地去描述你的期望值，描述确实发生了什么。
聊聊你的特殊经历“我有个疑惑”而不是概况性地说“这让人疑惑”，或者“这会让用户疑惑”。聊你的具体案例，会让团队放下防卫心理，有效地与你“同理”。
最糟糕的阐述是“没人会喜欢/用这个”。
太激动的言论，不太可能引导产品团队从一个新的角度去重新思考他们的原有工作，去改变套路。
如果你是在转达他人的反馈，要知道你不是简单地转达。因为你非常肯定那人在使用产品时心情糟糕，满心纠结。这样的反馈也是有价值的，你知道这些体验是怎么来的。记住，反馈用户体验，重点就是去创造“同理心”。笼统地说“大家会讨厌的”，不起任何作用。
3. 问“我们为什么这么做”
如果你很难理解产品某个功能的用意，同时沮丧无助不会使用，那么就向团队提出质疑“这为我们服务的对象带来了什么？”，抛出问题后让团队思考。
这看上去有一点像被动式地挑衅，因为主动去臆想产品的设计初衷然后责怪团队的漏洞——这不妥当，上面的方法要有效得多。很有可能有一些终端用户数据是你所不知道的，（而团队掌握了这个信息）。当团队不能清楚地表达出产品对用户的价值的时候，才会恼火其实不应该那么做。
有一百万个理由可以用来解释某件事情的结束。也许团队没办法去做用户研究、找出所有的用户场景和潜在用例。也许他们没有好的途径和资源可以利用。也许某个过程突然变得复杂，团队在尝试之后结束和放弃了一些设想。然而，所有这些与用户并不真正相关。
用户不关心为什么，他们只关心自己坏的体验。
不要因为没有具体的用户场景而急着说抱歉，或者感觉一定要为你的反馈添加一层靓丽的外衣。客观地转述一种主观体验不会恼怒任何人。如果团队找借口推脱，那么你可以重申你差的体验，重申我们应该去修改这个设计，因为我们关心的是用户要拥有好的体验。
5. 有没有提供建议也不要紧。
除非你有建设性的意见，否则别来反馈——这是一个糟糕的论调。
用户的反馈不可小觑，因为他们不是产品的设计师或工程师，也正如此，大多数用户不太可能提供专业建议去改善差体验。这同样适用于内部反馈。当你作为一位终端用户在转达你的体验时，找到解决方案并非你的任务。那是开发团队的职责。
从另一个角度看这也是合理的。大家不想提出建议给开发团队，因为他们不想
去干涉或指点开发团队的工作。干涉不太好。只要你表达出你的想法以及它会如何解决你的问题，不要藏着掖着就好。
最好的建议不是去给出一个特定的方案“把按钮放在这里......”，而是给出目标“给我一条路径到......”，其实举例阐述时也会顺带提到这一点。再接着团队就会提出解决方案，来满足你的目标，从而提高用户体验。
最后一点想法
记住，总的来说，给予反馈是为了让产品更好。最好的反馈最有可能创造共情心，促进产品提升。给出更有效的反馈，会调动团队的积极性去做些事情提升产品体验，更加服务于用户。【作者：Cemre Güngör】
