我怎么能像用户一样思考？

Question

我们现在正处于项目深处，时间紧迫（但合理）。我们的总体策略是完成强大的测试，发布测试，并从我们的测试人员那里获得反馈。

很多时候，我们受到了一些小事情的影响，这些事情会导致长时间，耗时的讨论。它们都归结为一件事：虽然我们知道我们需要什么功能，但我们在处理细节方面遇到了麻烦，例如“这条消息应该去哪里”和“他们是否需要立即反馈，或者它会破坏它们的流量，所以我们应该推迟'？

这些都是我们的测试人员应该抓住的东西，但是

a）像这样的每个“低优先级”错误会从关键问题中消耗时间

b）我们希望拥有尽可能强大的产品

和

c）即使是最好的测试组也会不时错过。

我们使用我们的产品，并且我们知道我们的用户如何使用旧版本......但是当我们尝试使用新版本（具有重要的图形时）时，我们都不知道如何像用户一样思考以及潜在的变化）。

编辑 - 更多背景：

我们正在撰写广泛分布的用户群使用的网络应用。我们的应用程序是他们工作的重要组成部分，但不是最大的（当然，当它不起作用时，我们只对它们很重要）。让实际用户使用我们的产品很困难，因为我们在地理位置上距离最近的用户位置（我们在俄亥俄州，我认为距离我们最近的位置是3个多小时）。 / p>

我们能得到的最接近的是我们的客户服务团队（他们真的是一个很大的帮助），但他们并不像用户那样思考。他们也是我们的测试人员（当他们知道任何他们找不到的任何可能意味着电话数量大幅上升时，它确实激励他们发现错误）。本周大部分时间我们有三位（总共约12位）客户服务代表在这里进行一些初步测试......他们也参与了讨论。

Answer 1

观看某人使用该应用对我来说是一个巨大的好处。可能是某人并不完全熟悉它。

了解他们如何尝试导航，他们如何尝试输入信息或调整窗口大小。在创建/运行应用程序后，我们认为这是理所当然的。

用户总是会尝试做你从未预料到的事情，并且观察他们的行动可能会揭示你如何改变可能看似微不足道的东西，但确实会对他们产生重大影响。

Answer 2

阅读Don't make me think。

Answer 3

一般来说，你做不到。没有任何方法可以关闭大脑中的“程序员”部分并像用户一样思考。

你是对的（c），测试组不一定能抓住所有的bug。但是你能做的最好的事情就是让一个由真实，诚实到善的最终用户组成的测试小组，并重视他们的反馈。从他们的一般性评论中得出进一步的结论。

如果您想知道用户将如何看待您的系统，那么您可以获得的最接近的是真实用户的可用性测试。其他一切只是启发式和经验，也会出错。没有无错产品这样的东西，但你应该能够通过可用性测试获得“强大”的产品。

Answer 4

购买便宜易用的摄像机，并使用该应用程序记录您的测试人员。更好的是，让一些人不熟悉应用程序。使用它并录制它们。它相对便宜，你会惊讶于它会突出显示。

Answer 5

我喜欢“吃你自己的狗食”的政策（“http://en.wikipedia.org/wiki/Eat_one's_own_dog_food）。它会让你更近一步，因为你成为一个用户，虽然你可能会想到一个。

Answer 6

当您非常匆忙时尝试使用您的应用程序（例如，您有人等待晚餐）。 你会看到所有这些小东西，因为你必须等待，你必须回到键盘的鼠标等。

而且，让你的妻子使用它。或者你的母亲。

另一个有用的测试：帮助某人通过电话使用它。如果他找不到带有方向的按钮，那可能就是一个错误。

Answer 7

重要的是要获得足够的信息，你自己可以become a "user"。一旦你这样做，你可以自己回答大多数问题。

