本篇再来讨论一下几个跟问卷、交流、用户反馈、用户评价、社区等相关度较高的按钮文案。这几个按钮文案分别是：“提交”、“发送”、“发布”。
“提交”“发送”“发布”
在使用“提交”作为弹窗按钮文案时，适用的场景主要包括弹窗本身自带表单的，同时将用户编辑的信息单向传送至服务器或服务中心进行审核等情况，不是说在这些场景下服务器或服务中心不会对用户提交行为进行反馈，而是这种反馈是异步（asynchronism）的，或有一定选择的。
“提交”文案使用场景
“提交”按钮文案的用户的心智模型如下图所示：
提交心智模型
在使用“发送”作为弹窗按钮文案时，适用的场景是一种平等的交流场景，或期待对方能快速给出反馈的情况，虽然发送后接收方不会做出必然反馈或快速反馈的承诺，但用户的心智模型相比“提交”而言，是在期待一种更快速，更及时的回复的。有些意见反馈页为了增加即时性的感觉，甚至把反馈界面设计成聊天界面以缓解用户期待反馈是的焦虑感，提升用户体验。
“发送”应用场景
“发送”按钮文案用户的心智模型图如下：
发送心智模型
所以相较于“提交”，使用“发送”在某些场景下，如提交问题反馈时，可以起到适当减轻用户等待焦虑，减少跳出率等作用，但前提是要提高客服反馈的速度以及每件必复，以符合用户的心理预期，如果提供的反馈非常慢或者是选择性回复，就不能用“发送”按钮文案。
至于“发布”这个弹窗按钮文案，一般不会在前面两种应该使用“提交”和“发送”按钮文案的场景中被混用，因为发布的使用场景范围比较窄，一般用户用户填写的信息发布于公共区域，且用户在点击这个按钮的同时，认可系统的这种行为。
苹果撰写评论用“发送”不合理
其实目前在互联网行业，为了防止垃圾信息营销或不良信息控制或敏感信息控制，发布的内容需要人工审核或机器人审核后才显示也基本成为了标配，这时候弹窗按钮的文案究竟应该是“发布”还是“提交”（尽量不要使用“发送”），就需要看场景需要了。
在某些场景下，如果系统想要减少或消除用户对于发布信息需要审核这个行为的感知，就应当使用“发布”按钮，有些系统在同时还会在本地生成用户提交信息的“镜像”出现在发布区域，但实际上该信息仅发布用户可见，真正的用户的发布信息还在服务器端等待审核，但通过这些方式可以缓解用户焦虑，提升产品使用的刘畅感。
如果系统想要明确告知用户发布的信息需要系统进行审核后才能显示，且这种审核可能是异步的，或发布的内容可能是选择性的，那么此时就适合使用“发送”按钮以用文案的方式对审核行为进行暗示和隐喻。但这种场景一定是非常少的，所以这种使用要比较谨慎，以下例子的使用文案就存在明显问题：
“提交”使用场景不符
这几个按钮文案因为使用场景近似，所以在有些情况下经常容易被混用，厘清了各自不同的使用场景，就可以用来作为今后弹窗按钮文案规范的指导，至少在使用类似文案时，可以多问自己一句：“这个文案有歧义吗？”
网友评论