DevLog：使用者體驗 (1)

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

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

錯誤訊息不應過於簡陋

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

GitHub - YesPlayMusic, PR #9

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

1

權杖錯誤。

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

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

1

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

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

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

「請聯絡您的系統管理員。」絕對不是解決方法，事實上 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 從初衷找出需求〉，了解怎麼利用輔助工具幫你找到最需要的核心功能。