我一直这样做的方式是与他们讨论他们需要做什么，他们通常做什么，以及他们如何使用他们当前的工具来做。然后（非常重要）在他们这样做时与他们坐在一起。确保你能够很好地使用它们，以便你可以回过头来询问他们如何处理你后来想到的边缘情况（通常答案是令人震惊的“我们为此手动绕过系统”）。

我几乎总会注意到他们正在做的事情，这是他们没有提出的皇家PITA，因为他们已经习惯了这样做而且不知道更好。我将始终注意到他们的％90典型工作流程并不是工具提供的最简单的工作流程。

你不能真正依赖简单的老式需求收集，因为这要求他们像开发人员那样思考。他们通常不知道什么可以用你的软件，什么是容易，什么是困难。他们通常也不了解GUI设计原则。如果你问他们设计输入，他们会告诉你在他们喜欢的页面上放置任何新的控件，直到看起来像747控制面板。

Answer 8

问题往往是，即使用户在实际使用软件之前也不知道他们想要什么。有时候，一个小的疏忽可能是一个很大的可用性问题，有时很多用户要求的经过深思熟虑的功能看起来很少用。

我建议降低不实施正确的可用性功能的风险：

• 看一看实际做日常工作的用户。即使他们使用其他软件或根本没有软件。您将能够确定他们完成工作所需的工件。您将看到他们经常需要的数据。专注于最常用的工件，数据和工作流程。它们应该是最有用的。与常用的工作流程相比，异乎寻常的工作流程对用户来说可能更耗时。

• 使用GUI的工作原型让用户完成真实的工作流程。观察它们并注意阻碍它们的因素和效果。相应地调整原型。

• 如果软件中经常使用的部分出现问题，现在是时候详细讨论了。如果问题涉及很少使用的部分，请将其作为低优先级问题，并在有时间的情况下进行讨论。如果问题或建议不是优先事项，则应保持低优先级。如果您无法确定解决方案A或解决方案B是否最佳，请不要反复使用相同参数的圆圈。只需实施其中一个解决方案，看看beta测试人员是否喜欢它。你可以做的最糟糕的事情是浪费时间在很小的问题上，而大问题需要解决。

• 软件永远不会完美，因为用户的观点不同。一些用户会认为一个小问题会破坏整个应用程序。其他人将面临严重的可用性问题。人们倾向于倾听那些争辩最大声的人。了解您的用户将“大声”问题与重要问题分开。这需要经验，有时你会做出错误的决定，但没有完美的方法，只有稳定的改进。

• 如果可以，请为软件的部署阶段留出一定数量的可用性开发资源。当人们开始在真实的生产环境中使用它时，就会出现可用性问题。有时提供完美的软件并不重要，但要在问题出现时迅速解决问题。

Answer 9

可用性测试小组将帮助..测试不是专注于发现错误，而是关注新设计的学习曲线，由一组用户而非程序员制作。

Answer 10

对于如何像使用者一样思考的轻浮（但有些准确）的答案是将针织针放在你的耳朵并且非常用力地推动。

响应时间越长，我们作为程序员并不正常，我的意思是好的方式。我抓住那些仍在运行电子邮件中从陌生人那里收到可执行文件的人，然后想知道他们的计算机是如何被感染的。

任何一群人都会及时制定自己的行话，惯例，做法和期望。作为程序员，您将期望操作系统与Joe User不同。这很自然，但预计却难以解决。

这也是BAs（商业分析师）存在的原因。它们通常来自业务或测试背景，不像程序员那样思考。它们是您与用户的链接。

但实际上，您应该与您的用户交谈。没有poitn辩论用户做什么。只需拖入几个，看看他们做了什么。

Answer 11

我将所有用户视为恶意白痴。

恶意，因为我认为所有用户都会尝试破坏我的代码，做一些不允许的事情，避免输入有效的数据，并且会尽其所能使我的生活变得地狱。

白痴，因为我再也不能认为他们会理解像电话格式之类的简单内容，如果出现在许多选择中会尖叫，并且不会对复杂的指令有任何飞跃。我们的目标是全力以赴。

