在 UX 设计领域有一句老话，可用性测试不该由设计师自己来执行。虽然听上去是没错的，但真的是这样吗？实际上，作为团队中唯一的UX专家，UX 设计师一直在测试自己的设计，如果他们不去测，那么根本没人能测试。所以我们有个疑问，“测试自己的设计”，真的是弊大于利的吗？
很多人曾就这一话题发表过文章，包括 PaulSherman 自 2009 年起在 UXmatters 上做的很棒的专栏。但是，作为一个全面体验过这个问题的人，我想给出一个不同的视角。我测试了自己的设计，并让其他人分别测试了我的以及别人的设计，从中体验到了每种情况的利弊。在这篇专栏中，我们将讨论高效测试自己的设计的可能性，并给那些需要做可用性测试的 UX 设计师提一些小小的建议。
当测试结果没有找出明确的问题和解决方案时，你就会不由自主的放大那些能支持你想法的结果，而搁置那些不能支持你设计决策的结果。
首先，我们来看看认为最好不要自行测试的人，他们的几个观点：
你无法对自己的设计保持客观
对自行测试最大的争论是，设计师往往在自己的设计上付出了太多心血，所以很难保持客观。即使你努力保持公正并意识到自己潜在的偏见，也很难保证完全没有偏见，这些将影响你的肢体语言，以及你对测试参与者要问的问题和不问的问题。偏见会影响你对测试结果的分析和诠释。尤其是当测试结果没有找出明确的问题和解决方案时，你就会不由自主的放大那些能支持你想法的结果，而搁置那些不能支持你设计决策的结果。
你太过于熟悉自己的设计
作为 UX 设计师，你比任何人都要了解自己的设计。你了解设计中所有的需求、决策、技术限制以及利弊权衡。所以，和普通的测试参与者第一次使用产品相比，你对产品的看法是非常不同的。你自身的知识也让你很难从用户的视角去看产品。
你可能迫于压力不想找出太多问题
可用性测试是它是有助于赋予设计以思想的一个迭代的、习得的活动。它是自然发生且期望发现可用性问题的，并且这些问题不应片面地归咎于设计师。
关于可用性测试最健康的态度是，它是有助于赋予设计以思想的一个迭代的、习得的活动。它是自然发生且期望发现可用性问题的，并且这些问题不应片面地归咎于设计师。
不幸的是，并不是所有的公司对测试都持有这种健康的态度。当一个公司将可用性测试看作是对设计和其设计者的评估时，任何小的问题都将片面的归咎于设计师。在这样一个不健康的氛围下，测试自己设计的设计师会有强烈的意愿不要发现太多的问题。当第一次可用性测试安排在设计流程后期时，问题尤其明显，因为在后面的阶段发现了主要问题将导致主项目的延期。
其他人会察觉到这其中存在利益冲突
即使一个公司对可用性测试持有健康的态度并且设计师也尽了很大努力保持公正，其他人也仍会察觉到其中利益的冲突。他们可能用这个顾虑作为原因来反驳他们不认同的成果和提议。
将设计和测试的工作分给两个人去做会更有效率，会让你更快完成可用性测试，并缩短整体的开发周期。
虽然雇佣一个可以同时完成设计和自行测试的“通才”好像会给公司节省经费，但对一个人来说，这可是大量的工作。设计师通常忙于设计和制作原型以至于没有时间去计划测试、招募测试参与人员、进行测试会议和分析数据。将设计和测试分给两个人可以让他们能同时进行这些工作。这会更有效率，会让你更快完成可用性测试，并缩短整体的开发周期。
提供诚实的反馈时对参与者来说可能会很尴尬
直接对设计者提出批评和负面的反馈往往会让参与者很尴尬。反而，他们会努力表现得礼貌并降低批评的力度。无论何时我测试别人的设计，我都会强调：“我没有参与设计，我只是被要求收集测试者的反馈。所以如果你们狠狠的批评，也并不算是冒犯我，也不会伤了我的心。”参与者这时往往会开心的笑并觉得更自在，也更可能给出他们真是的观点。但是，当我自己是设计师，测试我自己的设计师，我很难发自内心的那样说。
作为设计师，没有人比你更懂这个设计。你清楚所有设计流程中的决议、疑问、异议和利弊权衡。
尽管有很多有力的原因支持不要自行测试，但自行测试仍有很多益处。我们来一起看一下。
你比任何人都更了解你的设计
作为设计师，没有人比你更懂你的设计。如果你搞定了投资人和用户调研，你就是最熟悉业务和用户需求的人。你清楚所有设计流程中的决议、疑问、异议和利弊权衡。所以你是计划可用性测试最合理的人选，你可以确保测试专注于解决最重要的问题。
你比任何人都更了解你的设计原型
作为原型的制作者，你知道哪些链接、按钮、交互组件是可用的，哪些是无效的。你知道怎样是行不通的，测试过程中有异常的情况发生之前，你最清楚怎样让参与者回到正轨。如果一个原型组件是无效的，你可以向参与者描述它怎样正常运行。如果你需要修复原型中的一个问题，你或许能够在试验间隙完成。
通过测试你可以获取第一手资料
有了对实验结果更深入的了解，你就能更好决策出哪些设计模块是需要改变的。
理解设计结果对 UX 设计师来说是无比重要的。那么还有比亲自去开展和观测测试更好的方式吗？没错，设计师可以简单的观测测试，然而，想让测试效果更好，就需要付出更多的注意力和互动在参与者身上，而不是简单的被动的观察。另外，这让你可以实时询问问题。有了对实验结果更深入的了解，你就能更好决策出哪些设计模块是需要改变的。
你可能是最能胜任测试工作的人
有些人可以同时熟练的完成用户调查和设计工作并热衷于两者。当你已经做过用户调查并完成了设计，你可能很难再将可用性测试交付给其他人去做。最在乎设计的是你自己，所以你是最了解情况也是最有动力去做测试的人。
即使你认为让其他人来测试你的设计更理想，但这并不总是可行的。当一个公司没有可用性测试方面的专家，通常会让另一个没有参与这个项目的设计师来代替执行测试，但对于进度比较赶的团队，就连这个他们都难以做到。所以，当没有可用的其他人选来做测试时，让 UX 设计师自行测试自己的设计肯定要比完全跳过可用性测试更可取。
关于可用性测试的小建议
提醒你的客户和项目团队，可用性测试是一个不断习得的过程，它的目的就是找出问题和解决设计上的疑问。
不管你认为设计师不要自行测试为好，还是设计师可以自行测试他们的设计，这里都有一些方法让这些情况发挥最大作用。
当你需要测试自己的设计时，下面几个小建议可以帮你躲避之前提到的问题：
提醒你的客户和项目团队，可用性测试是一个不断习得的过程，它的目的就是找出问题和解决设计上的疑问。提倡这种健康的关于测试的态度，避免将测试作为一个设计师的技能评估。
进行至少两轮可用性测试，并在设计的早期阶段就开始进行。这会使你能够在开发周期中较早发现并修复问题，而越早做出设计上的改变，时间和经济成本越小。当你有时间去修复发现的问题是，这些问题看起来不会是那么灾难性的，然后，再次测试。
针对解决方案的多个版本比较测试。这会让测试的焦点从评估一个设计或是设计师的能力重新回到哪些版本有效或无效的比较。比较测试将测试的调子变得更像一个不断习得的过程。
当你开始项目的可用性测试阶段，努力给自己一种置身于可用性测试中的心态——和原来的自己划分清楚，你已经不再扮演设计师的角色了，反而，你要将自己想象成一个中立的可用性测试专家，努力和那些设计保持距离。
努力让自己进入一种中立模式，简单地询问问题并记录参与者提供的信息。不要去辩护自己的设计或解释为什么自己确信要那样做。想象你是一个演员，接手了一个可用性测试员的角色，而不是你平时的设计师的角色。
努力做一个不含偏见任务和问题的讨论指南。因为这很容易会不经意间包含进去一些带有偏见的问题，所以让一个有测试经验的人检查一下你的讨论指南，这样他们可以指出那些存在潜在偏见的和具有一定引导性的问题。
告诉参与者你在测试一个早期设计，目的是发现和解决问题。让他们消除顾虑，知道你要的是他们真实的反馈，不论好坏，并且怎样都不会伤害到你的感情。当然，你绝不应该不诚实的声明或暗示这个设计方案不是你的，但是，你不需要主动说明你就是设计者。
如果你不确定自己是否能不带偏见，那就严格按照讨论指南，坚持只问指南上有的问题。
专注于客观地记录你听到和观察到。尝试着在测试期间得出结论和感悟是你作为设计师的偏见在误导你。（别在测试时着急得出结论）
当你报告测试结果时，直率的承认设计的问题和失败。客观地讨论自己设计中问题和成功的能力会提升你在其他人心中的可靠程度。将发现可用性问题当作是能改进设计的一次有价值的学习体验。
在任何研究活动——整个设计过程以及可用性测试期间，与用户研究者保持紧密的工作联系。
如果其他人将要测试你的设计，下面几个小建议会让这种情况达到最佳效果：
让将要执行测试的人在项目的一开始就参与进来，以确保这个人可以充分理解业务需求、用户方面的问题以及设计的演化。避免将一个对项目一无所知的人带进来做测试。
在任何研究活动——整个设计过程以及可用性测试期间，与用户研究者保持紧密的工作联系。尽管用户研究者主要负责用户研究和可用性测试而你主要负责设计，但保证这些不是分隔开的活动。
当可用性专家准备测试时，给他一个清单，上面包括重要的测试项目、你对设计的疑问和客户或其他项目组成员对设计的关注点和疑问。
观察每个测试会议并进行记录来保持专注。
在讨论结果和得出潜在解决方案的过程中与测试人员合作进行。
当你的团队没有专门的用户研究人员而只是由UX相关的人员组成时，设计师可以互相测试彼此的设计。然而，你仍然需要帮他们了解项目的细节，观察测试并在解读测试结果的过程中与他们保持紧密的工作联系。
理想的情况
理想的情况是有一个用户研究人员和一个设计师在项目中共同在用户调研、设计和可用性测试等环节紧密合作。
在我看来，理想的情况是有一个用户研究人员和一个设计师在项目中共同在用户调研、设计和可用性测试等环节紧密合作。当然，这并不是经常能实现的。所以，如果你必须自行测试自己的设计，按照这篇专栏中提到的建议，你可以将潜在可能发生问题降到最少。
原文作者：Jim Ross
