確認(rèn)框，顧名思義，對關(guān)鍵的用戶行為進行確認(rèn)，比如“詢問是否刪除”，“告知已刪除”。根據(jù)網(wǎng)上的觀察，發(fā)現(xiàn)有的網(wǎng)站對確認(rèn)框的設(shè)計缺乏合理性。本文談?wù)勛约旱乃伎肌?/p>

類別

根據(jù)觸發(fā)目的，確認(rèn)框分為兩類：詢問和告知。

轉(zhuǎn)推的確認(rèn)框

詢問，類似 Javascript 里的 confirm()，即：是否去做？

Flickr 的告知

告知，類似 Javascript 里的 alert()，即：做的狀態(tài)。

必要性

任何阻礙（打斷）用戶行為的動作，都應(yīng)該三思而后行。冷靜下來，我們真的、一定、必須打斷用戶的動作嗎？不妨思考下面三個問題，來考量“必要性”。

• 是。既然是用戶自己主動做了這個決定，那么確認(rèn)框有設(shè)計過度之嫌
• 不是，但用戶容易誤操作。先解決“誤操作‘的問題，再來談確認(rèn)框吧
• 不是。剔除確認(rèn)框

• 不能。真的不能嗎？難道不知道這對于用戶來說非常重要嗎
• 真的不能。使用確認(rèn)框
• 能。剔除之

• 不可以。真的不可以嗎？流程上不能再優(yōu)化了嗎
• 真的不可以。使用確認(rèn)框
• 可以。剔除之

必要性（上新浪微博，下騰訊微博）

兩大微博都只能最多添加10個標(biāo)簽，超出限制后，它們的確認(rèn)框如上。孰優(yōu)孰劣？

設(shè)計

做確認(rèn)框，就要保證其可用性。

根據(jù)可控的程度分為：原生和彈出層兩種。

Javascript 原生類型

JS 代碼原生的 confirm() 確認(rèn)框好處只有一個，那就是編碼方便。弊端有：

• 樣式因操作系統(tǒng)（和瀏覽器）而異
• 體驗無法與全站融洽
• 無法更改按鈕文案和樣式
• 沒有檔次
• 沒有情感

彈出層類型

注意：這里談的不是彈出層，而是彈出層類型的確認(rèn)框。

彈出層，因為是純手工編寫，完全可控，宏觀上有：

• 遮罩。使用遮罩，因為確認(rèn)框里的內(nèi)容很重要。顏色則取決于網(wǎng)站的情感基調(diào)，與重要性無關(guān)（因為真的很重要）；保持遮罩層顏色的統(tǒng)一
• 位置。相對居中
• 標(biāo)題。不設(shè)置標(biāo)題
• 內(nèi)容格式。左對齊，具體格式依內(nèi)容而定
• 按鈕格式。居中或右對齊
• 圖片。沒有，或者最多一個
• 移動?？梢砸苿樱⒈３譂L動
• 退出響應(yīng)。必須點擊某個按鈕才能做出相應(yīng)響應(yīng)，因為確認(rèn)框很重要。同理，不設(shè)置右上角的 “×”
• 快捷鍵?？梢钥紤]，記得照顧視覺障礙的用戶

不多一個字

• 說匹配用戶教育程度的語言
• 寫出文案后，逐字刪除，除非造成歧義
• 照顧用戶的情感。這里多一個字，勝一萬字

條理清晰

• 格式清晰
• 邏輯清晰

是的，有時候腦袋一熱，邏輯就亂了。清晰的格式有助于理順（自己和用戶的）邏輯。

注明后果

再說一遍，真的很重要。

不使用判斷詞和代詞

僅僅寫“是”和“否”不如寫“刪除”和“取消”直接。

擺放

Flickr 混亂的按鈕順序

我們習(xí)慣說“是否”，我們說“Yes or No”，那么，就按照這個順序來設(shè)置按鈕的擺放順序。（反過來也行，）務(wù)必在全站統(tǒng)一，不要一會左一會右，你叫用戶點哪？

樣式

• 與全站按鈕的樣式統(tǒng)一。不推薦使用 HTML 內(nèi)置的 按鈕，畢竟已經(jīng)到這一步了，再多做一點吧
• 分清主次。鼓勵用戶點擊的按鈕使用突出 / 鮮明的顏色，反之使用常色，或者干脆使用文字鏈接的形式

“取消”按鈕看上去就不能點

• 避免使用灰色。因為灰色看上去無法點擊。白色亦不贊同

選例分析

選取了三個“拖入到黑名單（阻止該人）”的例子。

豆瓣：把某人拖黑

亮點：

1. 不多一個字
2. 邏輯清晰
3. 注明后果
4. 確定=確定，避免了不能改動按鈕文案的硬傷

谷歌+：阻止某人（把某人拖黑）

亮點：

1. 囊括了豆瓣的全部亮點
2. 體驗統(tǒng)一
3. 格式清晰
4. 分清主次（更推薦使用醒目的紅色）
5. 不使用代詞
6. 可以挽回
7. 通過照片喚起情感

知乎：把某人拖黑

延伸閱讀

1. 小轟 《可用性案例分析》?http://cuikai-wh.com/blog/1543

來源：http://cuikai-wh.com/blog/1924