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

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

编辑注记:本文作者为 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 标签中才能实现。

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

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

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

产品迭代产品开发
下载极客公园客户端
iOS下载
反馈