现在我们已经提取出了解决方案所需的要素，也尽可能地排除了潜在的风险，是时候将其交付给开发团队了。但是这个雏形仍然只停留在我们的脑海中，或者只存在于我们笔记本和白板的抽象草图中，我们需要将这个雏形具象化为一个其他成员也能够消化理解的模式。

这时候我么不禁会想「好吧，是时候写个安利出来了」。在这章中我们会详细地介绍一个「安利」的诞生过程，并且展示一些来自 Basecamp 的真实案例。

写「安利」的根本目的是为了展现一个优质的潜在赌注。它基本上就是在介绍我们所需要的所有要素，它既要归纳到目前为止已经完成的工作，同时也要将这些工作很好的展现出来以吸引项目规划者对其下注

我们认为一个好的「安利」需要五个要素：

问题——原始想法、用户场景以及其他促使我们决定开工的原因。
预计投入——我们计划投入多少时间及其带来的约束。
解决方案——我们将提炼出的核心要素以一种让人们便于理解的方式展现。
无底洞——为规避问题而有必要提出来的解决方案细节
学会舍弃——所有被隔绝于雏形之外的东西：为了符合处理能力并使问题便于处理而故意不做覆盖的功能和场景。

成分1：问题

同时提出问题和解决方案是很危险的。这似乎是个显而易见的观点。但是让人吃惊的是，包括我们的团队在哪，常常会快速地基于一个假设——为什么这样开发是最好的——就跳到一个解决方案上。

直接切入到「要开发些什么」，也就是解决方案是很危险的。抛开问题，你就没有任何基础可以去支撑这个方案到底好不好。「将标签添加到 iPad 应用中」对于 UI 设计师来说可能很有吸引力。但是如何才能避免讨论逐渐沦为关于 UI 方案的漫长争论呢？如果没有特定的问题支持，我们是无从测试哪一个方案是更加合适的。

此外，在确立了问题之后，当我们写「安利」或者决定投注的时候，也能进行更加清晰的沟通。我们的解决方案或许是完美的，但如果这个问题只发生在那些非目标用户身上呢？我们很有可能会花费六个星期在一个完美方案上，但只有少部分低留存率的用户会受益于这个方案。我们希望将关于需求的讨论切分开来，这样我们就不会浪费时间在那些无益于目标用户群体的解决方案上。

你需要多久才能阐明这个问题取决于读「安利」的人了解多少上下文。最好的问题定义往往是脱胎于一个具体的场景故事中的，这个故事会说明为何现状已不满足需求。这为你提供了测试方案合适与否的判定标准。大家能够权衡这个解决方案和特定的问题——如果持续争论下去并发现其他的解决方案——判断新的解决方案是否更加适合这个场景故事。

成分2: 预计投入

你可以将预计投入视作定义问题的另一个部分。我们不仅想要满足这个用户场景，而且是在六周内实现，而非花上三个月，甚至在某些情况下，对于一些小分支项目，我们只花上两周，而非整整六周。

在「安利」中陈述预计投入有助于减少讨论中的废话。我们总能找到更好的解决方案，但我们真正关注的问题应该是，如果只有两周时间，那么这个既定的方案合不合适呢？

任何人都可能提出高成本的繁复解决方案，但是我们需要从开发和设计的角度去思考才能打磨出一个适合短时间的精巧想法。在「安利」中陈述预计投入并且将其作为约束条件，将使得所有成员都会成为产品开发流程中的助力者。

成分3:解决方案

就像有些解决方案是没有问题作支撑的，公司也常常会在没有解决方案的问题上下注。「我们真的很需要改进通知的检索功能，我们的用户在抱怨这个部分呢」。

这其实是还没有准备好去写「安利」或者去下注的。没有解决方案的问题仍然是一个有待塑造的工作。将其交付给团队实际是将研究和摸索的工作下沉到了错误的层级。在这个层级中，技能组、时间限制以及风险预估（短尾分布与长尾分布）都是不匹配的。

如果这里没有解决方案的话，我们就应该退回到塑造这一步工作去。只有当问题、预计投入和解决方案都备齐后，你就可以仔细检查解决方案与问题是否匹配，并判断是否值得投注。

展示想法

在提炼元素阶段，在正确的抽象层级上绘制出想法是至关重要的，这样我们既不用放慢速度，也不会使得任何突发奇想的灵感丢失。

