本篇再來討論一下幾個跟問卷奖蔓、交流赞草、用戶反饋、用戶評價吆鹤、社區(qū)等相關(guān)度較高的按鈕文案厨疙。這幾個按鈕文案分別是：“提交”、“發(fā)送”疑务、“發(fā)布”沾凄。
在使用“提交”作為彈窗按鈕文案時，適用的場景主要包括彈窗本身自帶表單的知允，同時將用戶編輯的信息單向傳送至服務(wù)器或服務(wù)中心進行審核等情況撒蟀，不是說在這些場景下服務(wù)器或服務(wù)中心不會對用戶提交行為進行反饋，而是這種反饋是異步（asynchronism）的温鸽，或有一定選擇的保屯。
“提交”按鈕文案的用戶的心智模型如下圖所示：
在使用“發(fā)送”作為彈窗按鈕文案時，適用的場景是一種平等的交流場景涤垫，或期待對方能快速給出反饋的情況姑尺，雖然發(fā)送后接收方不會做出必然反饋或快速反饋的承諾，但用戶的心智模型相比“提交”而言雹姊，是在期待一種更快速股缸，更及時的回復(fù)的。有些意見反饋頁為了增加即時性的感覺吱雏，甚至把反饋界面設(shè)計成聊天界面以緩解用戶期待反饋是的焦慮感敦姻，提升用戶體驗。
“發(fā)送”按鈕文案用戶的心智模型圖如下：
所以相較于“提交”歧杏，使用“發(fā)送”在某些場景下镰惦，如提交問題反饋時，可以起到適當減輕用戶等待焦慮犬绒，減少跳出率等作用旺入，但前提是要提高客服反饋的速度以及每件必復(fù)，以符合用戶的心理預(yù)期，如果提供的反饋非常慢或者是選擇性回復(fù)茵瘾，就不能用“發(fā)送”按鈕文案礼华。
至于“發(fā)布”這個彈窗按鈕文案，一般不會在前面兩種應(yīng)該使用“提交”和“發(fā)送”按鈕文案的場景中被混用拗秘，因為發(fā)布的使用場景范圍比較窄圣絮，一般用戶用戶填寫的信息發(fā)布于公共區(qū)域，且用戶在點擊這個按鈕的同時雕旨，認可系統(tǒng)的這種行為扮匠。
其實目前在互聯(lián)網(wǎng)行業(yè)，為了防止垃圾信息營銷或不良信息控制或敏感信息控制凡涩，發(fā)布的內(nèi)容需要人工審核或機器人審核后才顯示也基本成為了標配棒搜，這時候彈窗按鈕的文案究竟應(yīng)該是“發(fā)布”還是“提交”（盡量不要使用“發(fā)送”），就需要看場景需要了活箕。
在某些場景下力麸，如果系統(tǒng)想要減少或消除用戶對于發(fā)布信息需要審核這個行為的感知，就應(yīng)當使用“發(fā)布”按鈕讹蘑，有些系統(tǒng)在同時還會在本地生成用戶提交信息的“鏡像”出現(xiàn)在發(fā)布區(qū)域末盔，但實際上該信息僅發(fā)布用戶可見，真正的用戶的發(fā)布信息還在服務(wù)器端等待審核座慰，但通過這些方式可以緩解用戶焦慮，提升產(chǎn)品使用的劉暢感翠拣。
如果系統(tǒng)想要明確告知用戶發(fā)布的信息需要系統(tǒng)進行審核后才能顯示版仔，且這種審核可能是異步的，或發(fā)布的內(nèi)容可能是選擇性的误墓，那么此時就適合使用“發(fā)送”按鈕以用文案的方式對審核行為進行暗示和隱喻蛮粮。但這種場景一定是非常少的，所以這種使用要比較謹慎谜慌，以下例子的使用文案就存在明顯問題：
這幾個按鈕文案因為使用場景近似然想，所以在有些情況下經(jīng)常容易被混用，厘清了各自不同的使用場景欣范，就可以用來作為今后彈窗按鈕文案規(guī)范的指導(dǎo)变泄，至少在使用類似文案時，可以多問自己一句：“這個文案有歧義嗎恼琼？”
