作者從實際工作出發(fā)，討論了表單設(shè)計中誤操作的背后思維。

這段時間，在準(zhǔn)備CRM升級改版工作，其中有一個可用性問題。

有部分用戶反饋添加工單功能的體驗不好，經(jīng)了解后，這些用戶需要經(jīng)常添加工單，而工單填寫的內(nèi)容較多，她們有時會不小心點到模態(tài)背景，把添加工單彈窗關(guān)閉了，而一關(guān)閉，原先填寫的內(nèi)容也會隨著刪除，浪費時間和精力。

在CRM中，內(nèi)容較多的表單都是采用側(cè)滑彈窗控件，彈窗的關(guān)閉方式共有4種，“點擊關(guān)閉圖標(biāo)”、“點擊模態(tài)背景”、“點擊收起圖標(biāo)”、“點擊底欄取消按鈕”，其中“點擊收起圖標(biāo)”方式所起作用不大，在實際場景中，也比較少人操作，所以這種方式在新版本中將被去掉，這里不做討論。

添加工單彈窗原設(shè)計

為什么容易誤操作？

從界面來看，“點擊關(guān)閉圖標(biāo)”“點擊底欄取消按鈕”的方式都沒有這個問題，因為操作精確度要求高，存在誤點擊可能性小，但是“點擊模態(tài)背景”的方式就不一樣了，在這個頁面中，模態(tài)背景和內(nèi)容區(qū)所占面積差不多，容易被誤點到。

所以第一個原因是模態(tài)背景較大，而第二個原因則是，在這么長的表單中，用戶有間隔保存的需求，但是保存按鈕卻沒有時刻被看到。

所以針對以上的原因，有了以下方案：

1. 加大內(nèi)容區(qū)面積，減少模態(tài)面積，同時把保存按鈕一欄固定懸浮于底部；
2. 點擊模態(tài)背景時，給二次確認(rèn)提示，同時把保存按鈕一欄固定懸浮于底部；
3. 去掉“點擊模態(tài)背景”關(guān)閉彈窗的方式，同時把保存按鈕一欄固定懸浮于底部。

但是這三個方案都存在或多或少的缺點：

第一個方案，只能從一定程度上減少誤點擊概率，不能完全解決問題；

第二個方案，如果只運用在工單模態(tài)或有操作復(fù)雜頁面，會影響用戶習(xí)慣，如果全部運用，那有的場景又不需要二次確認(rèn)，操作麻煩；

第三個方案，不管是運用在工單模態(tài)或有操作復(fù)雜頁面，還是運用全部頁面，都會影響用戶習(xí)慣，因為已經(jīng)有大部分用戶適應(yīng)了通過點擊模態(tài)背景來關(guān)閉彈窗的方式，而且反饋也是比較快捷方便的。

當(dāng)面對著這三個方案一籌莫展的時候，我開始想，是不是哪里弄錯了，或者思路是不是狹窄了被捆住了，是不是還有其他更好的方案。

后來，我發(fā)現(xiàn)這三種方案其實都是屬于防錯的措施，就是減少或防止用戶犯錯發(fā)生的機(jī)會。那如果允許用戶犯錯呢，犯錯之后再給補(bǔ)救措施呢，這樣一想，頓時有種豁然開朗的感覺。

再次分析需求，用戶在填寫表單過程中，誤點擊模態(tài)背景，把彈窗關(guān)閉了，重新進(jìn)來之后內(nèi)容被清除了，需要全部重填。

這個需求中，有兩個點可以抓住，一個是誤點擊，另一個重新進(jìn)來之后內(nèi)容被清除掉，之前的全部思考都集中在第一個點上，而忽略了第二個點。所以有了另一個方案，把重心放在容錯上，適當(dāng)防錯。

添加工單彈窗新方案

這個方案，判斷通過點擊模態(tài)彈窗方式關(guān)閉彈窗時是否處于編輯狀態(tài)，若處于編輯狀態(tài)，則在關(guān)閉彈窗的同時緩存已編輯數(shù)據(jù)，在用戶下次進(jìn)到彈窗時顯示恢復(fù)提醒，同時也加大內(nèi)容區(qū)面積，把保存按鈕固定懸浮于底部，真正地解決問題。

最后，這個方案也得到了反饋用戶和產(chǎn)品同事的認(rèn)可和支持。

分享這篇文章是因為感觸較深，“防錯”和“容錯”都是常見的可用性原則，但在日常工作中，“容錯”卻很少用到，甚至有時想不起來！

原本在運用上，就應(yīng)該是“防錯”在先，“容錯”在后，盡量先讓用戶不要出錯，出錯了也有補(bǔ)救措施。

但是現(xiàn)在很多時候只停留在防錯層面，一到“刪除”操作就給“二次確認(rèn)提示”，再不思考其他，好像是萬能的，但其實不然，有的場景并不適合，例如上述例子。所以不要成為遇到“刪除”只會“二次確認(rèn)”的交互，這著實不妙啊。

本文由 @奶茶喝光了 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。