在Slake进行原型制作

多年来，在Slake-通常是在高增长时期-团队默认在瀑布中工作，在那里，一个想法被提出和研究，然后按照这个顺序进行设计或规范，然后建立。这不是最有效的工作方式，而且随着公司的发展--每一步都有更多的人参与进来--它只会变得更慢。

倒退的成本高得令人难以置信；如果您意识到在构建阶段犯了错误，回到绘图板可以被视为偏离或没有进行充分的计划。后见之明是20/20，正如他们所说，那么为什么要等到项目结束才能从这种清晰度中受益呢？要摆脱这种模式以便迭代地工作，需要高度的信任和自治，这需要团队花费时间来构建，因此明确地谈论过程会有所帮助。我们成功地将重点放在原型过程上，将其作为打破过时的线性瀑布思维的一种方式。我们在这里要分享的不是说明性的方法论，而是一个可以适应团队需求的简单框架。

我将从IDEO的Tim Brown倡导的设计思维过程中借用一些术语和想法，并在interaction-design.org上简明扼要地写下来，所以如果这篇文章能引起你的共鸣，那么设计思维文学可以提供更多的东西！

原型是一个学习和评估的过程。如果您在一个项目中有一个您想要验证的假设，一个您想要获得反馈的特定方向，或者一个您想要评估的技术计划，原型可以为您提供做出坚定决策所需的信息。

在将团队的全部资源投入到这些机会之前，原型也可以用来评估广泛的机会。构建一个您已经考虑了一年的功能或系统的粗略版本会让您有机会决定不再使用它。这是一项使产品和工程团队能够协助关键业务决策的技能。

最重要的是，原型为我们提供了安全和高效地失败的护栏。失败是学习过程中重要的一部分，和成功一样有价值。

您的假设是原型应该证明或反驳的陈述。预先定义成功是什么样子很重要-特别是在评估主观设计方向时-但同样重要的是确定失败是什么样子。记住，在这里失败不是可以避免的，它只是一种可能的结果，需要做好计划。失败几乎总是会导致问题的改革和新的原型；这就是设计过程的构思阶段和原型阶段之间的关系。

让我们看看我们在Slake的一些示例假设，以及可能伴随它们的成功/失败标准。

💡所见即所得消息可以与数据库中的现有消息一起无缝显示。✅旧邮件继续正确显示在新的所见即所得格式邮件旁边。✅可以修改搜索基础结构以返回两种格式的结果。❌需要将所有旧消息迁移为新格式以支持所见即所得。结果：成功。这是为所见即所得大型工程项目铺平道路的早期原型之一。

💡css-in-JS将使实现暗模式变得更容易，风险更低。✅我们使用css-in-js解决方案组装了一个基本的暗模式原型。❌css-in-JS迁移路径导致我们将样式分叉到两个位置，如果没有额外的工具，这两个位置将无法保持协调。❌css-in-JS没有为我们打开新的技术可能性。结果：失败。使用CSS-in-JS的迁移路径在那个时间点上似乎不值得投资，我们选择使用CSS变量，您可以在之前的博客文章中阅读到更多关于CSS变量的信息。

通过CDN提供静态💡，而不是从服务器呈现模板，我们可以在1秒内让SLACK呈现出来。✅我们的概念验证时间接近或低于1秒的加载时间。❌我们遇到了一个不可逾越的技术障碍。❌，我们不能令人信服地接近1秒。结果：成功。这是导致我们重新构建Slake客户端的原始原型。你可以在这篇博客文章中阅读更多关于该项目的信息。

在你开始之前把这些写下来是很重要的。当原型组装在一起时，球门柱很容易移动，特别是当它令人兴奋的时候。

原型是验证一个想法的机会，没有生产质量工程带来的所有包袱。如果你打算在最后扔掉代码，那么像硬编码数据、跳过测试、忽略Linter等快捷方式都是合理的选择。

如果需要编写生产代码，在单独的repo中工作或将原型隔离到自己的页面可以帮助缓解安全问题并提高代码的可读性。始终花时间计划您的技术方法；安全至关重要！

外卖不是代码或输出本身，而是从中学到的东西。花点时间对工作进行评估和记录，并决定如何处理这些新信息。什么进行得好，什么进行得不好？有什么惊喜吗？你达到你的成功标准了吗？你的假设有没有错？

记录学到的经验教训不仅仅是重述工作的一种有用方式-当另一个团队正在考虑类似的想法时，它可以成为未来的重要历史文物。能够说“我们试过了，这是我们的发现”，这给了其他人有价值的信号，让他们一起工作。

如果你的原型失败了，下一步可能是制定一个新的假设，并尝试一种不同的方法。如果原型是成功的，并且展示了您正在寻找的可行性，那么您可能会在作为工程项目基础的详细技术规范中了解到您所学到的东西。