起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從網上預約掛號說說：為什么容錯是可用性的重要原則之一？
在產品中，有很多因素可能導致用戶無法完成任務，或者完成任務的效率非常低，或錯誤率很高，而這些情況是可用性問題中最迫切需要解決的問題類型，在設計中應給予更多關注。
最近，因為疫情，看病掛號必須通過網上預約的方式。我用支付寶里的【醫療健康】應用幫家里人掛號，發現了一個嚴重的可用性問題，導致我差點就放棄了掛號?？捎眯詥栴}分為很多種，之前我有總結不同專家提出的設計原則。
這些可用性專家對設計原則有同有異，有些原則是所有專家都覺得很重要的，有些原則可能只有某位專家覺得它重要。于是我做了統計，想通過某個原則被專家提到的次數，給這些原則的重要性做個排序。
以下是我總結的設計原則圖，從上到下是依據統計和自己的理解的制作了設計原則的大致樹狀圖。這些原則也有迫切程度的區分，有些是直接影響是否可以使用的原則，有些是增加吸引力、情感體驗和粘性的，打造更完美的體驗的原則。
一個產品，如果核心流程有問題導致出錯，那談粘性、視覺美感都是奢談。
其重要性依次從上到下：
這6位專家都有提到容錯，這是一個影響用戶體驗的重要因素，尤其針對核心功能與任務的容錯。比如注冊、登錄、購物流程等。這也是為什么一個產品都反復打磨注冊、登錄等流程，如果用戶在這些環節出現錯誤或因某些原因沒辦法逃離掉，那后續的內容再精彩都沒有意義了。而一些核心任務也是可用性優化中優先級最靠前的。
很多時候并不一定是沒有路徑完成，而是這個路徑某部分由于某種原因沒法讓用戶正確認知，或者當出現錯誤，沒法幫助用戶從錯誤中及時回復，導致用戶停滯在某一個地方進退兩難，最終放棄。
我用支付寶的醫療健康預訂掛號就遇到了一個讓我沒法完成預約任務的問題，是在最后一步我將要付費時彈出一個需要我填寫個人信息的toast提示。最后通過問客服才解決了，如果沒有客服介入，我可能就放棄用這個app掛號了。
如下圖所示，在最后一步，當我覺得一切都完成，點擊付款時，突然彈出一個Toast,只持續短暫的1s左右就消失了。我大概只掃到“首頁”和“聯系電話”等一些字。
靜態截圖效果：
除了toast彈窗持續太短暫，字數太多的問題。另一個問題是“首頁”到底指的是哪里？是【支付寶】首頁，還是【醫療健康】的首頁？又或者是選擇的【醫院首頁】？在完成預約掛號的任務流程中，有大約10個頁面，到底是指哪里呢？下面是這個任務的流程圖，猜猜這個“首頁”是指哪個首頁？
是不是跟我當時一樣，找了半天也沒有找到【首頁】是指哪里？我找了半天也找不到，只有求助客服了，謝天謝地還有客服，它發我一個此操作入口的截圖，我才恍然大悟在哪里。
如下圖：
這個首頁原來是指醫院的首頁，在醫院首頁里選擇官方操作平臺后，會彈出一個Action Sheets，在里面選擇信息采集，之后就可以填寫【患者在京信息采集】了?？杉热贿@個操作是疫情期間的必須操作，為什么放action sheets里，放在這里本身就很隱蔽，用戶以為在首頁界面就可以找到“填寫個人信息”的相關文字、鏈接，誰會想到它藏在action sheets。
但剛才的Toast里,根本沒有提到過“信息采集”這幾個最關鍵的字，這讓用戶怎么找。
我好奇有多少人像我一樣通過客服介入才完成掛號流程，覺得應該不少。
這個例子里，文字描述在可用性中也是有重要意義的。描述一定要盡量明確清晰。文字的重要性只要你下載一個不熟悉的語言的應用，就知道文字描述對一個應用有多重要了。以下是我對這個可用性問題的優化建議。
優化1：最小成本的優化是更改這個toast彈窗里的文字描述，讓它更清晰，明確。
以下是我優化后的文案：
- 告訴用戶首頁是指個哪里？
- 告訴用戶填寫的頁面叫什么名字，這樣方便用戶查找。
- 盡量精簡語言，toast有時間限制，所以文字字數不宜過長。
- 可以把toast顯示時間設置長一些（1-2s）。
當然這種優化只是從成本最小的角度出發，但并不代表它是更合理的方式。因為這種方式中，用戶即使知道需要到哪里填寫表格，也需要一步步返回到醫院的首頁，還要再里面找“信息采集”頁面。效率非常之低。更好的方式應該是通過模態對話窗的形式讓用戶選擇，直接到信息采集頁進行填寫。
優化2：
改用對話框的形式，優化效果如下圖：
既然用戶點擊付款，說明這時用戶的唯一目的就是完成預約。而沒有填寫信息采集卡是攔在用戶目的前的唯一攔路虎，所以應該通過模態對話框，把用戶直接帶到相應頁面進行填寫（用戶點擊“前往”button），填寫后也應該直接返回此頁，而不應讓用戶再重新把掛號流程走一遍。還有沒有其他，更好的優化方式，可以留言討論：）
這個例子可以看出，有很多因素可能導致用戶無法完成任務，或者完成任務的效率非常低，或錯誤率很高，而這些情況是可用性問題中最迫切需要解決的問題類型，在設計中應給予更多關注。
本文由 @cating 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
神測
想問一下用戶去掛號，是不是都有明確的醫院、醫生、時間的需求，那我們在掛號的時候是不是根據用戶的病情，直接推有號的信息，這樣設計是不是使得用戶體驗更優
現在還遠遠沒有這么人性化吶，每家醫院的號源都是獨立的，而且用戶往往都是會有幾個鐘意的醫院，醫院的選擇涉及病人對醫院的喜好、看的病種以及離家距離等，比如有的病人喜歡去中醫院，有的喜歡協和醫院，有的看心腦血管會優先阜外醫院等。如果說未來更理想的狀態，應該是用戶設置幾個自己的偏好醫院（并且用戶可以對幾個醫院進行排名，就像高考的填報志愿一樣，優先選擇哪個，其次選擇哪個，再其次哪個），之后填寫當次的病情、病狀，以及可接受的看病時間（可能是某一天，也可能是某一段時間內都可），系統會根據這些信息智能推薦有號源的，這會讓掛號省事很多。但目前感覺這只是一種美好的愿景，現在實現起來有各種的障礙
想問一下用戶去掛號，是不是都有明確的醫院、醫生、時間的
如果信息采集是掛號的必要條件，那就不應該與掛號方式層級并列，而應該在選擇掛號預約后，先填寫信息，再進行預約，是相對比較合理的流程。因為用戶已經到達掛號確認這一步，用戶的期待是下一步支付后就掛號成功了，這時候再設一道「攔路虎」，用戶體驗肯定不會太好。
確實是這樣的，先進行預約的時候先判斷一下是否有個預約人的信息。
是的，其實這里的信息和購物后填寫地址、電話等個人信息的邏輯類似。因為有可能用戶想掛的沒有號，或者用戶只是來比較、瀏覽，所以信息填寫肯定要放在預約成功后（對標-首次購物，成功拍到商品后填寫地址信息），之后就應該填寫個人信息。因為這個掛號預約程序不同醫院不太一樣，有的醫院在這個流程中的方式更科學、友好，對比不同醫院的不同方式還挺有意思的。