关于移除功能

宣布新增一项功能很容易，但解释为何要移除某项功能却很难。因此，大多数产品只会做前者，而绝不做后者；几年下来，它们便变成了无人维护的纪念碑，铭刻着人们曾经怀有的种种美好初衷。

我们努力去做更难的事情。

对于一家小型工作室来说，这并非口味问题。我们维护着众多平台上的大量应用——iPhone、iPad、Android、Windows 以及浏览器扩展——而整个团队的人数甚至不足以填满一次视频通话。 我们保留的每一项功能，都需要在每次发布时进行测试，在每个应用商店的列表中进行描述，翻译成每种语言，并回答相关问题。这种成本并不会因为某项功能曾经是个好主意而消失。.

我们的决策方式

当某项功能的维护成本持续高于其使用价值时，该功能就会被提上审查议程。我们会从三个方面进行评估：当月有多少人使用该功能、该功能引发支持工单的频率，以及它对我们开展其他工作造成了多大程度的阻碍。

第三点最容易被低估。 某项功能可能只有相当数量的用户在使用，几乎不会产生任何支持邮件，却依然会成为导致重新设计耗时加倍的原因。一种无人问津的导出格式，可能会悄无声息地决定整个数据模型的架构。当我们发现此类情况时，必须思考：这项功能是否值得牺牲它所阻碍的一切。.

我们绝不会因为某些东西不够光鲜亮丽就将其移除。一个人们每天都在依赖的普通开关，其价值远胜于一个仅因好奇心而被打开一次的炫酷屏幕。.

如何将其删除

提前发布公告——通常提前两个完整的发布周期。为用户提供过渡方案：导出功能、可无缝迁移的设置，以及在该平台上实现相同功能的操作指南。回复每一封邮件。然后发布这款更小、更简洁的应用。.

退出流程比公告本身更重要。大多数人不会阅读更新日志，因此他们第一次注意到功能被移除，往往是在去寻找该功能的时候。 我们希望用户在那个时刻看到的是应用内清晰的说明，而不是一个消失的按钮。如果该功能存储了用户的数据，这些数据必须以用户能在其他地方实际打开的格式随用户一同移出。.

我们的失误

我们犯的错误是过于悄无声息地移除了某项功能。人们很容易认为，使用率低的功能不会被用户察觉，于是便在更新中悄无声息地将其移除。但那些确实使用过该功能的用户立刻就注意到了，他们感到不满也是理所当然的：从他们的角度来看，这款应用在一夜之间变得更差了，而且没有任何预警。 即便是小众用户群体，也理应获得完整的流程。.

我们还学会了不要解释得过于详细。一篇长达数段、满是理由的删除说明，读起来反而像是在推卸责任。现在，我们只需用一两句话说明发生了什么、何时发生、为什么发生，以及该如何替代处理。.

为什么值得

每次精简功能，都会让接下来的决策变得更轻松。应用体积越小，测试速度越快，移植到新平台越容易，在应用商店的描述中如实说明也越简单。而且它也更易于使用，这才是关键所在。.

令人感到抱歉的是，这让那些喜欢该功能的用户失望了。但值得庆幸的是，此后这款应用对所有人来说都变得更好了，包括其中大多数用户。