这是由OK-Cancel 或 Cancel-OK?问题启发的。.
我记得在某处读过关于在某些情况下切换 OK-Cancel/Cancel-OK 的概念，以防止用户在未阅读其内容的情况下单击信息弹出窗口或对话框。据我记得，这还包括移动“确定”按钮的位置（水平，从左到右），以防止用户只记得点击的位置。
这真的有意义吗？这是强迫用户“先思考/阅读，然后点击”的好方法吗？还有其他适用于这种情况的概念吗？
我特别想到了一个与安全相关的应用程序，在这种应用程序中，出于习惯而轻率地按下 OK 可能会导致潜在的危险情况，而 Cancel 会导致安全状态。
请不要这样做，除非你真的，真的，真的确定它是绝对需要的。这是一个试图通过技术手段解决粗心和愚蠢的案例，而这种事情几乎永远不会奏效。
您可以做的是使用动词或名词，而不是典型的 Windows 确定/取消按钮标题。这将在不牺牲可预测性的情况下为您带来即时的关注收益。
不不不不不不不不不不！
在我们的一款产品中，我们有一个用户选项，要求使用 Ctrl+Click 来执行与安全相关的命令。
但是在我的书中，用交换位置或四处移动的按钮让用户吃惊是糟糕的设计。
不。如果你让用户更难错误地点击 OK 并强迫他们思考，他们仍然只会更加努力地思考如何点击 OK——他们不会考虑他们正在尝试执行的实际操作。请参阅可用性专家 Aza Raskin 的文章：当您的意思是 Undo 时，切勿使用警告。引用：
如何使警告无法忽略？如果是人的习惯导致了问题，为什么不设计界面让我们无法形成习惯。这样，在回答问题之前，我们总是会被迫停下来思考，所以我们总是会选择我们想要的答案。那会解决问题的，对吧？
这种思维方式并不新鲜：它是这种句子的第 n 个单词的类型以继续的方法。例如，在游戏激战中，删除一个角色需要先点击一个“删除”按钮，然后输入角色的名字作为确认。不幸的是，它并不总是有效。尤其：
- 它使我们专注于手头的非习惯性任务，而不是我们是否想放弃我们的工作。因此，不可能忽略的警告比正常警告要好一点：无论哪种方式，我们最终都会丢失我们的工作。这（失去我们的工作）是最糟糕的软件罪过。
- 它非常烦人，而且因为它总是需要我们的注意力，它必然会分散我们的工作注意力（这是软件中第二大罪过）。
- 它总是比标准警告更慢且工作量更大。因此，它犯了第三大罪——要求我们做更多的工作而不是必要的。
[如果你想要一个微软风格的，这个 MSDN 上的 .NET 家伙说的也是一样的！]
如果您必须使用对话框，请在对话框内的按钮上添加描述性标题。
例如，让他们说“发送发票”和“返回”，而不是“确定”和“取消”按钮，或者在对话上下文中适当的任何内容。
这样，文本就在他们的光标下，他们有很好的理解机会。
Apple Human Interface Guideline 站点是一个很好的参考，并且非常易读。 该站点上的此页面讨论了对话框。
这是一个示例图像：（来源：apple.com）
不，这没有意义。你不会“让”用户阅读。如果决定如此重要，那么你最好找到一种方法来减轻危险，而不是把一把上膛的枪交给一个假定粗心的用户。
无论如何，将“安全”按钮设置为默认值（由输入/空格键/等触发）是一个好主意，因为如果它们让用户感到惊讶，那么针对预期窗口的击键不会意外触发意外操作。但即使在这种情况下，您也必须意识到，当用户意识到他们所做的事情时，选择已经消失（以及对话框上的任何解释性文本）。同样，您最好找到另一种向他们提供信息的方法。
在某些情况下，我所做的是将显示消息框的时间与关闭它的时间进行比较。如果它少于“x”秒，它会立即弹出。在大多数情况下，这迫使他们实际阅读屏幕上的内容，而不是盲目地点击它。
做起来也挺简单的......
像这样的东西：
Dim strStart As DateTime = Now
While Now < strStart.AddSeconds(5)
MessageBox.Show("Something just happened", "Pay Attention", MessageBoxButtons.OK)
If Now < strStart.AddSeconds(5) Then strStart = Now Else Exit While
End While
归根结底，您不能强迫用户做他们不愿意做的事情……他们总能找到解决方法
我见过的最可靠的方法是根据所写的内容给出一个多项选择题。如果他们没有得到正确的答案，他们就无法继续……当然，在几次之后，他们会意识到他们可以依次选择每个答案，直到按钮启用然后单击它。再次意味着他们不阅读所写的内容。
在您必须为用户的行为承担责任之前，您只能走这么远。告诉用户他们的行为被记录下来会让他们更加小心——如果他们被追究责任，他们更有可能做正确的事情。尤其是如果有一条精心设计的消息说：
这将被记录下来，您将对此决定的任何影响负责。您已指示我删除表 ALL_CORPORATE_DATA。这样做会导致整个公司的数据库停止工作，从而使整个公司陷入停顿。
您必须选中复选框以声明您接受此责任，然后才能选择继续...
然后是一个带有“是的，我接受我的行为的责任”的复选框和两个按钮：
如果他们删除表格并且公司网格停止，他们就会被解雇。然后备份被恢复，每个人都再次像拉里（无论拉里是谁）一样高兴。
请不要这样做。这不会产生任何积极影响：您试图避免人们单击“确定”而不是“取消”，让他们可能会单击“取消”而不是“确定”（好吧，他们可能会再试一次）。但！当人们真正想取消时，您还不如实现他们单击“确定”，这可能是一场真正的灾难。就是不好。
为什么不重新设计 UI 以使 OK 成为“安全选择”？
结合良好的反馈、系统模型的沟通和内置公差，可以更好地解决这个问题。
赞成确认机制的说法是实现的简单性。从程序员的角度来看，这是将责任转移到用户身上最简单的方法：“嘿，我问过你是否真的想把自己踢到脚上，不是吗？现在除了你自己，没有人可以责备...... 。”
从用户角度：
对用户更好但更复杂（从软件开发的角度来看）的解决方案是：
在可能的情况下，提前沟通该操作将对系统产生的确切影响（例如 Stack Overflow 在“发布您的答案”按钮上方显示消息预览）。
一旦操作发生，立即提供反馈以确认（SO突出显示新提交的答案，gmail在发送消息时显示确认等）。
允许撤消或更正可能的错误（即在这种情况下删除或编辑答案，Windows 允许从回收站等恢复文件）。对于某些不可逆的操作，仍然可以提供撤消功能，但仅限于有限的时间范围（即允许在提交后的前 10 分钟内取消或更改在线订单，或允许在第一个“发送”后 60 秒，但实际上在发件箱中排队等）。
当然，这比插入确认消息框要多得多，但不是转移责任，而是试图解决问题。
但是如果 OK/Cancels 不一致，那可能会让用户感到厌烦或不安。
并且不要像某些 EULA 那样强制用户在“同意”按钮变为可点击之前将面板滚动到底部。有时您无法让用户仔细阅读所有内容。
如果他们真的需要阅读它，也许应该在按钮出现之前发生短暂的延迟？这也可能让用户感到恼火，但如果这是一个非常关键的问题，那就值得了。
编辑：或者需要某种额外的机制，而不仅仅是单击“接受”非常重要的决定。复选框、按键、密码等。
我建议通过使用红色文本来告知用户这是一项关键操作，并解释为什么这是一个不安全的操作。
此外，不是两个按钮，而是有两个单选按钮和一个“确定”按钮，默认选择“不继续”单选按钮。
这将为用户提供一个不常见的界面，增加认知负荷并减慢他的速度。这就是你想要的。
与任何与用户交互一样，您在帮助用户和烦人之间只有很小的空间。我不知道你的确切要求，但你的想法对我来说似乎没问题（双关语）。
听起来您的用户正在通过安全应用程序中的一种输入向导。
作为移动按钮的替代方案的一些想法。
在按下最后的确定之前，有一个最终屏幕来查看所有输入。
在他们点击确定后有一个确认框，解释此操作的结果将是什么。
免责声明要求您在用户继续之前通过选中一个框来同意它。
不要改变它 - 你只会混淆而不是帮助。
相反，像 FireFox 一样，在 5 秒内不激活控件。- 只要确保您包含一个计时器或某种指示器，您就可以让他们有机会阅读它。如果他们点击它，它会切断计时器，但需要他们再点击一次。
不知道它会好多少，但它可能会有所帮助。
请记住，正如那个人所说：你不能解决愚蠢的问题。
这会让我头疼。特别是当我不小心关闭应用程序并忘记保存我的文件时:(
我看到另一个强制用户在点击之前“阅读”的好例子：Firefox 总是将“确定”按钮变灰（也就是禁用）。因此，用户必须等待大约 5 秒才能继续执行任何操作。我认为这是我在强迫用户阅读（和思考）方面看到的最大努力
我看到的另一个例子是安装程序的“许可和协议”页面。其中一些要求用户向下滚动到页面末尾，然后才能继续下一步。
键盘快捷键仍然会像以前一样运行（您会惊讶于很少有人真正使用鼠标（尤其是在 LOB 应用程序中）。
Vista（和 OSX IIRC）已经转向为每个问题使用特定动词的想法（例如当应用程序想要崩溃并想要向 MS 提交故障转储时使用“发送”/“不发送”）
在我看来，我喜欢 Outlook 在应用程序尝试通过 COM 发送电子邮件时使用的方法，在允许使用按钮之前使用计时器（也会影响键盘快捷键）
如果您使用Ok和Cancel作为界面，您将始终允许用户跳过您的消息或屏幕。如果您然后重新排列确定和取消，您只会惹恼您的用户。
如果您的目标是确保用户理解，则解决方案是：
这就是我对提交/重置按钮订单问题的回应，我认为这里可以使用相同的原则。只要您确保用户可以区分这两个按钮，顺序并不重要。过去我所做的是使用（提交/确定）按钮的按钮并使用（重置/取消）按钮的链接。用户可以立即看出这两个项目在功能上是不同的，因此可以这样对待它们。
我真的不赞成/取消。它被过度使用了，需要您阅读咿呀声才能说出您正在接受或取消的内容。遵循 MacOSX UI 的理念：按钮包含一个简单易懂且本身就有意义的短语。Exampleç 您更改文件扩展名并弹出一个对话框说：
"Are you sure you want to change the extension from .py to .ps?"
If you perform the change, the document could be opened by a different application.
(Use .ps) (Keep .py)
它比 OK/Cancel 更具交流性，而且您的问题几乎是多余的，也就是说，您只需要保持最右边的按钮处于活动状态，这似乎是标准。
因为它涉及您提出的原始问题。永远不要这样做。曾经。甚至在枪口下也没有。一致性是 GUI 的重要要求。如果您不一致，您将破坏用户体验，并且您的用户很可能会将其视为错误而不是功能（实际上这将是错误）。一致性非常重要。要打破它，你必须有很好的理由，并且不能有另一种不同的、标准的方式来达到同样的效果。
我想知道您是否正在考虑 Visual Basic 中存在的选项，您可以在其中设置各种提示和响应选项；一种选择是允许您根据默认值切换取消和确定；所以用户可以直接按回车键，大多数时候都能得到正确的操作。
如果您真的想朝这个方向前进（我认为这是一个坏主意，而且我相信您也会在稍加思考并阅读所有其他帖子之后），最好包含一个验证码显示以显示 OK。