为了让自己的设计充分解决问题，每一个设计师都会尝试收集很多同行、用户的建议，这是一个需要彼此充分沟通的过程。但是往往这种沟通会变得不那么愉快，设计者觉得对方不懂，对方觉得设计者不接受自己的意见，反馈了也没用。有了不愉快的经历之后下次可能设计者就不会去寻求更多的建议，只是凭借自己的经验去做决定。这对于达到优秀的设计起不到任何帮助。对这件事有一些简单的想法，写下来希望对大家有点用。这里的「设计」包括但不仅限于视觉、交互及产品解决方案
心态
这里的「心态」是一个广义的概念，这里主要说一下我觉得最重要的「防御心态」。这种状态一般会表现出两种情形：过度保护和过度开放（这个词可能不太恰当，领会精神）。在很多设计反馈的讨论中，很多设计师都或多或少的有一些防御心态，这样的心态会让大家觉得这是一场 Challenge 大会，一定要有赢家和输家，于是整个讨论就变得火药味十足，设计者开始保护/放弃自己的设计，反馈者忘了设计目的，不停的鸡蛋里挑骨头，最终大家不欢而散。
在反馈之初，参与双方要保持一个平等的态度，在提供反馈时注意自己的措辞，不要急于否定对方的看法，保持开放的心态，当出现「防御心态」的时候需要及时提醒对方（当然很多时候他们会觉得自己并没有处于防御心态）。Asana 的联合创始人 Justin Rosenstein，他发明了一种「D」手势，用来提醒在讨论过程中陷入「过度防御状态」的设计师，这也是一种很好的做法。
对象
这里的对象指提供反馈的人，最好的情况是你可以对所有人一视同仁，但肯定会有一些人是你喜欢与之交流的，有一些人你是比较反感的。当遇到你不喜欢的人时，不可避免的你会出现上面提到的「防御心态」，这对于收集到良好和正确的反馈是不利的，所以在你做到对所有人一视同仁之前，建议去找那些你喜欢并且你认为能切实给你建议的人。
用合适的方式完整阐述设计方案
一个好的设计反馈应该至少有 1/3 的时间是听设计者讲自己的想法，在这个过程中合适的方式来阐述方案很重要，有的人喜欢搞个 Keynote，有的人喜欢用白板，不论用什么，只要能让自己自然完整的阐述设计方案就是好的方式。
很有可能大部分人都不了解这个设计的背景、要解决的问题等等，准确完整的表达自己的想法至关重要，建议表达的思路从 Why（这个设计解决的问题是什么、为什么要解决这个问题） - How（通过什么样的思路解决、有过哪些尝试、优劣势分别是什么） - What（想过哪些具体方案、为什么最后得到这个结果、这个方案的优劣势是什么）开始，然后说明希望自己遇到的问题以及希望从反馈者得到哪类信息。我一直认为不了解设计背景和方案成型过程的人是没法给出针对性有效反馈的，所以这一步至关重要，不要因为时间原因放弃这个过程。同时设计者本身要控制好其他人，不要被其他人在这个过程中打断。
描述问题
很多反馈者会直接在反馈中说：你把红色变成蓝色，透明度降低 20%，不要覆盖界面……我认为这样是不好的，这样会使得设计者放弃后续的思考过程，直接采用对方给出的方案，而这个方案不一定是最优的。所以我认为好的反馈应该是下面这种：
这个设计面向的用户是 XX 类型，我们要解决的是这些用户从场景 A 到场景 B 时遇到 C 问题，这个设计是从 D 角度出发，如果是这样可能会引出问题 E，如果沿用该设计，那问题 E 是否需要解决？
如果这是一个问题，得让设计者感同身受，准确且清晰的描述问题，然后让对方想想如何去解决这个问题。不要急于给出自己的解决方案，让对方有过思考之后再讨论具体的方案实现。这样可以让彼此在想法上对等，信息充分之后交流效果更佳。
不要只有主观看法
主观看法没有问题，很多有趣的思路都是从主观看法演变而来的，但不要只有主观看法。「我觉得用户不会喜欢这个」、「我不喜欢这个思路」、「这个想法太傻了」如果你说出了这些话，其他人一定在期待你给出一个更好的想法，但如果你没有更好的想法，那他们就会觉得你是来搅局的，以后就不带你一起玩了，所以最好有一些客观「事实」或「数据」来证明你自己的看法，这样会让他们更尊重你。
注意用词
很多人会用「我这个人说话比较直」为由来激烈表达自己的看法，但对于某些年轻、内向、内心不够强大的设计师来说，这种对话可能会让他们并不是那么舒服，进而对设计反馈这事产生疑虑。能在一起工作的人水平也差不了太多，仔细听完对方的表述，平和的交流。
结
我们在设计中面临的问题可能是下面这样
期望的解决方案是下面这样
但实际上我们设计的解决方案是下面这样
一个好的设计反馈可以帮助我们在上线前就尽可能避免出现上面这样的结果，同时增强团队信任，了解彼此的工作和性格，更好的推进产品本身的改进。
