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

Lai_發表於2017-08-31
谷歌

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

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

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

但是當你為開發者構建產品時，使用者體驗同樣也很重要。人們往往會忘記開發人員也是使用者，從本質上來說，軟體開發是一項不僅受限於計算機的工作方式，而且也受限於程式設計師工作方式的人類活動。誠然，通常情況下開發人員的數量要比普通消費者少，但是開發人員所使用工具的可用性越高，越能使他們花費精力去為使用者創造價值。因此，就產品來說，開發人員的使用者體驗和普通消費者的同樣重要。在本文中，我將介紹為開發人員設計的開發者體驗，闡述我們在谷歌對它進行評估的一種方法，並分享一些我們在開展 Flutter（一個構建美觀移動應用的新型 SDK）專案時，從一個具體研究中學到的經驗教訓。

為開發人員設計開發者體驗並不是一個新鮮的想法。開發人員使用者體驗的相關研究可以追溯到早期計算時代，因為在一定程度上，當時所有的使用者都是開發者。出版於 1971 年的 「程式開發心理學」 是這個領域的里程碑式的著作。當我們談到開發者體驗，特別是將這個術語應用於 SDK 或庫時，我們通常會考慮產品的三個方面：

  • API 設計，包括類、方法和變數的命名，API 的抽象級別，API 的組織以及 API 的呼叫方式。
  • 文件，包括 API 參考和其他學習資源，如教材、操作指南和開發人員指南。
  • 工具，涉及到有助於編輯、除錯和測試程式碼的命令列介面（CLI）和 GUI 工具。比如，研究 表明，IDE 中的自動完成功能對如何在程式設計中發現和使用 API 有很大的影響

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

我們如何觀察開發人員的使用者體驗？

我們用來評估開發人員使用者體驗的一種研究方法是觀察真正的開發者如何使用我們的 SDK 和開發工具來執行一個實際的程式設計任務。這種被稱為使用者測試的方法，被廣泛應用於消費者 UX 研究，我們對它做出調整來評估為開發者設計的產品。在關於 Flutter 的具體研究中，我們邀請了 8 位專業開發人員，請他們分別執行上面的模型。

在這個過程中涉及到的一個關鍵方法是 有聲思維法。這是 Clayton Lewis 在 IBM 研發的口頭報告協議，能夠幫助我們瞭解參與者行為背後的原因。我們給了參與者以下說明：

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

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

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

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

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

1. 提供大量的示例，並有效地展示

在幾輪使用者測試之後，能夠明顯看出開發人員想從示例中學習如何使用新的 SDK。但是問題並不在於 Flutter 沒有提供足夠的例子 -- 它的 Github 資料庫中有 大量的例子。問題在於，這些例子沒有被組織起來，以一種真正對我們研究的參與者有幫助的方式呈現。出現這樣的問題有兩個原因：

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

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

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

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

幾個 Flutter 團隊的工程師通過直播觀察了使用者測試，他們被一些參與者經歷的挑戰所觸動。因此，該團隊已經開始持續地向 Flutter 的 API 文件（例如，ListView 和 Card）中增加更多示例程式碼。

此外，團隊開始為更大的程式碼示例構建 一個精心策劃的視覺目錄。現在只有少數示例，但是每個示例都有截圖和完整可執行的程式碼，所以發開人員可以很快確定一個示例是否對其問題有用。

2. 適應開發人員的認知能力

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

new Card(
 child: new Container(
   child: new Row(
       children: [
         titleSection,
         new Container(
           child: new Row(
               children: [
                 phoneNumber,
                 new Container(
                   child: emailWidget
                 ),
                 ]
            )
          )
        ]
     )
   )
)複製程式碼

「你能告訴我你想輸出什麼嗎？」（主持人）

[出聲思考] 「哦，我或許應該用列而不是行。」（P6）

我們轉向認知心理學尋求解釋。事實證明，用程式碼構建佈局需要對物體之間的空間關係進行推理的能力，認知心理學家將其視為 空間視覺化能力。正是這種能力影響了一個人有多麼擅長解釋駕駛方向或者轉動魔方。

這一發現改變了一些團隊成員對於視覺化 UI 構建器的看法。該團隊非常高興能夠看到社群驅動在這方面的探索，例如名為 Flutter Studio 的基於 Web 的 UI 構建器。

3. 促進識別而非回憶

使用者介面應該避免強迫使用者回憶資訊（比如一個隱晦的命令或者引數），是眾所周知的 使用者體驗原則。相反，使用者介面應該允許使用者識別出可能的操作過程。

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

body: new Card(
  child: new Text(
    ‘1625 Charleston Road, Mountain View, CA 94043’
  )
),複製程式碼

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

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

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

  • 總結小部件的佈局行為，使它們更易於理解。
  • 提供同時含有程式碼和圖片的佈局樣例，將一些回憶任務轉變為識別任務。
  • 提供一個 Chrome-style 的檢查器來顯示小部件屬性的“計算值”。

4. 預料到開發人員會對“就在眼前”的東西視而不見

一個讓 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 按鈕。此外，一些工程師一直在研究一種可靠的方法，為需要它的使用者提供儲存時重新載入的功能。

5. 不要假定程式設計師會像你期望的那樣閱讀出現在程式碼中的英語

在 Flutter 中，一切都是一個部件。使用者介面主要通過巢狀部件組成。一些部件只有一個子部件，而其他部件則有多個子部件。這個區別是由於部件類的屬性是『一個子部件』（child）」還是『多個子部件』（children）。聽起來很明確，對吧？

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

「我在想『子部件』（child）是否可以是多個。我能傳遞一批子部件進去，或者說真的可能只有一個子部件？」(P2)

「所以『子部件』（child）將是四件事，第一項、一個分隔符和另外兩項。」(P2)

這種對屬性名稱語義的錯誤理解導致了以下的錯誤程式碼：

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

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

結論

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

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章