代码之家  ›  专栏  ›  技术社区  ›  Jeff

我怎样才能像用户一样思考?[闭门]

  •  12
  • Jeff  · 技术社区  · 17 年前

    我们经常会被一些琐碎的事情所困扰,这些琐碎的事情会导致冗长的、耗费时间的讨论。它们都可以归结为一件事:虽然我们知道我们需要什么功能,但我们在一些小细节上遇到了麻烦,比如“这条消息应该去哪里”和“他们是否需要立即反馈,或者它是否会中断他们的流程,所以我们应该推迟?”?

    这些都是我们的测试人员应该了解的,但是

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

    b) 我们想要一种尽可能坚固的产品

    c) 即使是最好的测试团队也会时不时地错过一些东西。

    我们使用我们的产品,我们知道我们的用户是如何使用旧版本的……但当我们尝试使用新版本时,我们都不知道如何像用户一样思考(新版本有显著的图形和底层更改)。

    编辑-更多背景:

    我们能得到的最接近的是我们的客户服务团队(他们真的帮了大忙),但他们也不像用户那样思考。他们还充当我们的测试人员(当他们知道任何他们找不到的bug都可能意味着调用数量的大幅上升时,这确实激励他们去发现bug)。本周的大部分时间里,我们有三名(总共约12名)客户服务代表在这里做一些初步测试……他们也参与了讨论。

    19 回复  |  直到 17 年前
        1
  •  20
  •   Dustin Brooks    17 年前

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

    查看他们如何尝试导航,如何尝试输入信息或调整窗口大小。在创建/运行应用程序后,我们认为是理所当然的事情,一小时又一小时,一天又一天。

    用户总是会尝试做一些你从未预料到的事情,而观察他们的行动可能会揭示出你可以如何改变一些看似微不足道但却对他们产生重大影响的事情。

        2
  •  12
  •   Greg    17 年前
        3
  •  9
  •   Adam Bellaire    17 年前

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

    关于(c)你是对的,测试小组不一定能捕获所有的bug。但你能做的最好的事情是让一个由真实的、诚实的最终用户组成的测试小组,并重视他们的反馈。从他们的一般性评论中得出进一步结论。

    如果你想知道你的用户会如何看待你的系统,你能得到的最接近的方法就是对真实用户进行可用性测试。其他一切都只是试探和经验,也容易出错。没有无缺陷的产品,但您应该能够通过可用性测试获得“强大”的产品。

        4
  •  6
  •   Mitch Wheat    17 年前

    购买一台便宜、易用的摄像机,并使用该应用程序记录您的测试人员。更好的是,让一些不熟悉该应用程序的人使用。使用它并对其进行录像。它相对便宜,你会惊讶它会突出什么。

        5
  •  4
  •   Robert Gould    17 年前

    我喜欢“自己吃狗粮”的政策 http://en.wikipedia.org/wiki/Eat_one (你自己的狗食)。它使您更进一步,因为您成为了一个用户,尽管您可能会这样想。

        6
  •  4
  •   ofaurax    17 年前

    在你非常匆忙的时候尝试使用你的应用程序(例如,你有人在等晚餐)。 你会看到所有这些小东西,因为你必须等待,你必须回到键盘上的鼠标,等等。

    还有,让你妻子使用它。或者你妈妈。

    另一个有用的测试:通过电话帮助他人使用它。如果他找不到你指示的按钮,那可能是个错误。

        7
  •  4
  •   T.E.D.    17 年前

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

    我经常这样做的方式是与他们讨论他们需要做什么,他们通常做什么,以及他们如何使用当前的工具来做。然后( 非常重要 )当他们做这件事时,和他们坐在一起。确保您与他们相处得足够好,以便您可以在稍后向他们提出有关他们如何处理您想到的边缘案例的问题(答案通常是骇人听闻的“我们为此手动检查系统”)。

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

    开发商 . 他们通常不知道你的软件可以做什么,什么容易,什么难。此外,他们通常对GUI设计原则一无所知。如果你要求他们提供设计输入,他们只会告诉你在他们最喜欢的页面上添加任何新控件,直到它看起来像一个747控制面板。

        8
  •  3
  •   Sebastian Dietz    17 年前

    问题往往是,即使用户在实际使用软件之前也不知道他们想要什么。有时,一个小的疏忽可能是一个大的可用性问题,有时一个经过深思熟虑的功能,被许多用户请求,却看不到什么用处。

    • 看看用户实际做的日常工作。即使他们使用其他软件或根本没有软件。您将能够确定他们完成工作通常需要的工件。您将看到他们经常需要哪些数据。关注最常用的工件、数据和工作流。它们应该是最有用的。对于用户来说,异国情调的工作流可能比经常使用的工作流更耗时。

    • 使用GUI的工作原型,让用户通过真实的工作流工作。观察他们,注意什么阻碍了他们,什么效果好。相应地调整原型。

    • 如果您的软件中经常使用的部分出现问题,现在是时候详细讨论它了。如果问题涉及很少使用的零件,将其作为低优先级问题,并在有时间的情况下进行讨论。如果问题或建议的优先级较低,则应保持低优先级。如果你不能确定解决方案A或解决方案B是最好的,不要一遍又一遍地用同样的论点兜圈子。只要实现其中一个解决方案,看看beta测试人员是否喜欢它。你能做的最糟糕的事情就是在小问题上浪费时间,而大问题需要解决。

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

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

        9
  •  1
  •   cletus    17 年前

    对于如何像用户一样思考,轻率(但有点准确)的答案是把一根编织针插在耳朵里,用力推。

    更长的回答是,我们作为程序员是不正常的,我的意思是,在一个好的方面。我对仍在运行他们从陌生人那里收到的电子邮件中的可执行文件的人的数量感到惊讶,然后想知道他们的计算机是如何被感染的。

    任何群体的人都会及时形成自己的行话、惯例、惯例和期望。作为一名程序员,您对操作系统的期望与Joe User不同。这是很自然的,可以预料,但很难解决。

    实际上,你应该和你的用户谈谈。用户做什么没有争论的焦点。只要拉几条进去看看他们会做什么。

        10
  •  1
  •   Carlo    17 年前

        11
  •  1
  •   David    17 年前

    我对待所有用户就像对待恶意的白痴一样。

    恶意,因为我假设所有用户都会尝试破坏我的代码,做不允许的事情,避免输入有效数据,并且会做任何他们力所能及的事情,让我的生活陷入地狱。

    白痴,因为我不能假设他们会理解简单的东西,比如电话格式,如果有很多选择,他们会尖叫着跑开,不会对复杂的指令有任何信心的飞跃。目标是在整个过程中握住他们的手。

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

        12
  •  1
  •   Rob K    17 年前

    要想像用户一样思考,就要成为用户。但这些是您的测试人员报告的实际bug吗?还是“增强请求”?如果软件按照需求设计,而他们只是不喜欢它的操作方式,那就不是bug。这是需求和设计的失败。让它工作起来,让它坚如磐石,让它易于更改,你就能让它成为你的用户想要的。

        13
  •  1
  •   HLGEM    17 年前

    我在这里看到一些很好的建议,特别是观察人们试图使用你的应用程序。我建议的一件事是查看纸质表单上呈现给用户的内容的顺序(如果他们使用纸质表单进行数据输入),并使最终的数据输入页面尽可能地模仿该顺序。如此多的数据输入错误(以及数据输入速度的损失)都是由于他们不得不在页面上四处跳跃并失去位置造成的。今年我为一场政治竞选做了一些工作,在每一种情况下,输入数据都变得更加困难,因为电脑屏幕的操作顺序与纸张输入的顺序不同。如果表格无法更改(如选民登记表,竞选活动必须使用国家提供的内容)以匹配计算机屏幕,则这一点尤为重要。如有可能,各屏幕之间也应保持一致。如果一张表格上的名字是姓氏,那么在下一张表格上的名字是姓氏将使人感到困惑,并导致数据输入错误。

    如果你真的对理解用户感兴趣,尽管我强烈建议你学习人因工程学课程。这是一次启发性的经历。

        14
  •  0
  •   DanSingerman    17 年前

    不幸的是,考虑到大多数项目的时间和资源,这是不可能的。如果你处于这样的位置,我建议你在团队中讨论谁对可用性最有把握,然后让他们对可用性决策负责——但这个人需要定期咨询真实用户,以确保他/她的想法与用户想要的一致。

        15
  •  0
  •   warren    17 年前

    例如,如果您正在编写一个票务系统,请提出任务,并询问诸如“您将如何更新此票证”或“如果单击此按钮,您希望发生什么”之类的问题。

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

        16
  •  0
  •   user29439 user29439    17 年前

    您可以采用TDD/BDD方法,在测试之前让用户参与进来,让他们在编写单元测试时与您一起细化需求。我们开始将其中一些趋势融入到我们当前的项目中,在我们先前涉及到用户的领域中,我们看到的bug越来越少。

        17
  •  0
  •   Ric Tokyo    17 年前

    没有“像用户一样思考”的技巧,把你的手放在一个对项目一无所知的人身上,然后把你所做的事情扔给他们。

    这是向最终用户展示外观+感觉+功能的唯一方式。

    一旦你震惊了一个对产品一无所知的人,倾听他们所有愚蠢的(或者你认为他们是)抱怨,纠正他们,安排他们指出的每一件愚蠢的装饰性的事情(要么通过修复用户界面,要么通过改进你拥有的任何文档)。。

    在你让你选择的人对你的应用程序感到满意后,从第一轮的零知识开始,选择另一个…和另一个。。。直到他们看到它时不再感到震惊,并且他们不会被卡住。。“好的……这是做什么的?”类似于阶段。

        18
  •  0
  •   Brian Postow    17 年前

    俗话说:你可以做一些“傻瓜证明”,但你不能使它“该死的傻瓜证明”。

    另外:当你做一些“防白痴”的东西时,世界会发明一个更好的白痴。

        19
  •  0
  •   xaddict    17 年前

    请完全没有知识、洞察力或编程经验的人使用该程序,并尝试了解该程序的每个功能。

    永远不会使用这种程序的人最有可能发现bug。

    将其视为尝试将URL放入搜索字段中的新Safari用户(或FF)。。。 作为一名程序员,你猜没有人会那么愚蠢(或者,嗯……不知道),但人们有时会发现自己处于这种情况。作为一名程序员,我们怀念这些东西。