浏览器中的原型设计

原型设计动画和交互对于多种原因至关重要：它们可以让您的界面感觉虚假地快，它们可以帮助用户专注于特定任务，并且它们可以更好地了解应用程序的当前状态。数据正在加载吗？现在是否无法点击某些东西？他们需要等待多长时间才能执行操作？

在 Gusto，我一直致力于大量微小的交互细节和原型，原因正是如此——遗憾的是，目前我无法向大家详细展示太多。但是，我认为我怎么做的过程远比我实际正在做的内容更有意思，所以这就是我要在这里分享的内容。

我遇到的原型设计动画问题归结为工具，因为它们最终让我感觉很受限制。每当我过去尝试使用它们时，我感觉总有一只手被绑在背后。我很有可能没有正确使用它们，但我感觉它们都没有真正模拟浏览器的行为，而且虽然我一直对像 Framer、Marvel、Zeplin 和 Principle 这样的工具获得的关注感到着迷，但我认为它们不适合我。至少现在还不适合。

在我看来，原型设计许多交互的最佳方式仍然是使用普通的 HTML、CSS 和（惊讶！）在我需要时加入一些 jQuery。

我今天正在进行原型设计

对于我的最近项目，我决定在 CodePen 上投入一些时间，帮助我们的设计团队快速原型设计。以下是我构建的内容

查看 Pen Gusto 原型：页眉，作者是 Robin Rendle (@robinrendle) 在 CodePen 上。

真的，就是这样。它只是一个看起来像我们应用程序的简单原型。

这是一个包含应用程序导航的所有 HTML 的 Pen——它还包含所有 CSS。这样，Gusto 的设计师就可以分叉该 Pen 并开始编写 HTML 和 CSS 来试验特定部分的 UI，而无需承受编写生产代码的额外压力。重要的是要注意，此原型不是用于确定 UX 的，因为像 Figma 和 Sketch 这样的工具在这方面做得更好。当确定难以处理的 UI 交互（如表格、电子表格和下拉菜单）时，此类原型最为有用——这些组件很快就会变得很复杂。

为了制作此原型，我只需将我们网络应用程序中的所有 HTML 和 CSS 复制并粘贴到一个新的 Pen 中。（将来，我们可能应该有一个系统，始终使用我们应用程序中的最新代码来进行原型设计，但就目前而言，我认为这是一个很好的起点。）此 Pen 包含我们需要的制作看起来像 Gusto 应用程序的所有菜单和导航项目。我们有一个单独的 Pen 用于页脚，它关闭了我们在页眉中打开的所有 div。最后，我们还有一个 Pen 像这样导入另外两个 Pen

<!-- HEADER -->
[[[http://codepen.io/robinrendle/pen/481a88853820067752e28cdb479c91f3]]]

<!-- HTML GOES HERE -->
<h1>App Prototype</h1>
<p>You can fork this pen and write all the HTML and CSS you need to prototype interactions and explore ideas right here in your browser.</p>

<!-- FOOTER -->
[[[http://codepen.io/robinrendle/pen/0dcaa93954f06f4d03b7e23e8ea54cac]]]

查看 Pen Gusto 原型：完整，作者是 Robin Rendle (@robinrendle) 在 CodePen 上。

带有所有 [[[ ]]] 的奇怪语法是什么？那是 CodePen 的 HTML 包含语法。如果我们在这对括号之间放置一个 Pen 的 URL，CodePen 将从该 Pen 中获取代码并直接将其放置到这个新的 Pen 中。就是这样！很不错吧？

为了总结，我想对我在这个新设置中学习到的几点进行一些说明。

经验 1：原型应该超级容易分享

理想情况下，原型很容易与其他设计师和工程师共享，设置起来非常快，并且不需要事先培训或专业知识——Codepen 非常适合此目的。我喜欢这个设置的几个原因。首先，我们不必像在 Framer 中那样教设计师 CoffeeScript，也不必运行 React 或 Vue 研讨会来帮助他们使用复杂的原型设计应用程序。

是的，人们确实需要学习 HTML 和 CSS 的工作原理才能制作这样的原型，但我认为学习这两种语言的入门知识对于在网络上工作的设计师来说至关重要。

经验 2：糟糕的代码是可以的

这是我最近在进行原型设计时学到的另一件事：**糟糕的代码是可以的**。实际上，我们应该在浏览器中进行原型设计时编写可怕的、不可原谅的代码。我们应该编写那种会让 Harry Roberts 彻夜难眠的 CSS 和 HTML，因为干净、可维护的代码会妨碍设计过程，而此时应该关注的是尽可能快地迭代。

说实话，在制作这些原型时，我不关心前端最佳实践——我不考虑 BEM、语义 HTML 甚至性能。哦，我当然也不关心渲染 React 小工具的最熟练方式。

只要我们丢弃所有这些原型代码，稍后从头开始，并且只要有一步将设计分解成组件，并确保这些乐高积木在我们生产环境中是可维护的、有良好文档记录的和高性能的，那么我认为编写糟糕的代码不仅应该被允许，而且应该积极鼓励。

这引出了我的最后一点。

经验 3：设计师和开发人员应该始终翻译他们的代码

我认为，设计师和/或前端开发人员第一次编写代码时，绝不应在生产环境中进行。在安全的环境中拥有随意和自由地疯狂使用代码的余地会让您专注于设计并使其与浏览器的约束条件兼容。之后，您可以考虑将代码从一堆热腾腾的垃圾中整理成优美、干净、可用于生产的诗歌。将静态模型转换为交互式原型是第一步，但强制执行代码标准的下一步至关重要。

您的应用程序使用 BEM 吗？您应该如何将每个组件抽象到单独的文件中？您如何称呼您引入设计系统的这些新组件？

我相信，一旦您拥有了交互式原型，所有这些问题都更容易回答。我强烈建议设计师和前端工程师尝试制作这样的工具。起初可能感觉有点奇怪，但我保证它会从长远来看产生更好的作品。