你有沒有重視開發者體驗？
英文原文：APIs for Humans: The Rise of Developer Experience (DX)
做應用開發的都知道要重視用戶體驗，因為如果體驗不好，功能再強也沒人用。同樣道理，當你的用戶是開發者時，如果不注意服侍好他們，開發者也會 離你而去。而在軟件蠶食一切，平臺化的背景下，各個公司都希望通過開放 API 等手段打造自己的應用生態體系，但是他們往往卻忽視了開發者體驗。所以你也許需要看看 HelloSign 的這篇開發者體驗指南。
用戶體驗（UX）是許多消費者軟件的最高優先級。簡化復雜交互為有意義的用戶體驗是技術公司的一項重要的競爭優勢。
不過如果你的產品是 API，你的最終用戶是開發者呢？如何才能給他們設計一個好的體驗呢？
設計實現你商業目標的 API 意味著要專注于開發者體驗（DX）。要想實現這一點需要你有同理心，理解你的受眾。
到底什么是 DX？
一般而言，DX（Developer Experience ）是指開發者使用你 API 時的感覺，所以是感性的。它是開發者跟你的 API 交互時所有體驗的匯總。但這個東西 IT 業以往是不怎么關注的。
相反我們討論的是更具體的東西：比如性能、伸縮性等。
我們通常預期開發者是聰明的，因此不會在確保其體驗上面費太多功夫。但隨著向 API 遷移變成了現狀，業界終于慢慢開始意識到 DX 的價值。
體驗是重要的
DX 是你使用 API 時所有體驗的總和。如果這當中有很多體驗都不好的，他們就不想用了。然后跟朋友抱怨你的 API。更糟的是，如果你的競爭對手 DX 更好，他們可能就會轉過去了。
反之，如果你的對手不注意開發者體驗，那你吸引更多用戶的機會來了。如果兩個競爭對手的 API 類似但其中一個對開發者更加友好，聚焦 DX 的公司就會擁有競爭優勢。
此外，開發者的時間是有限的，你的 API 不應該讓他們付出太多的時間和精力才能理解和實現。擁有很好的 DX 是創建幫助滿足你商業目標和用戶目標的 API 的關鍵。
話是這么說，但 DX 并非靈丹妙藥，只是讓你的 API 取得成功的因素之一。功能性幾乎總是戰勝可用性。如果你做的東西不是開發者想要的，那 DX 再好也白搭。但如果你和對手都提供了開發者想用的東西，那 DX 就至關重要了。
把同理心作為 DX 原則指南
要想實現卓越開發者體驗，API 設計師需要理解同理心的作用。雖說這個道理聽起來挺簡單，但操作起來卻很困難，原因有這么幾個。
首先，同理心往往被誤解。一般而言，同理心是指理解另一個人情緒狀態的能力。這可不是想象一下就行的。俗話說，鞋子合不合腳，自己穿了才知道。你對某種情況作出的反應換一個人可能就很不一樣。
比方說你是一名開發者或產品經理，正在開發一個 API，那你肯定對 API 的工作方式很熟悉。你會理解那些設計決策、知道所有奇怪的地方，并且已經適應那些痛點，也知道那些邊界情況在哪里。
但外面的開發者就未必有你那么熟悉了，對你來說理所應當的事情對他們卻是全新的。對于這類人來說可用性是關鍵。
成就你的用戶
作為 API 的設計者當然希望開發的 API 功能性和可用性俱佳，這樣才能喚起用戶積極的情緒反應。那我們究竟希望用戶對我們的 API 有什么樣的感覺呢？我們希望創造什么樣的體驗呢？
大多數公司不會提這樣的問題，因為答案似乎很明顯：我們希望用戶熱愛我們的公司和產品。這種想法有個很大的問題，因為大多數用戶并不關心你的公司和產品。用戶周圍是各種各樣的公司和產品，他們為什么要對你的 API 有不同的感覺。
我們 API 的用戶是人，人往往注意的是自己。因此，我們希望開發設計 API 能讓他們出色。他們會希望開發出一個出色的功能，好讓自己能做朋友和老板面前顯擺。他們希望有我是天才的感覺。因此，作為 API 設計者應該竭盡所能讓 API 帶給他們那種感覺。
高效的 API 必須是出色的功能和出色的可用性的結合。開發者交付功能面臨著巨大的壓力—盡可能幫助他們可確保他們對集成和你的 API 感覺良好。
創建移情的 API
根據前面的 DX 原則指南，我們可以推導出一些實現細節。
1）溝通：要容易理解
有一份清晰且最新的文檔是一個好的開頭，這樣會方便你的用戶理解 API 怎么用。因為用戶要花可觀的時間閱讀文檔，所以這應該是產品要考慮的一部分。
這方面 Stripe 做得非常棒。他們的文檔介紹完整組織合理，API 參考指南很清晰。左欄的選擇變了以后右欄也會跟著變。甚至還有一個固定的半頁眉欄，讓你可以隨時切換編程語言。
除了 API 文檔外，有一份全面的 “入門指南” 可以加快開發者熟悉需要掌握的東西。
這方面 Twilio 的 API 頁面是一個很好的例子—他們有文檔鏈接，但同時也放了許多其他有用的東西，包括使用方法、快速入門等。這對開發者觀看想要做的例子大有幫助，并且讓他們看到 API 還可以做什么事情，對 API 本身也提供了一個很好的概覽。
2）要易用
這一點不難理解。API 設計者應盡量降低 API 的使用門檻，從而提高采用率和整體用戶滿意度。舉措包括考慮盡量減少非編碼的安裝，像創建賬號、app、注冊付費套餐、跟銷售談判等要減少到最少或避免。
此外，考慮向你的目標受眾提供 SDK。你仍然希望開發者只通過 HTTP 跟你的 API 交互，但提供多語言 SDK 可以讓開發者方便地跟你的 API 交互。
很大一部分開發者都希望 SDK 支持自己的語言，如果你的 SDK 支持他們的語言，那他們也會更愿意使用使用你的 API。
當然，維護自己團隊不熟悉的語言的成本也會更高，所以從團隊熟悉的語言開始也許會好一點。
如果你的目標是初創企業，那很可能他們會使用 JavaScript 或 Ruby，所以用這些語言開發 SDK 能夠收獲很大一部分的此類用戶。如果你針對的是企業客戶，也許可以考慮 SDK 對 .NET 和 Java 的支持。
SDK 維護的另一個管理策略是把 SDK 開源，讓社區提交 pull 請求。這樣用戶可以根據需求變更 SDK，或者在遇到 bug 時報告或修改。這也是獲得有關 SDK 可用性用戶反饋的一個很好的方式。
3）要易于調試
出錯總是難免的，bug 沒有是不可能的。但是由于 API 的天生異步性，其調試就顯得特別困難。想跟蹤到底哪里出錯很難，無論是用戶端還是 API 端都如此。
API 調試不應該很難。解決方案是提供 API 儀表盤。任何設計得當的 API 都應該有儀表盤，這樣開發者可以去看看自己額請求和調用情況，一眼就能知道哪里出問題。這會節省開發者大量的時間。
4）要易于求助
有時候用戶會遇到自己無法解決的問題。這種情況下，要是他們能夠得到你的幫助就好了。可以設立一支專門的 API 支撐團隊，不行的話可以讓你的開發者輪流提供 API 支持。
這么做有雙重目的，一是幫助用戶，二是幫助鞏固你的開發團隊對用戶的同理心。盯住 GitHub 和 StackOverflow 上面的問題。讓開發者通過 Slack、HipChat、IRC 之類的渠道能很方便地找到你。
5）不要向開發者用戶推銷。要幫助他們、給社區做貢獻
營銷影響著用戶對你產品的感覺。但開發者憎恨傳統的營銷，所以要尊重他們的智慧，避免那種沒有意義的推銷方式。相反，幫助他們解決問題、盡你所能給社區做貢獻才是正道。
開發者是消費和理解信息的專家。他們閱讀面廣、受教育程度高。你要是生硬地推銷他們會知道并無視。這還會影響你的品牌，折損開發者體驗。
同時這還會讓開發者懷疑你的動機。他們自己知道什么東西對他們和自己公司最好。如果你需要向他們推銷，他們會懷疑你是因為產品不夠好才這么做。
相反的做法是，尋求給開發者社區做貢獻，建立你自己的社區。盡可能博客多交付內容，招聘布道師傳授課程舉辦講座，給開源項目做貢獻。你做的那些吸引開發者為你的公司工作的事情一樣可以用來吸引其他開發者用你的 API。
為什么你不能創建出移情的 API
設計 API 很簡單。能干的開發者 1 小時就可以搞定。但設計移情的 API 則要困難得多。它需要對用戶以及某種程度上對自己的員工要有態度上的轉變。
1）康威定律
康威定律指出，“設計系統的組織……做出的設計只能是這些組織的溝通結構的復制品。” 康威定律一般用來討論軟件架構，但一樣適用于 API 設計。如果組織部把同理心內化為自己的文化，那他們對用戶產生同理心的可能性也很低。組織內缺乏同理心會在他們的產品身上體現，這也包括 API 設計。
2）太熟悉 API
雖然有點無辜，但缺乏同理心還可能是因為你太熟悉 API。這也很正常，API 的開發團隊天天跟它打交道自然熟得不得了，可能就忽視了他人未必能知道 API 是怎樣工作的。而這樣又會導致他們對批評有抵觸。
畢竟嘛，如果團隊覺得 API 很直觀但用戶不懂的話，他們會認為要么是用戶至上不夠，要么這種情況只是少數。意識到這種認識偏差的存在有助于采取措施強化對用戶的同理心。
3）無法獲得反饋
原因之三可能是公司無法征求到用戶反饋并確定優先級。理解客戶需求至關重要，而征求反饋并進行響應則是痛點。除非你向用戶提出明確的請求，一般他們都不會提供太多的反饋。要千方百計想辦法獲得用戶反饋，確保組織內有機制分析反饋并采取響應措施。