弹窗按钮文案解析（二）

上一篇文章把弹窗按钮主要使用的文案以及使用场景和作用进行了罗列，本篇文章主要针对几组比较容易混淆的按钮文案进行对比说明，以区分它们之间的不同和厘清各自适合的使用场景。

1.  “好的” vs. “我知道了”

“好的”和“我知道了”使用的场景并没有非常显著的区别，所以这两个按钮文案的使用经常容易被混淆。但仔细思考还是能发现两者之间的不同点：

好的vs.我知道了

a. 使用“我知道了”按钮时系统传递的信息的正式程度和重要程度比使用“好的”时更正式，更重要，如系统重要通知、系统发放的优惠券等等，适合用“我知道了”。

b. 用户在面对“好的”按钮时，对系统信息的重要程度的心理预期比“我知道了”要低很多，因为相较于“好的”的随意，“我知道了”更接近一种契约，一种承诺，用户会有一种在点击“我知道了”按钮时，系统拿到了“用户已阅”回执的心理模型，虽然系统并没有这么做。

我知道了更正式

c. “好的”一般也用于有前置操作的后续反馈，如前面的操作导致了弹窗结果，而用户对于前面的操作导致的弹窗结果有一定心理预期。而“我知道了”更适合于在没有用户前置操作的情况下重要的系统信息。

好的 vs. 我知道了

所以设计者在设计无后续操作的Alert弹窗时，需要衡量所传递给用户的信息的重要性，对于那些非常重要的需要用户仔细阅读的信息，可以使用“我知道了”来增加对信息重要性的暗示和用户的心理预期，但也要注意不要滥用。

2. “确认” vs. “确定”

在弹窗设计时，“确认”和“确定”是比较容易被混淆的两个按钮文案，两者都可以和“取消”按钮组成二选一的按钮组合，所以很多产品设计者容易分不清两者之间的差别而乱用，从而造成对用户认知的负担。

确认 vs. 确定

a. 在Confirm弹窗场景中，“确定”对应的场景是用户进行了某项“删、改”这个层级的不可逆操作，但这种操作只涉及某条信息的修改、删除、状态永久改变等变化，并没有提交更多附加信息到服务器。“确认”对应的场景是用户在前置场景中进行了配置、选择、信息填写等操作，在点击提交按钮时，系统用Confirm弹窗进行二次确认，此时需要用户意识到自己附加的信息会改变系统状态。

在Confirm弹窗里“确认”和“确定”

b. 在“排序”、“筛选”等侧边弹窗场景里，用户虽然在选择Action按钮前执行了很多操作配置，但此时并不是二次确认弹窗，所以此时更适合用“确定”按钮来执行当前选择。

c. 表单页的中间步骤Aciton按钮可以使用“确定”，此时用“确定”比“提交”按钮应用场景的普适性更佳。

表单Action按钮更适合用“确定”

所以，“确定”按钮一般来说，适用范围和场景比“确认”要多，“确认”现在更多的使用场景是配合主Action动作一起组合使用，这时候，“确认提交”、“确认还款”就比“确定提交”、“确定还款”语境和语气更佳合理。

最后，很多时候在有些场景里，使用“好的”比使用“确定”更加合理。

有些场景“好的”更加合理