你為何那樣做？給工程師的使用者行為除錯指引

原文：Why’d You Do That?!? An Engineer’s Guide to Debugging User Behavior

作者:Edmond Lau ，The Effective Engineer 作者。 Soft & Share獲作者授權翻譯。

“為什麼我的程式沒有做到我預期它做的呢？ ”

简体中文版本

這是身為軟體工程師的我們每天會問自己的問題，而且我們也建立了全部的技能幫助我們在出錯時做程式碼的除錯。一些工具如 breakpoints 和 strace 讓我們檢查運行系統的狀況( state )。Assertions 和 print statements 讓我們能夠查證我們對程式行為的假設是否正確。 Minimal reproducible test cases去除分心，如此我們可將我們的注意力灌注到只跟故障系統相關的部分。如果沒有這些技術，每天的開發進度將慢很多。

那麼，另一個很類似的問題 — “為什麼我的使用者沒有做到我預期他/她們做的呢？”—我們很多人經常會把我們所知的程式碼除錯最佳實踐拋棄在腦後。

有可能我們獲取了新的使用者，但他們在第一次使用後就不再用了，對於這件事我們會如同在檢查程式碼一樣很努力地想要了解他們的想法。我們有可能落入沒完沒了地爭論要如何設計才對，卻沒去查證設計提案背後的假設。也許我們會花好幾個禮拜或好幾個月的時間將一層一層功能堆上去，卻沒去跟真正的使用者做最小版本測試，看看哪些功能是他/她們覺得跟自己相關的部分。

幸運的，我們可以扭轉情況。我們用來做程式除錯的心法和工具可以幫助我們解開使用者行為的神秘面紗並更有效地開發產品。

如同對你的程式碼除錯一樣，對使用者行為除錯

多年前，我參加 Google 相關 API 設計的科技論壇，由 Joshua Bloch 主講，他是 Java collections API 的首席架構師，也是 Effective Java 的作者。 Bloch說：當你為上千或上萬個開發者設計介面時，只要 API 設計有誤，就很有可能大幅提高成本，有可能需要更多的時間進入狀況或是花很多時間來修正誤用所造成的問題。好的設計，相反的，很容易了解而且不容易誤用。Bloch 進一步說明，甚至在寫任何程式碼前，他會寫一頁到兩頁的介面說明，然後實際地詢問工程師們(也許面對面，也可能線上討論)，了解他們會如何使用這 API。這是他的最小可行性產品 ( MVP – minimal viable product )— 一個讓他可以先不寫任何程式碼就能做 API 設計上任何問題的除錯。

我們為使用者做的最小可行性產品( MVP )相當於我們為所寫的程式做的最小可重現測試案例。在做最小可重現測試案例時，我們會問：什麼是表現出我們關心的錯誤行為準則的最小段程式碼？在做最小可行性產品時，我們會問：什麼是可驗證使用者行為是否符合我們期待的最小單位功能？這兩個技術都有類似的目的：幫助我們專注能量並花力氣到真正重要的地方。

學著去讀你使用者的想法

而且，正如檢查程式狀態( state )對於程式碼的除錯很重要，瞭解使用者在想什麼對於使用者行為除錯也是相當重要。

當一個產品有明顯的流量可做參考，分析網站與點擊紀錄也許足夠讓你做使用者行為的除錯。以 Etsy為例，採用一種叫做持續實驗的程序來設計他們的產品 ( 註一 )。當設計一個產品的頁面，他們將起草一個假設，例如“當使用者於產品頁面看到相關產品的圖像時將會買更多”。他們會做 A/B 測試來驗證這個假設，例如只展示給區隔的使用者相關產品的圖像。他們將應用這樣的行為研究測試結果來打造下一輪設計。

當度量如點入連結率、註冊率或購買率等，可以清楚判定成功與否時，運用這樣的 A/B 測試的技術就非常有用。當我們沒有夠多的樣本在統計上做可以辨識的測試，或想更深入探索使用者行為模式時，另一個很有用的途徑是研究互動日誌(session logs)。把使用者在日誌中的所有個人行為資訊連結起來, 我們可以建立一個有時間順序的使用者互動事件文本。研究使用者如何瀏覽產品以及採取了哪些行動將詳細畫出使用者的意圖，這通常無法從 A/B 測試的歸納數字中得知。案例如 Google 採用像 Session Viewer 這樣的工具來讀取並視覺化使用者如何完成搜索相關的事務。( 註二)

有時候，甚至互動日誌( session logs )也無法提供我們所需要的深度洞察。使用者測試在這狀況下就可能派得上用場。如我曾待過的 Quip，甚至在已經做了幾輪的新產品或新功能，也會積極地針對新的變更找真實的使用者測試。我們可能讓參與的客戶或早期使用者做一個功能的 beta 測試版，然後用書面或訪談的方式收集他們的回饋。或是我們可能運用如 usertesting.com 的服務散播任務腳本(a script of tasks )給線上使用者並把他們使用產品的詳細過程錄影下來，詳查他們的思考過程，這測試通常在一小時內。讓使用者測試成為產品開發中的一個正規環節，我們將更有信心判定哪些設計有效、哪些會失敗，以及應該在哪方面投入。

所以使用者行為除錯的工具其實就在我們眼前。既然我們不會在不確定程式中的每一小部分都各自可行的狀況下寫上千上萬行的程式，那為什麼我們要採用無效率的方法開發產品呢？請積極運用程式碼除錯那套想法到使用者行為的除錯。