1、不犯错误
1.1 提高程序的健壮性-不让程序犯错；
1.2 使用户的操作都可撤销-给弥补错误的机会；
1.3 控制用户的输入-不让用户犯错
1.3.1 用户需要填的表单尽量改成选择控件
1.3.2 给用户尽量少的选择
2、不用弹窗提示错误
弹窗最令人讨厌的地方在于：毫无预兆的出现、与当前进行的流程没有联系、必须处理后才可以回归原本的流程。
那么减少弹窗讨厌程度的一种方式就是···不要用弹窗进行提示。可以用 toast （过一段时间自动消失）来取代部分不重要的提示弹窗，用一些精美的动效来代替部分用于反馈操作结果的弹窗（譬如发布成功、保存成功之类）。
3、如果一定要有弹窗，那么出现在正确可接受的场景下
弹窗并非十恶不赦。弹窗被憎恨几乎都是由于被滥用。
About Face3 这本书里称弹窗这种提示方式为“模态”，意即打断用户当前的操作流程，强制性的提醒或逼迫用户进行某些操作。“强制”就一定是坏的吗？如果一个支付工具在你的账户可能有安全风险的时候，用弹窗提示你，你会憎恶它吗？如果你的一份重要文件可能发生不可逆转的改变，系统用弹窗提示你，你会不开心吗？
我想答案都是“不会”。
这说明我们队弹窗的滥用出现在将不够重要的信息，用模态的方式呈献给了用户。而当真正重要的信息出现时，正像狼来了的故事一样，提示太多次，用户直接就关闭了窗口，而重要的提示压根没有起到提示作用。
在现在大多数产品中，弹框在报告错误时依据场景分为三种：
a. 警告
警告弹框用于告知用户程序在进行中发生的错误。
譬如 Windows 老版本的系统时常做的那样，弹出一个提示框，上面画着大大的！号，所有的信息只有：“啊天啦噜好像有什么地方出错了”，而你能做的只有点击确认按钮。
b. 错误
错误弹框和警告弹框非常接近。但是错误弹框除了告知错误以外，还为用户提供可能的操作。
譬如程序发生了某种故障失去响应，弹出弹窗说：“啊天啦噜我好像遇到了什么问题”，但是会给你两个选项（虽然通常都没什么作用），一个是重启，一个是继续等待。
c. 确认
确认弹框出现在程序对如何对用户的操作做出响应缺乏信心时，给出多个可能的选择让用户选择。
譬如最臭名昭著的 Microsoft Word，修改文档在退出时总会被问：“请问你要保存吗？”，甚至给出了三个选项，“是”、”否“和“取消”。如果我不想保存，那么我为什么要修改呢？
但这个确认弹框并不是用户在实现目标中必须的，而是由于程序本身的问题，反过来向用户确认。如果程序可以做到自动保存当前版本和未修改版本，那即使用户真的发了疯，不想要当前修改后的版本，也有方式回退到上一个版本的话，这样的确认弹框就会变得毫无必要。
首先警告弹窗毫无存在的必要，一是因为这和用户关系不大，二是因为即使用弹窗提示，用户也对这样的错误毫无办法。这种情况下应该提高程序健壮性，避免程序崩溃的情况发生。如果程序崩溃，不要让用户做出选择，而是程序自动做出应对错误的相应。
其次错误弹框也大多数情况下无存在的必要，因为用户在很多时候并不能明白程序到底出了什么问题，也并不清楚应该选择某个选项进行应对，同警告弹窗一样，程序应该自己做出合适的响应。但是在少数情况下，发生的错误与用户自身有密切的联系，如文件丢失等等既重要又与用户密切相关的问题，还是可以用弹窗进行提醒。
最后，如果允许用户撤销自己的操作的话，那么确认弹框也变得不再必要。
