既然我们已经有了胃口的约束和要解决的问题，现在是时候获得从文字的想法转变为一个软件解决方案的要素了。可能有几十种不同的方法来解决一个问题。因此，重要的事我们能够快速行动，涵盖许多不同的想法，而不被拖累。

以正确的速度前进

在这个阶段，有两件事情可以让我们以正确的速度前进。

首先，我们需要在房间内找到正确的人——或者没人适合。要么我们独自工作，要么与一个能够跟上我们步伐的值得信赖的伙伴合作。我们可以用简略的方式交流，拥有相同的背景知识，并且在我们跳跃式思考时候，能够坦诚相待的人。

其实，我们需要避免在图纸和草图中构建了错误的抽象层次。如果我们从线框图或具体的视觉布局开始，我们会被不必要的细节所困扰，无法像我们需要的那样广泛探索。

这里的挑战是既要足够具体，能够在特定的解决方案上取得进展，但是又不要被细枝末节拖累。我们试图回答的问题是：

• 在当前的系统中，我们把新东西放哪？

• 你如何做到上面的事情？

• 关键组件和交互是什么？

• 这个方案最终会把你带到哪去？

为了能够在正确的细节水平上捕捉我们的想法，我们亲自制作了几种原型技术：面包板设计和粗体标记草图。这些方法让我们能够快速绘制整个流程图的不同版本，以便我们可以讨论没中方法的优缺点，并在讨论过程中保持一致性。

面包板方法

我们从电气工程中借用了一个概念来帮助我们在正确的抽象层次上设计。面包板是一种电气工程的原型，它具有真实设备的所有组件和布线，但是没有工业设计。

决定是否包含指示灯，这个问题和讨论底盘材料、旋钮应该放在灯的左边还是右边、角落应该有多尖锐这些问题截然不同。

类似地，我们可以在不需要指定特定的视觉设计的情况下，草拟出交互方案的关键组件和连接。为此，我们使用了简单的速记方法。我们只会画三种基本元素 ：

1. 地点：这些是你可以导航到的东西，比如屏幕，对话框和弹出的菜单；

2. 可见功能：这些是用户可以操作的东西，比如按钮和填入文本框。我们认为界面副本也是一种可见功能。阅读它是一种行为，为用户提供后续操作的信息。

3. 连接线：这些显示了可见功能如何将用户带到另一个地方。

我们用文字而不是图片来标记一切。重要的是我们能够识别组件和连接。这些方法能够让我们展开一个想法并且判断用户的动作序列能否满足我们想要解决的问题。

示例

假设我们的产品是个发票工具。我们正在考虑添加一个新的“自动支付”功能，以便我们客户的客户能够自动支付未来的发票。

如何开启自动支付？涉及到哪些步骤？我们可以选择一个起点，假设用户已经在一个发票页面上。这是我们第一个场景。我们通过写下这个场景的名字，并在下面划线来表示它。

在发票上，我们考虑添加一个“开启自动支付”的新按钮。这是一个可见功能。可见功能放在线的下面，表示可以在这个场景找到这个功能。

那么这个按钮会让用户到哪里去呢？某个设置自动支付的地方。我们不需要具体说明它是一个单独的屏幕还是弹出模态框。从连接关系的角度来看（拓扑接口），这两者是相同的。让我们从按钮到设置自动支付屏幕画一条连接线。

现在我们就可以讨论新的屏幕上可以有什么功能？我们在这里要求输入信用卡吗？是否已经有卡存档？是用ACH ¹。还是其他支付方法呢？

只需要弄清楚在横线下面些什么内容就可以引发关于构建什么的争辩和讨论。

当我们仔细思考时，我们决定应该在这里要求提供信用卡详细信息，并显示金融机构的徽标（这是在特定产品领域的一个方面）。

简单明了。但是等等——我们是否真的支付了原始支票？嗯。现在我们既有功能问题，也有界面问题。启动自动支付实际上做了什么？它仅仅用于未来的订单，还是第一次使用自动支付也会支付当前的发票。我们在哪里解释这种行为呢？仅仅因为面包板上的几个词和箭头，我们开始有了更深层次的问题和讨论。

由于我们使用了如此轻量级的符号，并且没有被线框图所拖累，我们可以快速切换并探索不同的可能性。

我们可以在设置界面上添加一个选项...

但是现在我们就会让确认屏幕的职责复杂化。如果你现在支付余额，我们需要显示收据。确认界面是否应该在某些条件下显示刚刚支付的金额的收据。

可不可以尝试一种完全不同的方法。我们不从发票上开始，而是在支付的时候将自动支付作为一个选项。这样就不会对当前正在支付的金额产生歧义。我们可以在现有的支付确认页面上添加一个额外的“自动支付已启用”提示。

把这些画成草图提醒我们，当前的支付表单除了信用卡之外还支持ACH。我们讨论并且确认了我们也可以使用ACH。

启用自动支付之后呢？客户如何关闭它？到目前妹纸，系统中的许多客户没有用户民或密码。他们通过带有token的链接逐个支付发票。一个理所当然的想法是，既然用户有了自动支付这样的功能，他们需要一个用户名和密码以及一个登录页面来管理这些内容。

