發布於 

DevLog:使用者體驗 (1)

2 年後的我:都是幹話。自從用了 macOS 之後,反而希望越詳細越好。因此,不要這麼做

貢獻了一個新東西到某個 GitHub 儲存庫,其中主要是讓程式更適合使用者。有許多開發者常常犯下類似「錯誤訊息太艱深難懂」、「以為使用者會需要,但其實沒必要的」的錯誤,而這篇文章我會詳談為何我覺得開發者為何不應該犯這些錯誤。

錯誤訊息不應過於簡陋

此外,我把原本很醜的 if 表示式以 Map 改寫,同時我也讓訊息比較好懂,畢竟這個專案的目標客群是一般使用者,盡可能用些平易近人的錯誤訊息。

GitHub - YesPlayMusic, PR #9

為什麼錯誤訊息要平易近人?首先我們來看一個反例。

1
權杖錯誤。

你能一眼就看出來到底出了什麼問題,且該怎麼修正嗎?就連我這個稍有經驗的電腦使用者都不一定知道該怎麼修,更何況是一般使用者?

也因此,一個好的錯誤訊息要讓使用者知道這是怎麼了,和應該怎麼修。就以上面的錯誤訊息為例,我們可以寫得更加具體:

1
判斷權杖時發生錯誤。可能是因為閒置過久,或是沒有權限所致。

首先,前面的「具體錯誤」是給了解系統的人看的,這樣使用者詢問這些人時,他們才能清楚是哪個環節出錯。而後面的可能發生原因,就是給使用者看的。也因此,我們要盡可能避開專有名詞,用使用者能看懂的字眼,去告訴使用者大概是怎麼了。

現在使用者知道問題的可能原因了。但是,使用者知道原因,卻不知道怎麼修,這樣仍然不是合格的錯誤訊息。所以我們也要給出可能的解決方法。首先,我們先看解決方法的反例:

Microsoft 詞彙庫中的反例

「請聯絡您的系統管理員。」絕對不是解決方法,事實上 Microsoft 之前很喜歡使用「聯絡管理員」這種推卸責任的話語來掩蓋他們懶著寫解決方法的事實。

但是聯絡管理員真的有用嗎?事實上不少使用者自己就是「系統管理員」,難道是要聯絡自己嗎?所以解決方法的撰寫,要盡可能讓使用者能夠自己解決,而不是一直推卸。就以上面的錯誤訊息來說,我們可以改寫成這樣:

1
判斷權杖時發生錯誤。可能是因為閒置過久,或是沒有權限所致。請嘗試重新登入您的帳戶,或重新以有權限存取此系統的帳戶登入。

比起最一開始的錯誤訊息,我們讓開發者更好判斷錯誤的本因、讓使用者更好理解問題的可能原因以及怎麼解決,這樣便是最適合使用者和系統管理員的錯誤訊息。

不需要就不要寫

時間寶貴,別浪費時間在沒人用的功能上。寫太多功能,除了程式本身會變得十分臃腫,也會使核心功能的維護時間被寫新功能的開發時間佔據,導致程式日漸不穩定。

此外,不要一股腦把所有能拿到的東西都塞進去使用者介面裡面,因為使用者不需要也看不懂,放太多只會讓介面變得十分混亂。舉個現實中的例子,假如你拿到這些資料:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
// kb/s
currentSpeed: 500, // 目前速度
// byte
totalSize: 100000000, // 總計大小
// byte
gotSize: 300000, // 收到的大小
respHeader: { // 伺服器回應的 header
server: 'blah',
cookies: {}
},
reqHeader: { // 用戶端要求的 header
userAgent: '???'
}
}

一個不好的使用者介面會把目前速度、總計大小、已下載的大小、伺服器和用戶端的回應放上去,甚至還會幫忙算 ETA 和經過時間,但是使用者真的需要這些資料嗎?

如果只是單純的遊戲下載器,我們只要告訴使用者目前進度和 ETA 就好。而如果是瀏覽器下載器,也不用精確到把詳細的回應告訴使用者。

所以,請秉持著「有需要再寫」原則,可以看看〈用 Golden Circle 從初衷找出需求〉,了解怎麼利用輔助工具幫你找到最需要的核心功能。


本網誌所有文章除特別聲明外,均採用 CC BY-NC-SA 4.0 授權條款。轉載請註明出處。

本站由 @pan93412 建立,使用 Stellar 作為主題。