在写「安利」时我们也需要在刻画细节是留意抽象层级。这里的难点有些不同，我们此时是有余裕放慢速度来好好准备展示内容的。比起我们独自或者与伙伴一起进行塑造时相比，我们需要保持高层次但更加具体一些。那些并不太了解前后文的成员在读「安利」或者看草图时必须要能够理解这个想法。

我们需要更加具体一些，但不是指通过线框图或者高保真模型来过度设计。它们会将稍后接手工作的设计师束缚住，同时还会使得我们的讨论偏离主题，倒向颜色、比例或布局等与我们塑造工作无关的主题。

与此同时，手绘面包板也必须给人「身临其境」的感觉。因为对于那些没有看到面包板是如何一步一步展开的人来说，它很可能看起来就像一碗由单词和箭头组成的大杂烩。

因此，我们需要一些技巧来帮助人理解这个想法，同时还要确保不会过多地陷入细节之中。

嵌入式草图

假设你在塑造阶段得到的面包板看起来是这样的：

大家恐怕很难理解这些新功能在主控面板上的位置。因此，我们可以在主控面板上画出一个新的方框来使其更加清晰。

但是我们还是留出了太多的空间需要人们去自行想象。这值得我们权衡是否要用粗体记号笔进一步地落实细节。

这使得我们可以更清晰地看到要素有哪些，并评估各个功能在主控面板上是否表达的足够清晰。这么做的缺点是，会使得我们干扰一些我们本不该插手的设计。设计师应当自行探索新的设计方案而不是被竖线与方框拘束住。我们应当在这里加行一个免责申明来提醒设计师们放开手脚。

在这个案例中，更多地视觉细节被选择性地加了进来，这是因为我们需要借助它来推销概念。幸运的是，我们在概念的其他部分不需要做出太多视觉上的决策。确保每个人都能准确地理解它是设计中很重要的一个部分。

为粗体记号笔草图注释

有时候，有些想法在本质上是图像化的，或者过于复杂以致于无法在面包板概念图中很好的表示。此时，为粗体记号笔草图做注释就能在「安利」中发挥很好的作用了。你只需要更加谨慎地去为它们加上标签。

在 iPad 上重新绘制草图——依旧使用粗体笔刷——是一件很有效的事。你可以使用不同颜色将标签和草图的主体部分切割开。

或者你也可以针对特定的元素增加一些延伸内容来做探讨。

成分4:无底洞

有时解决无底洞问题仅需要几行文字。例如，在之前的出票工具项目中，塑造者想要设计一个具体的方案来用于创建 URL。但是 URL 永远不会出现在项目 v1 的自定义域中。这解决的并不是概念的核心，但这么做就有可能填上一个潜在的无底洞。

成分5:禁止

最后，如果有什么内容是我们不打算在这个原型概念中去实现的，那么最好能将它提出来。在出票工具项目中，团队预先确定了将不允许对票据做任何形式的「所见即所得式」编辑。用户只能够在一个单独的「自定义」界面中上传 logo 或者自定义标题文本。在许多人看来「所见即所得」是很好的，但是考虑到我们在周期计划中的预计投入，将其设置为「禁止」是很重要的。

范例

这里是两个真实的「安利」示范。

这个关于「待办任务分组」的「安利」首先展示了在当前的设计中人们受到的使用局限。然后就如何启用可选的待办任务分组这个问题，通过草图的方式画出了所有主要的想法。

两个截图展示了这个问题。粗体记号笔草图给出了解决方案。兔子洞问题则激发了更多的草图。

这个关于「通知方式变更」的「安利」则通过两个视频展示了问题。最后的黑框则是对用户行为数据的分析，用于支撑「安利」中的决策。

两个视频展示了问题。粗体记号笔草图和面包板描述了解决方案。黑框包含的可视化数据则用于支撑权衡抉择。

准备展示

下一步就是游说大家这个「安利」所阐述的内容值得去投注。这可以通过多个方式去实现。

在通常情况下，我们更偏好异步通信，只有在必要的时候才会升级为实时通信。这将给予所有人最大程度的时间自由来做一些真正有用的事情。这也就意味着展示一个「安利」的第一步就是将其中的所有的要点都写在某处，相关成员可以在他们方便的时候自行阅读。这让我们的赌局变得简短而高效。在理想情况下，所有人都有空预先读一读「安利」。如果在某些情况下无法实现预读，安利者也要做好准备以应对现场推广。