在这种情境下，如果团队决定添加用户名/密码流程，那就超出了他们的胃口范围了。从战略上反思他们对客户的了解，他们认为如果发票使用工具者的顾客联系他来主动关闭自动支付也是可行的。在这种情况下，我们可以在已经提供给开票人的客户详细信息中添加一个禁用自动支付的选项。我们绘制了如下流程：

这个例子展示了在面包板阶段应该追求的思维水平和动作速度。将流程完整的写出来让我们面对最初未能想到的问题，并激发设计灵感，而不会因无关紧要的视觉选择而分心。

一旦我们完成用例的演练，而且流程没啥问题，我们就可以继续推进，并且更清晰地定义项目。我们现在变得更加具体，虽然仍然省略了大量的细节。

粗体标记草图

有时候我们脑海的想法是视觉化的。使用面包板会失去焦点，因为元素的平面排布才是基础问题。在这种情况下，我们也不想在线框图或者不必要的细节上浪费时间。因此我们使用粗体标记草图。

粗体标记草图是一种用宽笔画绘制的草图，添加细节很困难。我们最初是在纸上用较大尖头的Sharpie马克笔进行绘制。如今，我们也在iPad上使用大直径的笔尖进行这种绘制。

有一个例子。我们经常在Basecamp的待办事项中添加假的待办来作为分隔符。我们会创建一个类似“---需要测试---”这样的项目，并在其下方放置其他项目。我们想到在待办事项工具中提供官方的分隔符功能，将这个功能作为待办事项的一等功能。

我们必须弄清楚添加分隔符的影响。我们提出了一个粗略的想法，添加分隔符之后，将列表分为上方的“松散”待办事项和下方的“分组”待办事项。后续添加新的分隔符会把上面的“松散”待办事项中添加更多组。

我们可以通过每个组里面的可见性功能来添加新的项目，包括顶部的“松散”组。

这种符号标记方法比面包板的限制要少很多，但是也有缺点。我们可能会画一个侧边栏的草图，并依赖于这样的布局元素，哪怕它不是核心的元素。但是只要我们保持一定的警惕，仍然要比过早陷入线框图的细节要好很多。

将粗体标记草图称为一种技术或工具可能看起来有点傻。之所以特别指出它们，是因为我们太容易跳到错误的细节层次。为这个粗略的早期阶段命名并使用特定工具有助于我们划分自己的创作过程，并确保在我们没有充分调查领域之前不会急于详细阐述某个具体想法。

要素就是输出

在自动支付的例子中，我们最终得到了一些明确的要素：

• 在现有的“支付发票”界面上新增了一个“使用此功能进行自动支付？”的复选框

• 在开票人侧提供一个“禁用自动支付”选项

对于待办事项组项目，元素包括：

• 第一个组上方的松散待办事项直接属于父级

• 分组待办事项显示在松散待办事项的下方

• 我们想尝试在每个部分中增加“添加”的可见功能，但如果视觉效果不佳，我们也可以依赖操作菜单来将待办事项添加到指定位置

类似的，当我们为在日历网格上渲染事件简化解决方案时，我们使用了粗体标记方法。

这让我们制定出解决方案的要素：

• 一个双月日历网格

• 用点表示事件，没有跨天

• 下方的事件列表用日程形式展示，点击网格中的点会让事件视图滚动到对应位置

这个要素列表和“月度日历”相比非常狭窄和具体。这正是我们希望通过塑造过程实现的缩小范围。

设计师的空间

稍后，当需要涉及到设计室的时候，你也不想不得不告诉设计师，“我知道我是这样画的，但请忽略它”。无论你说什么，任何具体的模型都会影响其他人之后的工作——尤其是如果你的职位比他们高。他们会将初始模型中的每一个细节视为指示，尽管你并没有这个意图。

在正确的“抽象层次”上工作不仅确保我们以适当的速度前进，还为后续阶段的创造力留下了重要的空间。

通过省略细节，面包板和粗体标记方法为设计师在项目的后续阶段提供了空间。

这是塑造过程中的一个主题。我们正在使项目更加具体和明确，但仍然为后续的决策和选择留下了大量空间。这不是一个规范。它更像是游戏的边界和规则。一旦开始玩，它可能会有无数种不同的走向。

尚未交付

这个塑造的步骤仍然在很大程度上属于你的私人领域。此时在墙上或笔记本中的作品对于任何没有和你在一起的人来说，或多或少都是难以理解的，这是正常的。

我们已经从一个模糊的想法，比如“自动支付”或“待办事项组”，发展到了一个具体的方法和一些具体的元素。但我们目前的形式仍然非常粗糙，大部分还只是轮廓。

我们所做的是确定了一个解决问题的方法。但在我们认为是安全的，可以交给团队成功构建之前，可能还有一些重要的未知因素或需要解决的问题。

下一步是进行一些压力测试和风险降低。我们希望检查可能阻碍项目在既定时间内交付的漏洞和挑战。

之后我们将看到如何将成形的概念整理成一份用于推介的文稿。

没有传送带

同时请记住，在这个阶段，我们可以选择放弃这个项目。我们还没有对它下注。我们也没有做出任何承诺或保证。我们所做的是通过使其更具可操作性，为原始想法增加了价值。我们已经更接近一个可以在资源分配时争取的好选项。