今天，想要來和大家聊聊「系統提示訊息」。
在17年的數位產品開發生涯裡，有三個項目，是我覺得在開始開發前，必須要先講清楚的。
其中一個就是「系統提示訊息」。
你可能會想問，這有甚麼好聊的，不就是「提示訊息」嗎？
其實，「系統提示訊息」也是有蠻大的學問的。
為什麼這麼說？
給大家三秒鐘的時間想想，我們甚麼時候會用到「系統提示訊息」？
3…2…1…好，時間到
沒錯，答案就是「出現錯誤」的時候，而且是「用戶操作錯誤」的時候。「系統提示訊息」就用來提供給用戶回饋，及團隊追查錯誤的。
假設一個情境，用戶今天興高彩烈的使用了你的產品，結果無法註冊，甚至一直註冊失敗，你覺得用戶會有怎樣的反應？我想大多數的用戶就會直接選擇離開，好一點的客戶才會聯繫客服反應，而且這些會反應的客戶其實是少數，因為大部分的人都會覺得很麻煩，很多時候我自己也是這樣的狀況。
那這些反應給客服的用戶，通常詢問客服後，我們都會問甚麼問題？是不是會問他們「是否有跳出錯誤訊息？」，或是請他們「截圖」，當然有些時候要請用戶點開F12，開啟「開發工具網頁」，這時候大多數的用戶就會開始罵人了…。
那為什麼要問這個問題？答案很簡單，就是要提供給技術人員確認「問題發生的狀況」。
下列幾種提示訊息，你們覺得哪一種是比較好的提示訊息？
範例(A)：註冊失敗。
範例(B)：您所在地區無法註冊。
範例(C)：註冊失敗。(3001)
我想，這應該是很容易回答的。
當然，範例(A)是最不好的形式，雖然他也是提供給用戶一個清楚的回饋，可是不知道為什麼會失敗，這樣用戶還是會持續地去操作，直到用戶失去耐性，接下來就是失去這個用戶了。
那範例(B)和(C)，各是用在甚麼地方呢？
範例(B)，其實是對用戶相對貼心的，會把用戶操作失敗的原因都清楚地告知，但是有些時候回饋的內容也需要拿捏，像範例(B-2)，寫得非常的詳細，但是其實反而會造成閱讀上的障礙，這樣就顯得有點過頭了。
範例(C)，則是工程師最常使用的方式，因為在開發過程中，會有一份文件，叫做「系統錯誤碼(System Error Code)」，而開發過程中會先預想到的錯誤狀況，就會先編列在這份文件上，然後逐步更新，範例(C)中的3001，指的就會是這份文件中的一個編號，工程師就會針對這個編碼，直接去看文件，或是針對紀錄操作錯誤的紀錄(log)去搜尋。
系統錯誤碼(System Error Code)的文件可能會像下列表格：
| SysErrCode | 內容 |
| 3001 | 註冊時的IP不合法 |
| 3002 | 註冊帳號格式不正確 |
| 3003 | 註冊密碼格式不正確 |
| 3004 | 註冊帳號已存在 |
透過這個表格，我們大概可以理解一件事，就是要盡可能地列舉出「導致註冊失敗」的原因。
當然，理想是這樣沒錯。只是在實務上，就容易產生一個認知不對等的部分。
由於需求規格文件的制定，大多數是由PM決定或是撰寫，可是這份「系統錯誤碼(System Error Code)」的文件，卻多半是由工程師去維護，於是就會變成一種狀況。
(※延伸閱讀：搞懂規格書，讓你的團隊再也不用通靈)
PM想像的提示訊息，長的是範例(B)，但是又不是所有的PM可以把全部可能列出，於是大多數可能介於範例(A)和(B)之間。
而工程師做出來的提示訊息，也是範例(A)，因為規格書上並沒有說要把「系統錯誤碼(System Error Code)」顯示出來，「系統錯誤碼(System Error Code)」只會存在工程師紀錄的log上。
於是，在第一版出來後的提示訊息，蠻高的機率長的是「範例(A)」，而不是範例(B)或(C)。
那要如何解決這樣的問題？
其實，只要將「系統錯誤碼(System Error Code)的文件」改由PM與工程師共同維護即可，如下：
| SysErrCode | 內容 (PM與工程師共同增加) | 用戶端顯示 (由PM定義) | 系統端紀錄 (由工程師定義) |
| 1001 | 登入帳號不存在 | 您輸入的帳號與密碼不相符。 | login account error. (1001) |
| 1002 | 登入密碼錯誤 | 您輸入的帳號與密碼不相符。 | login password error. (1002) |
| 3001 | 註冊時的IP不合法 | 您所在的地區無法註冊。 | registration failed. (3001) |
| 3002 | 註冊帳號格式不正確 | 您輸入的帳號格式不符。 | registration failed. (3002) |
| 3003 | 註冊密碼格式不正確 | 您輸入的密碼格式不符。 | registration failed. (3003) |
| 3004 | 註冊帳號已存在 | 您輸入的帳號已存在。 | registration failed. (3004) |
| 3005 | token 已失效 | 系統發生異常。(3005) | token failed. (3005) |
而這份表格，有幾個需要注意的地方：
1. SysErrCode編碼規則：建議由技術主管定義，其他人配合執行，如果由多人定義的話，到時候編號會難以規範遵守。
2. SysErrCode只能增加：可以廢棄某個編碼，但是不能刪除或進行置換，如果之後將3004改為3007，哪未來搜尋3004的紀錄時，需要近一步確認實際的內容，也會浪費多餘的時間。
3. SysErrCode編碼唯一：一個編碼只能對應一種狀態，如果有兩種以上，當錯誤發生時，還要進行人為的判斷，也就失去定義編碼的用意。
4. SysErrCode內容擴充：PM及工程師都可以增加，但是建議PM針對產品規格上的規則撰寫，工程師針對開發及系統面的問題撰寫，因為系統相關的錯誤，PM並不一定能掌握到，也避免到時候互相責怪對方沒有撰寫。
5. 系統提示訊息的顯示：分為兩個部分，一個為「用戶端顯示」，另一個為「系統端顯示」。
(1) 用戶端顯示：由PM負責定義，這部份顯示的內容是提供給用戶閱讀。需要注意一點，很多時候避免讓部分別有用心的用戶，做一些不法的操作，就會避免將精準的回饋給用戶。
例如列表中的1001及1002，很多時候避免直接顯示「密碼錯誤」，而是會用「帳號與密碼不相符」來做混淆，降低盜帳號的風險。
或是列表中的3005，很多系統異常的狀況，也不會願意讓用戶知道太多，於是最常看到的就是類似這樣的顯示「系統發生異常。(3005)」
(2) 系統端顯示：這部分指的是被記錄到log裡的資料，通常都是用英文紀錄，當然，英文比較好的工程師就會願意寫，但是，還是有部分工程師比較不願意，就會寫一個大概，重點就會是後面的SysErrCode。不過這部分，就是看工程師的習慣，團隊有一個共同的規範即可。
很多時候，剛開始接觸軟體開發的PM，基本上都會忽略「系統提示訊息」這個部分，甚至不知道要定義這件事。當然，初期還不會遇到狀況，但是到中後期，開始進行測試時，就會發現，用戶的體驗很容易因為「提示訊息的不清楚」，導致「操作中斷」，然後不知道下一步要做甚麼。
又或者是當發生錯誤時，跑去問技術是甚麼原因，技術回說要查查，然後說這有幾種可能，也才會意識到，這樣追查錯誤很沒效率。最後，還是需要重新花時間定義每一個狀況。不如，在開發初期的時候，就先把「系統提示訊息」定義清楚。
系統提示訊息做的好，用戶不會留下來；
系統提示訊息做不好，用戶會留不下來。
《如果覺得這邊文章有幫到你，歡迎請我喝杯咖啡》
——–
大家好，我是 數位產品開發教練 – 陳俊聖/廣三/HeroMi
17年數位產品開發經驗。經手至少80個大小專案。
擅長解決與工程師的溝通問題，幫你建構工程思維。
如果有任何想法，歡迎留言或發信給我，希望可以幫到你
我的信箱：info@hero-mi.com
*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。
留言