你有没有重视开发者体验？
英文原文：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）无法获得反馈
原因之三可能是公司无法征求到用户反馈并确定优先级。理解客户需求至关重要，而征求反馈并进行响应则是痛点。除非你向用户提出明确的请求，一般他们都不会提供太多的反馈。要千方百计想办法获得用户反馈，确保组织内有机制分析反馈并采取响应措施。