我们最近在 CodePen 发布了一些我参与的功能。这让我开始思考这个过程。它总是独一无二的，并且有很多原因。让我们来探讨一下。
是什么激发了灵感？
功能始于想法。
是突然出现的巨大而明亮的火花吗？还是很久以前出现的微小火花，但慢慢变得明亮起来？
记录想法可以提供很大帮助。我们最近在 CodePen Radio 上讨论过这一点。如果你真的写下想法（包括你自己的和用户请求的），它可以澄清和具体化这些想法。
也有一些工具（例如 Uservoice）专门用于用户反馈来指导功能开发。
就我个人而言，我更喜欢将内部产品愿景与衡量的客户请求相结合，在公开路线图上保持轻量级。
CodePen 上设计素材的添加，我最近参与的一个功能，更像是一个缓慢增强的火花，而不是一个快速而猛烈的火花。它来自多年积累的用户请求。CodePen 应该有一个颜色选择器。我们会认为这很不错。使用自定义字体应该更容易。是的……我们也经常在复制来自 Google Fonts 的代码时跳来跳去。
然后我们收到来自 Unsplash 的一封邮件，内容大致是嘿，你知道，我们有一个 API。嗯嗯。你确实有！然后火花变成了哇，所有这些事情感觉都非常相关。它们都是帮助你进行设计的元素。设计素材，就其本身而言。
也许我们可以说这是一个启动新功能的好方法：它似乎是一个好主意。你的本能是去做它。你自己也想要它。你有足够的调查表明你的用户也想要它。
趁着这个机会……
火花已经点燃。感觉这是一个好主意，现在应该做了。现在怎么办？
当你为现有项目开发新功能时，你不可避免地会考虑它如何融入应用程序的 UI 和 UX。也许这只是我作为设计师的思维方式，但设计驱动的功能开发确实似乎是最佳途径。首先，确定它将要做什么、使用起来是什么感觉以及外观如何，然后围绕它进行构建。
在涉及非 UI 和 UX 功能以及改进方面，我总是那个泼冷水的人。我试图将让我们切换到 Postgres 变成让我们找到一种方法，如果我们真的必须切换到 Postgres，在这样做的同时为用户提供一些东西。但我扯远了。
我敢打赌，大多数新功能并不是让我们在网站上添加一个全新的区域。大多数网站工作是在对现有内容添加/删除/细化较小的部分。
在我们正在构建的新设计素材功能中，很明显我们希望将其添加到代码编辑器内部，因为您需要在该处使用它们。我们的倾向通常是让我们做一个新的模态框！在这种情况下，我并不反对模态框。单击一个按钮，短暂切换思维上下文以查找设计素材，复制您需要的内容，然后关闭它并使用它。此外，我们已经在编辑器中使用了相当多的模态框，因此这种交互方式已经建立了可用性。
但是一个新的模态框？也许吧。有些事情确实需要全新的 UI。但只要我们开始考虑新的 UI，我总是认为这是一个且慢的时刻。不是因为新的 UI 很难，而是因为它太容易了。在可能的情况下，我更愿意改进我们已经拥有的东西。这就是这个功能带给我们的。
我们已经有一个素材功能，允许人们上传文件，这些文件通常是设计素材！为什么不将这两个世界结合起来呢？这就是趁着这个机会……的时刻。我们的现有素材模态框也需要一些改进。还有一个类似的想法积压，用于改进它。
因此，这成为了一个不仅创建新功能，还清理现有功能的机会。我们也充实了现有素材上传的功能集，提供了更简单的 UX，例如点击复制按钮和操作按钮，允许您将 URL 添加为外部资源，或在我们的素材编辑器中打开它们以进行更改。
清理适用于 UI 设计工作、前端代码和后端代码。当然还有 CSS，正如本网站的读者所知！功能是进行春季大扫除的一个绝佳借口。
谁可以参与这项工作？
在新的功能开发中，这是一个需要回答的大问题。即使是小团队（比如我所在的团队）也会根据每个功能细分为更小的团队。
为了找到新功能的答案，制作一份单页文档非常有益。单页文档是在开始构建新事物时创建的一份文档，您可以在其中确定所需内容。
它迫使你不要狭隘地思考你将要做什么，而是广泛地思考。这样，你就可以避免出现以下情况：我只是在这里添加一个小的复选框……7 个月后，2427 个文件被修改……完成了！
单页文档可能如下所示
- 概述。解释你正在构建什么以及为什么。
- 替代方案。你是否考虑过多种解决方法？
- 前端概述。包括设计、可访问性和性能。
- 后端概述。
- 数据考虑因素。这是否会影响数据库？
- API 和服务考虑因素。
- 客户支持考虑因素。这可能会导致更多或更少的支持吗？
- 监控、日志记录和分析考虑因素。
- 安全考虑因素。
- 测试考虑因素。
- 社区安全考虑因素。
- 成本考虑因素。
如果你认真地完成了整个列表并写下了所有内容，那么你将处于更好的状态。你将确切地知道这个新功能需要什么，并且更接近于估算时间表。
至关重要的是，你将知道你需要谁来参与这项工作。
这段话，摘自 Fabricio Teixeira，确实很有道理
设计师必须了解数字产品的运作方式，而不仅仅是表面上的内容，以及即使是最微小的设计决策如何对许多其他地方产生连锁反应。
当你开始讨论产品中的“微小设计更改”时，你必须将其他学科纳入考虑范围。很有可能“微小设计更改”实际上并不存在。
对于我们的设计素材迷你功能，我们能够快速投入其中的主要原因之一是，假设我们适当地确定了它的功能范围（请参阅下一节），90% 以上的工作可以由一名前端开发人员/设计师完成。在所有人员中，我的时间安排最宽裕，因此我能够承担这项工作。
有些功能，也许大多数功能，需要更多跨学科的团队。在我们这个小团队中，大型功能通常需要几乎所有人的参与。
版本一与未来
你很可能需要将你的想法缩减到可管理的范围。放开手脚去想大点子非常诱人，但你想得越大，行动速度就越慢。我相信我们都遇到过即使是小功能也需要花费预期时间三倍的情况。
我努力成为那个把东西推向市场的人，至少当我在一个我知道完善和打磨不是空想的地方时是这样。我倾向于发现范围蔓延和延迟带来的麻烦比事情进展得太快带来的麻烦更多。
对于我们的设计素材功能，正如我提到的，我最初希望将其范围限定为几乎仅限于前端的项目，这样就不需要我们很多人参与。这与这样一个事实相平衡：我相信我们可以在不需要大量后端工作的情况下使其变得非常有用。我不会仅仅因为人员可用性问题而限制功能，但有时星星确实会以这种方式排列。
设计素材模态框中的颜色选择器部分就是一个很好的例子。我们立即考虑有人可能希望将他们自己喜欢的颜色保存为调色板。也许是在每个 Pen 的基础上，或者全局到他们的帐户。我也认为这是一个不错的主意，但这需要一些用户数据库工作来为我们做好准备。这似乎是一件很小的事情，但我们肯定会花时间处理类似的事情，以确保数据库更改足够抽象，我们不仅仅是在添加一个“喜欢的颜色”列，而是一个可以适度扩展的系统。
所以一个简单的颜色选择器可以是“v1”！没问题！将它推向市场。看看人们如何使用它。看看他们要求什么。然后根据需要对其进行改进和添加。
老实说，我们收到的反馈并不多。这通常是胜利的一列。人们大声表达对它的喜爱当然更好，但这很少见。当产品运作良好并满足人们的需求时，他们通常会默默地、心满意足地继续他们的工作。但如果你妨碍了他们，至少在一定规模上，他们会告诉你。
也许有一天我们会重新审视设计素材区域并推出 v2！保存的收藏夹。更多的图像搜索提供商。更一般的搜索。更好地记住你之前使用过什么并更快地向你展示这些内容。这种改进可能需要一个不同的团队。它也与 v1 一样令人满意，甚至更令人满意。
以下是 v1 最终呈现的更详细情况
另一个示例… CodePen 的新外部资源
说到改进功能！让我们将这些内容映射到我们最近在 CodePen 上处理的另一个功能上。我们刚刚改进了外部资源区域的工作方式。现在就是这样
大多数人不太可能对它之前是什么样子有深刻的记忆。这并没有太大区别。最大的 UI 差异是那个大型搜索框。之前，输入框是搜索字段，类似于自动完成。我们仍在使用自动完成，但已将其移动到搜索框中，我认为这是一种更强的提示。
移动自动完成发生的位置确实是一个微小的变化，但我们有很多证据表明人们根本不知道我们提供了它。使用视觉搜索提示完全解决了这个问题。
另一个重要的 UX 改进体现在那些记住的资源中。每当你选择一个资源时，它都会记住你做了什么，并为你提供一个再次添加它的按钮。嘿！这很像收藏设计资源，不是吗？！幸好我们没有创建那个“收藏颜色”数据库列，因为我们已经看到了更多抽象系统会很有用的地方。
在这种情况下，我们决定将这些收藏保存在localStorage中。现在我们可以以一种处理收藏的方式来试验 UI，但仍然不需要立即触碰数据库。将其移动到数据库的优势在于，任何类型的收藏都可以跨浏览器和会话跟随用户，而无需担心丢失它们。总会有 v3！
这里还有一些幕后更新，在内部，我们也同样感到兴奋。那个自动完成功能？它搜索了成千上万甚至数十万个资源。这是很多数据。在此之前，我们通过在你点击自动完成字段之前不下载这些数据来处理它。但后来我们确实下载了它。我们自己服务器上存储的一大块 JSON 数据。一大块 JSON 数据经常过时，需要我们不断更新。我们有一个更新它的系统，但它仍然需要工作。新系统直接使用CDNjs API，这意味着永远不需要进行大型下载，并且资源始终是最新的。好吧，至少与 CDNjs 一样新。
说到 v3，我们已经有很多想法了。速度是一个轻微的顾虑。我们如何加快搜索速度？我们如何按受欢迎程度范围限定这些结果？我们如何放松并更好地猜测你正在搜索的资源？可能最重要的是，我们如何将其扩展到 npm 上的资源？我们希望解决所有这些问题。但幸运的是，没有任何问题阻碍我们现在推出更好的产品。
总结
有点漫无边际，是吧？
这里肯定有一些不完整的想法，但最近功能开发一直占据着我的大脑，我想记录一些东西。我们许多开发人员在整个职业生涯中都处于这种循环中。我们中的许多人对我们构建什么以及如何构建它有很大的发言权。与所有这些相关的事情有很多需要考虑，而且可以说没有明显的最佳实践。它太大了，太模糊了。你无法用手拿着它说这就是我们进行功能开发的方式。但你可以认真思考它，有一些适合你的原则，并尽力而为。