[譯] 我是如何在谷歌做開發者使用者體驗的

<b>本文講的是[譯] 我是如何在谷歌做開發者使用者體驗的，</b>

<b></b>

基于 Flutter 的使用者調研進行說明

人們談論使用者體驗（UX）時，談論的對象通常是他們所熱愛的消費産品，比如：智能手機、消息應用或者一副耳機。

API 設計，包括類、方法和變量的命名，API 的抽象級别，API 的組織以及 API 的調用方式。

文檔，包括 API 參考和其他學習資源，如教材、操作指南和開發人員指南。

開發者體驗的這三大支柱相輔相成，是以需要打包來設計和評估。

「當你在程式設計練習時，請『出聲思考』。也就是說口頭描述你的思維發展變化的過程，包括你的疑惑和問題、你所考慮的解決政策，以及你做出決定的理由。」

我們進一步向參與者保證，我們評估的是 Flutter，而不是他們的程式設計技能：

「請記住我們正在測試 Flutter 的開發人員使用體驗，并非對您的考驗。是以任何讓您感到困惑的事情都是我們需要解決的。」

每一次的開發者測試，都是從通路參與者的背景作為熱身，然後留給他們大約 70 分鐘的時間來完成任務。在最後 10 分鐘，我們會詢問參與者的體驗。每次測試中，我們都會向身處單獨會議室的産品工程師團隊不公開地直播測試情況，包括測試者電腦顯示屏的内容。為了保護參與者的隐私，我們将使用編号（例如，P1、P2、P3 等）來辨別他們，而非他們在本文中的姓名。

是以，從這次的研究中我們對開發者的體驗有什麼了解呢？

首先，Flutter 的 Github 庫裡的代碼示例缺少截圖。當時，Flutter 的網站提供了一個連結，可以在其 Github 庫裡搜尋到包括特定小部件在内的所有代碼示例，但是參與者很難确認哪個示例會産生預期的結果。你必須在裝置或模拟器上運作示例代碼，才能看到小部件的外觀，這是沒有人願意費心去做的。

「連結到實際的代碼是很好的。但是除非看到輸出，否則很難選擇要使用哪一個。」 (P4)

第二，參與者期望在 API 文檔中看到示例代碼，而不是其他零散的地方。試錯是學習 API 的常用方法，API 文檔中的片段可以使這種學習方法得以實作。

「我點選『文檔』，但它是 API，而不是示例。」 (P4)

<a href="https://link.juejin.im/?target=https%3A%2F%2Fdocs.flutter.io%2Fflutter%2Fwidgets%2FListView-class.html" target="_blank"></a>

<a href="https://link.juejin.im/?target=https%3A%2F%2Fflutter.io%2Fcatalog%2Fsamples%2F" target="_blank"></a>

程式設計是一種認知高度緊張的活動。在這種情況下，我們發現一些開發人員很難隻用代碼編寫 UI 布局。在 Fluttter 應用程式中，建構布局涉及在樹中選擇和嵌套小部件。例如，要在咖啡館資訊卡中建構布局，需要正确地組織幾個行小部件和列小部件。這看起來并不是一項艱巨的任務，但是三名參與者在試圖建立這個布局時，搞混了行和列。

「你能告訴我你想輸出什麼嗎？」（主持人） [出聲思考] 「哦，我或許應該用列而不是行。」（P6）

這個原則和軟體開發有什麼關系？我們觀察到的一個問題是，很難直覺的了解 Flutter 部件的預設布局行為并弄明白如何改變它們。例如，參與者 P3 不知道為什麼卡片在預設情況下會縮小到它所包含的文本的大小。P3 難以解決如何使卡片填充整個螢幕寬度的問題。

「我想要的是讓它占據螢幕的整個寬度。」（P3）

當然，很多程式員最終會弄明白這個問題，但是他們下一次遇到同樣的問題時，他們需要回憶如何去做。對于開發人員來說，在這種情況下沒有可視的線索來識别出解決方案。

該團隊正在探索幾個方向，來減少建構布局中回憶的負擔：

總結小部件的布局行為，使它們更易于了解。

提供同時含有代碼和圖檔的布局樣例，将一些回憶任務轉變為識别任務。

提供一個 Chrome-style 的檢查器來顯示小部件屬性的“計算值”。

一個讓 Flutter 團隊感到自豪的特性是 Hot Reload。它允許開發人員在一秒内将改變應用到一個運作态的 App 中，而不會丢失應用程式的狀态。執行一次 Hot Reload 就像點選 IntelliJ IDE 中的一個按鈕，或者在控制台按下 “r” 一樣簡單。

然而，在前幾次的使用者測試研究中，研究小組對一些參與者在檔案儲存時觸發 Hot Reload 的預期感到困惑。盡管事實上，Hot Reload 按鈕啟動指令時就顯示在 入門引導的 gif 動畫中，他們怎麼會看不到 Hot Reload 按鈕呢？

結果表明，無視 Hot Reload 按鈕并期望在儲存時觸發重新加載的的參與者是 React Native 的使用者。他們告訴我們，在 React Native 中，Hot Reload 是在檔案儲存時自動執行的。

開發人員預先存在的心智模型會改變他們的感覺，并在一定程度上對 UI 元素産生『盲目性』。團隊增加了更多的視覺提示來幫助發現 Hot Reload 按鈕。此外，一些工程師一直在研究一種可靠的方法，為需要它的使用者提供儲存時重新加載的功能。

我們也是這樣認為的。然而，對一些參與者來說，單詞的單數形式并不能成功的表明隻有一個部件可以嵌套在目前的部件中。他們懷疑『子部件』（child）是否真的意味着『隻有一個』。

「我在想『子部件』（child）是否可以是多個。我能傳遞一批子部件進去，或者說真的可能隻有一個子部件？」(P2) 「是以『子部件』（child）将是四件事，第一項、一個分隔符和另外兩項。」(P2)

這種對屬性名稱語義的錯誤了解導緻了以下的錯誤代碼：

而且在這種情況下顯示的錯誤消息雖然準确，卻不足以将參與者推回到正确的路徑上：

新手程式員在這兒所犯的錯誤很容易被忽視。然而，看到專業開發人員浪費時間來處理簡單的問題讓團隊成員感到很不爽。是以在調查結果報告出來的幾天後，團隊成員進行了短期的修複工作。通過運作「flutter create」指令，将一個最有用的多個子部件『列』，添加到你獲得的應用程式模闆中。我們的目标是讓新手發開人員盡早了解『子部件』（child）和『多個子部件』（children）的差別，避免他們以後再浪費時間去弄清楚。除此之外，一些團隊成員也在研究一個更長期的解決方案，以改善錯誤資訊在此種情況和其他情況下的可操作性。

我們可以從觀察程式員使用 API 和應用所學中學到很多，來提高面對開發人員産品的使用者體驗。如果你編寫了代碼或建構了其他開發人員使用的工具，我們建議你觀察他們是如何使用它的。正如一位 Flutter 的工程師所說的，你總是能從觀察使用者研究中學到一些新的東西。随着軟體不斷推動世界的變化，我們要關愛研發人員，讓他們能盡可能高效開發，并保持心情愉快。

<b>原文釋出時間為：2017年8月31日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>