有哪些很好的例子可以证明“我不是用户”？
我是一名具有可用性工程背景的软件开发人员。 当我在研究生院学习可用性工程时，一位教授有一句口头禅：“你不是用户”。 我们的想法是，我们需要将 UI 设计基于实际的用户研究，而不是我们自己关于 UI 应该如何工作的想法。
从那时起，我看到了一些很好的例子，似乎证明我不是用户。
- 用户尝试使用电子邮件模板创作工具，并在尝试输入竖线 (|) 字符时遇到困难。 问题原来是键盘上的管道中间有一个空格。
- 在网络应用程序中，用户看不到首屏下的内容。 常见的。 我们告诉她向下滚动。 她不知道我们在说什么，也不熟悉滚动拇指。
- 我正在监听技术支持电话。 销售代表告诉用户关闭浏览器。 我在后台听到 Windows 关机铃声。
还有哪些其他好的例子？
编辑：为了澄清，我正在寻找一些示例，在这些示例中，开发人员做出的假设最终证明用户会知道、理解的内容是非常错误的。
I'm a software developer who has a background in usability engineering. When I studied usability engineering in grad school, one of the professors had a mantra: "You are not the user". The idea was that we need to base UI design on actual user research rather than our own ideas as to how the UI should work.
Since then I've seen some good examples that seem to prove that I'm not the user.
- User trying to use an e-mail template authoring tool, and gets stuck trying to enter the pipe (|) character. Problem turns out to be that the pipe on the keyboard has a space in the middle.
- In a web app, user doesn't see content below the fold. Not unusual. We tell her to scroll down. She has no idea what we're talking about and is not familiar with the scroll thumb.
- I'm listening in on a tech support call. Rep tells the user to close the browser. In the background I hear the Windows shutdown jingle.
What are some other good examples of this?
EDIT: To clarify, I'm looking for examples where developers make assumptions that turn out to be horribly false about what users will know, understand, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
我认为最大的例子之一是专家用户倾向于使用应用程序。
他们说：“好吧，我有这个工具，我能用它做什么？”
普通用户将操作系统、文件系统或应用程序的生态系统视为一个可怕的大地方，他们可能会迷失方向，再也不会回来。
对于他们来说，他们想要在计算机上做的一切都是基于任务的。
他们想要一个起点、一个可重复的工作流程，并且他们希望每次执行任务时都能做到这一点。 他们不关心简化流程或找到最好的方法来做到这一点，他们只想要一种可重复的方法来做到这一点。
在构建 Web 应用程序时，我很早就学会了将应用程序的起始页与菜单分开，并使用基于任务的链接以非常大的字体指向应用程序执行的主要操作。 对于普通用户来说，这极大地提高了可用性。
因此请记住这一点：用户不想“使用您的应用程序”，他们想要完成一些特定的事情。
I think one of the biggest examples is that expert users tend to play with an application.
They say, "Okay, I have this tool, what can I do with it?"
Your average user sees the ecosystem of an operating system, filesystem, or application as a big scary place where they are likely to get lost and never return.
For them, everything they want to do on a computer is task-based.
They want a starting point, a reproducible work flow, and they want to do that every time they have to perform the task. They don't care about streamlining the process or finding the best way to do it, they just want one reproducible way to do it.
In building web applications, I long since learned to make the start page of my application something separate from the menus with task-based links to the main things the application did in a really big font. For the average user, this increased usability hugely.
So remember this: users don't want to "use your application", they want to get something specific done.
在我看来，“开发者不是用户”最明显的例子就是常见的确认对话框。
在大多数基于文档的应用程序中，从最复杂的（MS Word、Excel、Visual Studio）到最简单的（记事本、Crimson Editor、UltraEdit），当您关闭具有未保存更改的应用程序时，您会看到如下对话框：
假设：用户将阅读对话框
现实：如果平均阅读速度为每秒 2 个单词，则需要 9 秒。 许多用户根本不会阅读该对话框。
观察：许多开发者的阅读速度比典型用户快得多
假设：可用选项的可能性均等。
现实：大多数（>99%）用户都希望保存他们的更改。
假设：用户在点击选择之前会考虑后果
现实：用户按下按钮后的一瞬间就会感受到选择的真正影响。
假设：用户会关心所显示的消息。
现实：用户专注于他们需要完成的下一个任务，而不是“照顾和喂养”他们的计算机。
假设：用户将了解该对话框包含他们需要了解的关键信息。
现实：用户将对话框视为他们前进道路上的障碍，只想以最快的方式摆脱它。
In my mind, the most visible example of "developers are not the user" is the common Confirmation Dialog.
In most any document based application, from the most complex (MS Word, Excel, Visual Studio) through the simplest (Notepad, Crimson Editor, UltraEdit), when you close the appliction with unsaved changes you get a dialog like this:
Assumption: Users will read the dialog
Reality: With an average reading speed of 2 words per second, this would take 9 seconds. Many users won't read the dialog at all.
Observation: Many developers read much much faster than typical users
Assumption: The available options are all equally likely.
Reality: Most (>99%) of the time users will want their changes saved.
Assumption: Users will consider the consequences before clicking a choice
Reality: The true impact of the choice will occur to users a split second after pressing the button.
Assumption: Users will care about the message being displayed.
Reality: Users are focussed on the next task they need to complete, not on the "care and feeding" of their computer.
Assumption: Users will understand that the dialog contains critical information they need to know.
Reality: Users see the dialog as a speedbump in their way and just want to get rid of it in the fastest way possible.
我绝对同意 Daniel 回复中的粗体评论——大多数真实用户经常有一个他们想要实现的目标，并且只是想尽可能轻松、快速地实现该目标。 从经验来看，这不仅适用于计算机新手或非技术人员，也适用于相当精通技术的用户，他们可能不熟悉您的特定领域或技术堆栈。
我经常看到客户面临着丰富的技术、工具、实用程序、API 等，但没有明显的方法来完成他们的高级任务。 有时，可以通过更好的文档（考虑全面的演练）简单地解决这个问题，有时可以使用一些基于命令行脚本/工具构建的高级向导，有时只需对软件项目进行基本的重新优先级排序即可解决。
话虽如此……再举一个具体的例子，那就是 Windows 开始菜单（摘自 关于旧新事物博客的文章）：
正如这里其他人提到的，我们技术人员习惯于摆弄环境，单击所有可以单击的内容，浏览所有可用的菜单等。然而，我的家庭成员害怕他们的计算机更担心他们点击的东西会“删除”他们的数据，因此他们更希望获得关于点击位置的明确指示。
I definitely agree with the bolded comments in Daniel's response--most real users frequently have a goal they want to get to, and just want to reach that goal as easily and quickly as possible. Speaking from experience, this goes not only for computer novices or non-techie people but also for fairly tech-savvy users who just might not be well-versed in your particular domain or technology stack.
Too frequently I've seen customers faced with a rich set of technologies, tools, utilities, APIs, etc. but no obvious way to accomplish their high-level tasks. Sometimes this could be addressed simply with better documentation (think comprehensive walk-throughs), sometimes with some high-level wizards built on top of command-line scripts/tools, and sometimes only with a fundamental re-prioritization of the software project.
With that said... to throw another concrete example on the pile, there's the Windows start menu (excerpt from an article on The Old New Thing blog):
As mentioned by others here, we techie folks are used to playing around with an environment, clicking on everything that can be clicked on, poking around in all available menus, etc. Family members of mine who are afraid of their computers, however, are even more afraid that they'll click on something that will "erase" their data, so they'd prefer to be given clear directions on where to click.
许多年前，在 CMS 中，我愚蠢地认为没有人会尝试创建名称中带有前导空格的目录……有人这样做了，这让系统的许多其他部分非常非常悲伤。
另一方面，试图向我的母亲解释单击“开始”按钮来关闭计算机简直是一个痛苦的世界。
Many years ago, in a CMS, I stupidly assumed that no one would ever try to create a directory with a leading space in the name .... someone did, and made many other parts of the system very very sad.
On another note, trying to explain to my mother to click the Start button to turn the computer off is just a world of pain.
关于用户“杯架”（CD/ROM）损坏的虚构技术支持电话怎么样？
实际上，让我感到困扰的是剪切/粘贴——我现在总是修剪我的文本输入，因为我的一些用户从电子邮件等中剪切/粘贴文本，最终选择了额外的空白。 我的测试从未考虑过人们会“输入”额外的字符。
How about the apocryphal tech support call about the user with the broken "cup holder" (CD/ROM)?
Actually, one that bit me was cut/paste -- I always trim my text inputs now since some of my users cut/paste text from emails, etc. and end up selecting extra whitespace. My tests never considered that people would "type" in extra characters.
今天的 GUI 在隐藏底层操作系统方面做得非常好。 但特质仍然显现出来。
为什么 Mac 不允许我创建名为“Photos: Christmas 08”的文件夹？
为什么我必须“弹出”已安装的磁盘映像？
不能仅通过更改文件扩展名将 JPEG 转换为 TIFF 吗？
（最后一个实际上是几年前发生在我身上的。我花了永远才弄清楚为什么 TIFF 无法正确加载！就在那一刻，我明白了为什么 Apple 过去使用嵌入式文件类型（作为元数据）直到今天我仍然不明白为什么他们愚蠢地回到文件扩展名，哦，是的，这是因为 Unix 是一个优越的操作系统。）
Today's GUIs do a pretty good job of hiding the underlying OS. But the idosyncracies still show through.
Why won't the Mac let me create a folder called "Photos: Christmas 08"?
Why do I have to "eject" a mounted disk image?
Can't I convert a JPEG to TIFF just by changing the file extension?
(The last one actually happened to me some years ago. It took forever to figure out why the TIFF wasn't loading correctly! It was at that moment that I understood why Apple used to use embedded file types (as metadata) and to this day I do not understand why they foolishly went back to file extensions. Oh, right; it's because Unix is a superior OS.)
我已经见过很多次了，这似乎是经常出现的事情。 我似乎是那种能够接受这些假设的人（在某些情况下），但我多次被用户所做的事情所震惊。
正如我所说，这是我非常熟悉的事情。 我开发的一些软件是由普通大众（而不是经过专门培训的人）使用的，所以我们必须为这种事情做好准备。 但我发现它没有被考虑在内。
一个很好的例子是需要填写的网络表单。 我们需要填写此表格，这对流程很重要。 如果用户不填写表格，对我们没有好处，但我们从他们那里获得的信息越多越好。 显然这是两个相互冲突的要求。 如果只向用户呈现一个包含 150 个字段（随机的大数字）的屏幕，他们会害怕地逃跑。
为了改进这些表格，这些表格已经被修改了很多次，但用户并没有被问到他们想要什么。 决策是根据不同人的假设或感受做出的，但没有考虑到这些感受与实际客户的接近程度。
我还将提到 Bevan 的“用户将阅读对话框”假设的推论。 脱离“用户不阅读任何内容”的假设更有意义。 然而，那些认为用户没有阅读任何内容的人通常会建议放置一些长而干燥的解释性文本，以帮助那些因某些随机的糟糕设计决策而感到困惑的用户（例如对应该是单选按钮的内容使用复选框，因为您只能选择一）。
任何类型的技术支持都可以非常提供有关用户如何（或不）思考的信息。
I've seen this plenty of times, it seems to be something that always comes up. I seem to be the kind of person who can pick up on these kind of assumptions (in some circumstances), but I've been blown away by what the user was doing other many times.
As I said, it's something I'm quite familiar with. Some of the software I've worked on is used by the general public (as opposed to specially trained people) so we had to be ready for this kind of thing. Yet I've seen it not be taken into account.
A good example is a web form that needs to be completed. We need this form completed, it's important to the process. The user is no good to us if they don't complete the form, but the more information we get out of them the better. Obviously these are two conflicting demands. If just present the user a screen of 150 fields (random large number) they'll run away scared.
These forms had been revised many times in order to improve things, but users weren't asked what they wanted. Decisions were made based on the assumptions or feelings of various people, but how close those feelings were to actual customers wasn't taken into account.
I'm also going to mention the corollary to Bevan's "The users will read the dialog" assumption. Operating off the "the users don't read anything" assumption makes much more sense. Yet people who argue that the user's don't read anything will often suggest putting bits of long dry explanatory text to help users who are confused by some random poor design decision (like using checkboxes for something that should be radio buttons because you can only select one).
Working any kind of tech support can be very informative on how users do (or do not) think.
Linux 中操作系统级别的几乎所有内容都是一个很好的例子，从名称的选择（“grep”显然对用户来说意味着“搜索”！）到语法的选择（“rm *”对你有好处！ )
[我不讨厌 Linux，它只是充满了 UNIX 遗留的不可用性示例]
pretty much anything at the O/S level in Linux is a good example, from the choice of names ("grep" obviously means "search" to the user!) to the choice of syntax ("rm *" is good for you!)
[i'm not hatin' on linux, it's just chock full of unix-legacy un-usability examples]
桌面和壁纸的比喻怎么样？ 现在情况正在好转，但 5-10 年前是许多远程技术支持电话的祸根。
还有反斜杠与斜杠的问题、各种键盘符号的无数名称以及过时的打印屏幕按钮。
How about the desktop and wallpaper metaphors? It's getting better, but 5-10 years ago was the bane of a lot of remote tech support calls.
There's also the backslash vs. slash issue, the myriad names for the various keyboard symbols, and the antiquated print screen button.
现代操作系统很棒，因为它们都支持多个用户配置文件，因此在同一工作站上使用我的应用程序的每个人都可以拥有自己的设置和用户数据。 只是，我收到的支持请求中有很大一部分是询问如何在同一用户帐户下拥有多个数据文件。
Modern operating systems are great because they all support multiple user profiles, so everyone that uses my application on the same workstation can have their own settings and user data. Only, a good portion of the support requests I get are asking how to have multiple data files under the same user account.
回到大学时代，我曾经培训人们如何使用计算机和互联网。 我会去他们家，设置他们的互联网服务，向他们展示电子邮件和一切。 嗯，有一对老夫妇（60 年代末）。 我花了大约三个小时向他们展示如何使用计算机，确保他们可以连接到互联网和一切。 我离开时感到非常高兴。
那个周末我接到一个疯狂的电话，说他们无法检查他们的电子邮件。 现在我正在享受周末，但决定帮助他们，并完成所有事情，30 分钟后，我问他们是否有两条电话线......“当然我们只有一条”不用说他们忘记了他们需要先连接到互联网（是的，这回到了调制解调器的时代）。
我想我应该有像 DUN - > 这样的设置快捷方式 检查电子邮件步骤 1，Eduora - 检查电子邮件步骤 2...
Back in my college days, I used to train people on how to use a computer and the internet. I'd go to their house, setup their internet service show them email and everything. Well there was this old couple (late 60's). I spent about three hours showing them how to use their computer, made sure they could connect to the internet and everything. I leave feeling very happy.
That weekend I get a frantic call, about them not being able to check their email. Now I'm in the middle of enjoying my weekend but decide to help them out, and walk through all the things, 30 minutes latter, I ask them if they have two phone lines..."of course we only have one" Needless to say they forgot that they need to connect to the internet first (Yes this was back in the day of modems).
I supposed I should have setup shortcuts like DUN - > Check Email Step 1, Eduora - Check Email Step 2....
用户不知道的，他们会弥补。 他们经常使用错误的应用程序工作原理。
特别是对于数据输入，用户的打字速度往往比开发人员快得多，如果程序反应缓慢，这可能会导致问题。
故事： 很久以前，在个人电脑出现之前，就有了分时技术。 一家分时度假公司的客户代表告诉我，有一次，当他给两三个漂亮的老年妇女上“如何做”课程时，他告诉她们如何停止正在运行的程序（以防它启动错误或花费很长时间） .）他让其中一名学生输入^K，分时终端回应“已杀！”。 这位女士差点心脏病发作。
我们公司面临的一个问题是员工不信任计算机。 如果你将他们在纸上完成的功能计算机化，他们将继续在纸上完成，同时将结果输入计算机中。
What users don't know, they will make up. They often work with an incorrect theory of how an application works.
Especially for data entry, users tend to type much faster than developers which can cause a problem if the program is slow to react.
Story: Once upon a time, before the personal computer, there was timesharing. A timesharing company's customer rep told me that once when he was giving a "how to" class to two or three nice older women, he told them how to stop a program that was running (in case it was started in error or taking to long.) He had one of the students type ^K, and the timesharing terminal responded "Killed!". The lady nearly had a heart attack.
One problem that we have at our company is employees who don't trust the computer. If you computerize a function that they do on paper, they will continue to do it on paper, while entering the results in the computer.