优质的产品没有微小的改动

编辑注记：本文作者为 CRM 管理工具 Intercom 的 COO Des Traynor，在 Intercom 的博客 INSIDER Intercom 上写有关 UX、客户获取经验和创业的文章。原文 THERE ARE NO SMALL CHANGES。

由于今后可能会用到 SMS 功能，所以我们想将产品中评论字数的长度限制为 140 字符。这只是一个微小的改动，对吗？

不对，优质的产品没有微小的改动

当你致力于为客户提供优质的产品时，就不存在微小的改动。看看上面的例子，一个初级的程序员可以在三分钟内写出实现这个功能的代码，毕竟这只是一个“if 表达式”。

但让我们先花点时间做个咨询，在进行“微小改动”之前问些问题。

当评论超过 140 个字符后会发生什么？我们会裁剪句子，还是向用户显示错误讯息？如果显示错误讯息，哪么在哪儿显示？它会显示什么内容？谁会去写这个错误讯息？我们如何向用户解释我们限制成 140 个字符的原因？错误讯息如何显示？我们有针对它的样式吗？如果没有，谁会去设计？

但等会儿，还没完......

即使我们已有答案解决上述问题，我们仍没结束。仅在服务器端作出改动会使问题变得棘手，我们还应该在客户端解决。但如果我们想在客户端验证字符是否超出，我们又有了些新问题......

谁去写 JavaScript？JavaScript 会和服务器端的代码显示一样的错误类型吗？如果不是，那么新类型是什么？用户禁用 JavaScript 时又该怎么办？我们如何确保每次对 140 个字符要求的更新都能影响到客户端和服务器端的验证？

我们依旧没完。现在站在用户的角度思考下。他们已经由被他们不理解的奇怪原因而导致的评论受 140 个字符限制所烦恼，现在还要他们去猜测他们已经输入了多少字符？一定有更好的方式，比如字符计数器。哦，这又引发了新的问题,,,,,,

就快结束了......

谁会去写这个字符计数器？如果我们在网上雇佣一个，那么谁会去在我们希望支持的浏览器中测试？

此外，这个字符统计的结果显示于屏幕何处？这个计数器的外观怎样的？当然，它的样式应该随着用户能输入的字符接近 0 而改变，并且当然应该在用户输入多于 140 字符时看起来就像出错的样子，又或者它应该在此时停止接受输入？如果是这样的话，那么用户粘贴文字进去又会发生什么？我们应该让他们继续编辑，还是显示警告？

当我们已经实现了字符计数器，标记好错误讯息的样式，实现服务器端的验证，并且也在所有支持的浏览器中测试，然后就是写一个测试，部署它。假设你开发产品的生产时间是固定的，这一切都会很直接。

然而所有这些都愉快的忽视了一个事实，用户会对在他们之前有人可以写 80 个单词的评论而现在只许可写 140 个字符感到奇怪。显然我们需要对这个新改动提供一个完整的解决方式，还要更新我们的文档、API、iPhone 和 Android 上的应用。同样我该怎对待之前的评论？裁剪他们，还是不去管？

最可怕是我们还需考虑如何处理哪些人们最近爱用的时髦字符。我们可能需要消除这些不合规矩的字符，而这意味着新的错误讯息，新的服务器端代码......清单还要加长。

当你解决了这些问题，你所需的功能终于实现，而这仅仅只是字符计数器。现在考虑下比“if 表达式”更复杂的情况。当你想按正确的方式去做一件事情时，没有所谓的小事。这就是为什么作为一名 UX 设计师，你需要在你点头和写另一个工作要点之前，就要很好的理解实现一个功能到底需要做些什么。

你不是认真的吧......

是的，这些都是胡扯。是的，上述任何一个决策对有经验的开发者而言都可以快速响应，但并不是全部。是的，你可以使用 maxlength 属性，但它只解决了一个问题，并且这种方法只在 HTML5 的 textarea 标签中才能实现。

当没能理清事物间关系时，两分钟的工作常常会变成需要两个小时来完成。被认为已经“正确的估计”只需两分钟完成的功能最终却超过预期，花费了两个小时。

要点：项目所需时间按分钟增长，而不是按月份。抓紧分钟，不必理会月份。

同意一个功能看似容易。写代码就不同了。维护它则有可能成为噩梦。当你最求产品的质量，产品就没有微小的改动。