面向开发者的产品，需要恰到好处的用户体验，就像锤子新品宣传的那样 > 内敛和克制的，使用起来舒服和体贴 最近的工作是开发运营一项面向开发者的服务，而我们的团队是做社交产品出身。在关乎到用户体验的问题上，这里面仿佛存在一个矛盾。
开发者服务不需要用户体验？
给程序员用的东西，要什么用户体验，功能可以work不就行了么？这是我们一开始的想法。当我们观察一些市面上的一些开发者服务的时候，我们发现，好和坏，真的不一样。举个例子，挑选国内两家数据统计服务提供商的界面进行对比一下：
腾讯分析 
百度统计
单从界面上看，就可以明显看出腾讯果然是一家以产品能力见长的公司。 于是，我们有了第一层理解：开发者服务也是需要好的用户体验。
开发者服务应该极致用户体验？
我们团队面向消费者的产品思维根深蒂固，产品经理往往会为一个按钮的大小和对齐纠结半天。极致体验，就是我们的口头禅。不干扰用户，让用户爽，就是我们的信条。于是我们系统最早的注册登陆，都不需要验证手机和邮箱——为了的让用户快速进入。
产品进入运营期，需要做用户回访和召回，问题来了，最早的用户都没有验证手机和邮箱啊。于是我们赶紧改版加了验证。
至此，我们突破了第二层理解：开发者服务，需要恰到好处的用户体验。
内部测试工具的用户体验
本人目前主要从事移动开发，客户端需要调用后端 RESTFUL API，后端开发的同事希望能够给他安装一个 demo app，有完整的功能，要能够跑跑关键点API的TEST，最好还能切换“开发|测试|上线”三级环境，方便调试。于是我开发了一个测试工具。
主界面 
切换环境
主要实现了如下的功能：
- 切换环境，倒数三秒后 kill app，重新打开后进入对应环境，并记住当前环境设置
- 修改对应环境的 appkey
- 常用的 TEST CASE
功能不多，但是后端同事觉得就足够用了。
官网、文档、反馈渠道
我们尝试去做推广，用户点广告过来之后，就考验我们转化率了。官网是否能够准确传达产品的理念和特点，开发文档是否足够的简明易懂，遇到问题是否能够找到最快速的途径进行反馈，这些都关乎用户体验。
这里我就说说Android平台集成文档。Android平台上有两大主流的开发工具，Eclipse 和 Android Studio，前者是 Google 最早提供的开发工具，后者是基于 IntelliJ Idea 新开发的，有较多新的特性，用起来也比较方便，缺点是还不是非常成熟，偶尔有 bug 。
我个人从 Android Studio 还是 alpha 的时候就从 Eclipse 迁移过来了，用的也比较熟。在写集成文档的时候，我想当然的侧重 Android Studio 的用户集成，没过多考虑 Eclipse 的文档，只是随便写写。
用户逐渐上来了，百分之七十都在问 Eclipse 的问题啊。于是我赶紧做了修改：
- 精简依赖包
- 降低 demo app 的 api level，降低用户使用成本
- 精简回调函数
- 反复调整集成文档，关键点加上注释
做了这些修改后，关于集成的反馈才渐渐少了，在可预见的未来，我还将在易用性上做更多的工作。
总结
面向开发者的产品，需要恰到好处的用户体验，就像锤子新品宣传的那样 > 内敛和克制的，使用起来舒服和体贴
我们还将持续改善用户体验，力求开发者用的顺畅，用的舒服。