设计师如何避免“我觉得”
很多设计师在日常设计方案讨论或评审过程，经常听到他人对自己设计稿做出类似“我觉得这里很奇怪啊”、“我觉得这个有点诡异”的意见反馈。这样的反馈通常会让设计师很完全找不优化和改进点。一千个观众眼里就有一千个哈姆雷特，如果每个人都以“我觉得而不是你觉得”作为意见，那只能让讨论陷入无限的争执中。有时也会出现忽略设计的合理性，直接顺从位高者的决策。
作为设计师每每遇到这样的情况都会觉得自己很无助，似乎设计这件事情超出的自己掌控范围，而自己有时其实也会不经意间脱口而出那句“我觉得”却无法表述合理的理由。那设计师该如何尽量避免这样的情况发生：
1.提升沟通技能
2.把控设计评审
01
提升沟通技能
1.“我觉得”改为“我认为”
“我觉得”可以理解为长期形成口头禅，但说着无意听者有心，当你说出这三个字的时候会让大家内心感觉到你的意见更加的主观，依靠的是个人喜好而没有理性的思考，毕竟做设计不等于搞艺术，我们还是需要经过理性思考并对齐产品目标的。可以尝试将“我觉得”改为“我认为”。觉得是感性的，缺乏理性分析。认为是理性的，是经过思维分析判断的。
2.表述合理的理由
如果这样的口头禅一时无法改变，我们可以尝试将我们的观点表述完整。例如，“我认为这里适合使用暖色，而不是冷色，暖色能更好的烘托喜庆的气氛，使用强烈对比色更正凸显主体...”。这样的表达要比“我觉得这里用该用红色”能更好的表明观点，也能让对方更好的明白自己的意图，并确定接下来的讨论方向。
3.探其原因
不让自己陷入困惑当中，那就要对意见提出者深入追问。我曾经遇到过这样的情况，评审中有人提出“我觉得这里的颜色需要优化一下，感觉不高级”，设计师追问什么颜色才会让你觉得高级，这时他回复“网易严选那个样子”， 对方认为网易严选给他带来了高级感，设计师继续追问哪些元素或者设计能让你感到高级。设计师通过深入的沟通，就能不断的接近对方对高级感的理解。后续可以对高级感继续优化和探索来符合用户心智模型。
4.提升专业表达能力
无论是交互逻辑还是视觉表现给方案体验者带来了不符合预期的结果或者用户体验不佳，这时就会提出不同的观点。设计师更应该使用专业的词汇来描述。例如，设计师在不同页面类似功能使用了不同的交互操作，我们可以说此设计没有遵循一致性和标准化原则，没有使用统一的风格元素、相同交互操作和功能没有保持统一。专业的表达能力还需要设计师经常去积累一些设计原则并不断完善走查文档，将这些内容熟记于心。
02
把控设计评审
在日常项目中设计稿通常会通过内审、小组评审、项目宣讲、部门评审等多轮评审环节。做好设计评审能够提升设计师水平、提高设计方案的质量以及获得新鲜的视角。跨小组的部门评审更有助于促进知识分享、增强合作交流并提升团队整体水平。
通常内审、小组评审的参与人员为设计师或设计行业专家，项目宣讲的参与者大多是产品经理、开发人员和运营人员，部门评审多为领导和身边同事。对于设计评审应该以更加专业的态度来对待，有理有据的分析设计方案，避免出现“我觉得”。
1.启发式评估(专家走查)
参与内审和小组评审的设计师或行业专家，都具有专业的设计能力，因此通过设计评审可以获得设计上和业务上的反馈与宏观层面的启发。
启发式评估可以在短时间内发现许多重大的可用性问题，当然评审结果会受到评审专家知识水平影响。启发式评估的特点：
a.评审专家以启发性规则为指导，评定用户界面元素是否符合原则；
b.评审专家模拟典型用户使用产品的情形，从中找出潜在的问题；
c.参与评审的专家数量不固定；
d.成本相对较低，而且较为快捷，因此也称为“经济评估法”；
e.精度不高。
评审专家通常根据事先准备好的走查表(可根据自身经验添加条目)，进行可用性走查。评审专家不以个人偏好为判断依据，主要以理论依据给出建议，除了发现问题外还应给出合理建议。通过启发式评估可以更好的避免评审过程中反复飘荡着“我觉得”却又找不到依据的情况。
简单易懂的启发式评估法则：
最终形成启发式评估报告，报告应该包括出现问题的关键位置、违反的启发式评估规则、严重程度、和改进建议等。
2.认知走查
项目宣讲的参与人员中产品经理、开发人员和运营人员占大多数，他们给出的意见不会像启发式评估那么专业。因此，在项目宣讲前设计师可以提前对参与评审人员组织认知走查，以便提前收集大家意见。
认知走查是模拟用户在使用产品过程中的每个操作步骤所遇到的问题，检查用户的任务目标和心理认知是否可以顺利执行下一步操作，针对每步操作提出四个问题：
•是否知道自己要做什么？
•在探索用户界面的过程中是否注意到操作方法？
•是否把自己的目的和正确的操作方法关联到一起？
•能否从系统的反馈中判断出任务是否在顺利进行？
通过回答每个操作步骤的问题，就能发现可用性问题。
认知走查步骤：
3.可用性测试
相对于以上两种方法，可用性测试的执行成本较高。不是所有的产品和功能都要做可用性测试的，比如一个表单、一个字段的修改等等，是不需要去做测试的。很多公司都不会去用可用性测试，有时是因为觉得产品没有问题，用户都会用，有时是设计师没有这个意识去做，长此以往过上了YY的生活。完整的可用性测试包含8个步骤。
步骤1：需求收集
在进行可用性测试之前，设计师要收集组内需求，让相关角色来根据模板填写并进行汇总整理。
步骤2：资料准备
一般大公司都会有专业的测试实验室和专业的测试设备，对于中小公司通常配齐不同型号的测试机或电视即可。如果是邀请外部人员测试，还要准备好报酬或礼物。
步骤3：用户招募
用户招募通常根据需求收集阶段要测试需求量的大小以及需求的多样性来决定。通常我们会通过公司对符合一定条件用户招募，例如至少使用过一次该功能。当需要与行业或竞品公司对标时，会通过外部平台进行用户招募，测试时也不会透露具体公司，以便用户能表达真实的想法。
招募时我们可以对用户进行分组。小白用户、大众用户、深度用户等，他们对产品理解和态度会有一定的偏差，测试时也应分组测试以免陷入分歧或表达不充分。
步骤4：测试任务设计
设计师要明确需要测试的任务和重点，当功能较多时需要作出取舍。测试时主持人需要进行暖场将用户引入场景中在开始测试。过程中不断活跃现场气氛得到并记录用户的反馈。通常测试时长40~60分钟，过长的测试会让用户疲惫使得效果大打折扣。
步骤5：预测试
在正式开始之前，应当将测试设备准好并按照正常测试流程完成一遍，保证测试过程顺畅。
步骤6：开始测试
测试通常会在实验室进行，为了能及时解答现场的困惑通常会有产品经理、设计师和运营人员在场以保证充分的沟通。测试开始前主持人要进行暖场将用户引入情景，测试过程中不断鼓励用户发表自己的看法。当讨论问题偏离测试主体时要及时纠正。实验室背后的观察者也应该保持安静并关闭闪光灯等能产生光亮的设备。
步骤7：输出分析报告
测试完成后会反复查看测试记录、录像等内容，将关键问题、重要问题、次要问题做出区分，哪些问题阻碍了用户顺利完成任务，在功能上线前根据重要度依次优化和解决。有些测试可能涉及一些新的问题，也应该作为未来的优化方向。
03
总结
如果你在团队中有丰富的经验，并且你的设计通常会获得团队的赞许，以往项目中你的假设方向验证后均取得了正向的反馈，当你说出“我觉得”会获得其他成员的认可。但对于大多数设计师仍然要增强自身沟通能力的软实力和专业知识的硬实力，通过不断提升自身影响力，辐射和带动周围同事走向更专业的沟通和表达。这样才能共同破除“我觉得”困扰。
参考文献
啥都别说了，点它就对了