与此同时，重要的是要确保用户没有意识到你认为他们是白痴。

Answer 12

像用户一样思考，做一个。但这些实际上是您的测试人员报告的错误吗？或者他们是“增强请求”？如果软件按照设计的要求运行，并且他们不喜欢它的运行方式，那不是错误。这是要求和设计的失败。使其工作，使其坚如磐石，使其易于更改，您将能够使其成为用户想要的。

Answer 13

我在这里看到一些很好的建议，特别是观察试图使用你app的人。我建议的一件事是查看在纸质表单上向用户呈现内容的顺序（如果他们使用这些来进行数据输入），并使最终数据输入页面尽可能地模仿该顺序。如此多的数据输入错误（以及数据输入速度的损失）来自于它们必须在页面上跳转并失去它们的位置。今年我为一场政治活动做了一些工作，在每种情况下，输入数据都变得更加困难，因为计算机屏幕的处理顺序与纸张输入的顺序不同。如果表单是无法更改的表单（如选民登记表单，广告系列必须使用州提供的内容）来匹配计算机屏幕，这一点尤为重要。如果可能的话，屏幕之间也应保持一致。如果它是一个表单上的名字姓氏，则在下一个表单上将其作为姓氏名字将会混淆人员和被保护人的数据输入错误。

如果您真的对了解用户感兴趣，我强烈建议参加人因工程课程。这是一种启发性的经历。

Answer 14

您可以采用TDD / BDD方法并在测试之前让用户参与其中，让他们在您编写单元测试时与您一起完善需求。我们已经开始将这些趋势中的一部分纳入我们当前的项目中，并且我们在早期参与用户的领域中看到的错误更少。

Answer 15

我建议做一些形式的可用性测试;我过去参加过这样的活动，发现它们非常有用。

例如，如果您正在编写票务系统，请调出任务，并询问“如何更新此票证”或“如果单击此按钮，您希望发生什么”等问题。

您也不一定需要完整的应用程序，在某些地方可以使用屏幕截图。

Answer 16

执行此操作的“正确”方法是对新界面功能进行原型设计（或模拟），并观察用户是否尝试使用它们。没有什么比看到真正的用户尝试使用新功能更具启发性了。

不幸的是，鉴于大多数项目的时间和资源，这是不可能的。如果这是您所处的位置，我建议您在团队中进行最佳掌握，然后让他们对可用性决策负责 - 但是这个人需要定期咨询真实用户以确保他/她的想法与用户想要的一致。

Answer 17

没有“像用户一样思考”的技巧，请抓住对项目一无所知的人，抛弃你对他们所做的一切。

这是了解外观+感觉+功能如何呈现给最终用户的唯一方法。

一旦你对那些对产品一无所知的人感到震惊，那就听他们所有的愚蠢（或者你认为他们都是）投诉，修理它们，安排他们指出的每一个愚蠢的化妆品（通过修复UI或通过改进你所拥有的任何文件... ..

在你满意的人之后，你选择从第一轮的主题零知识看你的应用，选择另一个...和另一个......直到他们看到它时他们不再感到震惊，他们不'卡住了......“好吧..这是做什么的？”各种阶段。

你（作为项目的成员，无论是项目经理，开发人员等）都不会认为用户是我对这个问题的回答。

Answer 18

老话说：你可以做一些“傻瓜证明”，但你不能把它作为“该死的傻瓜证明”。

此外：当你做出“白痴证明”的事情时，世界发明了一个更好的白痴。

除此之外，我同意其他人所说的话。

Answer 19

要求一个完全没有知识，见解或编程经验的人使用该程序并尝试找出该程序的每个功能。

永远不会使用此类程序的人最有可能发现错误。

将其视为尝试将URL放入搜索字段的新Safari用户（或FF）... 作为一名程序员，你认为没有人会那么愚蠢（或者，不知道），但人们实际上有时会发现自己处于这些情境中。作为程序员，我们会错过这些东西。