4 章节2：塑造的原则
雷欧雷欧 保存 显示目录
当我们在进行塑造工作时，一定要把握好塑造的抽象层级：产品经理常常会在模糊与具体两者间滑向其中一个极端。
线框图过于具体
当首席设计师直接使用了线框图或者高保真模型时，意味着他们过早地敲定了太多的细节。这会使得其他设计师失去发挥创造力的空间。我的一个朋友这样曾说道：
我会给我的设计师一个线框图，然后对她说：「我给你看的这个不是我想让你设计的。我希望你能重新思考设计稿。」但是当你给他们看了具体的东西后，这一点其实很难做到。
设计过于明确也会导致错误地预估。和我们所想的不同，工作越是具体，其实就越是难以预估。这是因为让界面得以如此进行操作，其背后隐藏着的复杂性和实现细节是不会体现在模型中的。要保持区块划分不改变，团队就无暇重新设计一个方案，最终导致投入高于产出。
文字过于抽象
在另一个极端，过于模糊的项目也同样没有意义。没人能够看懂一个只用寥寥数语描述的项目。「构建一个日历视图」或者「增加一个团队通知」听上去似乎没有毛病，但是谁知道它们到底是要什么呢？开发组并没有足够的信息去权衡取舍。他们不知道需要保留的核心内容和需要舍弃的附加内容都是什么。一名在这种场景下工作的程序员感叹道：
要处理这么一个没有前因后果的问题，我得是个读心者，这就像是「冥冥之中有个声音告诉你要做什么」。
在预估这个问题上，过于模糊的项目会自然而然地走向失控，因为这里没有一个明确的界线来圈定范围。
案例分析：点阵图日历
让我们来看一个如何在正确的抽象层级上塑造项目的范例。
我们在推出第三版 Basecamp 时并没有附带「日历」功能。我们有一个「日程表」功能，但这个功能只会把日程一个接一个的罗列出来，并且没有形成按照每月、每周、每日细化的网格。
这个版本推出后不久，用户们就开始要求我们在 Basecamp 中「加上一个日历」。我们曾经开发过日历，所以我们很清楚开发一个日历有多复杂，构建出一个合适的日历可能需要我们投入六个月以上的时间。
导致日历开发变得复杂的因素有很多：
- 在单元格间通过拖动来移动事件
- 多日事件会超出屏幕边缘
- 每月、每周、每日三种时间粒度需要多种视图
- 拖动事件首尾来调整持续时间
- 用颜色来标记不同类型的事件
- 移动端和桌面端需要不同的操作逻辑
而在有日历功能的旧版本中，只有10%的用户会用到日历。因此我们不想六个月的时间来做日历。另一方面，我们更希望用六周的时间做出一些功能来满足那些和我们进行邮件交流的用户。
那么问题来了，六周的时间，我们只能做出用户所期望的「日历」的十分之一，我们应该做哪十分之一呢？
我们进行了一些调查（我们在下一章中再来讨论），并缩小了我们所要解决的使用场景范围。最后，受手机日历启发，我们想出了一个好点子。我们可以开发一个只容纳两个月时长且只读的网格视图。每个事件都会在对应的那一天加上一个点，事件则会以列表的形式罗列在日历下方。单击带点的那一天则会将当天的事件滚动到屏幕中。我们将其称之为点阵图。
点阵图并不是一个功能齐全的日历，我们不允许在日期间拖动事件，我们也没有联通多日的长任务，只会在多个日期上加点，事件没有分类也没有上色。但是基于对使用场景的理解，我们对于这种取舍权衡十分满意。
这是我们定义解决方案的保真度：
点阵图的概念草图
请留意这个草图的粗略程度以及它所忽视的细节，这留给了设计师很大的空间来自由诠释它应有的外观与质感。
同时，也要留意到这个草图的精细程度，它已经把工作原理诠释的非常清楚：我们要开发什么？哪些功能我们要做，哪些不做？
在项目结束时，设计师和程序员们共同创造出的成果是这样的：
点阵图上线后的截图
这个小案例凸显了塑造工作的一些特质。
特质1：粗略
在塑造阶段的产品应该是粗略的，每个人都能轻易地看出它的不完善之处。他们也能发现自己为完善产品做出贡献的空间。过早地拿出过于精细的产品会使得成员们都陷入到错误的细节之中去。程序员和设计师都需要拥有发挥他们专业知识和判断能力的空间，这样他们才会投入工作并自主权衡利弊。
特质2：明确
尽管产品应该是不完善的、粗糙的，但是塑造过的产品应该是经过了思考的。从宏观来看产品的解决方案，其中应该涵纳了所有的核心要素，且这些要素彼此间也应当构成关联。虽然产品不应该细化到一个个具体的任务，但是在整体上应该是明确的。尽管仍然可能发生意外或者撞上「冰山」，但是要做什么的方向是明确的。同时，为了降低风险，我们也应该把可以预见的开放性问题和无底洞问题都予以解决。
特质3：界限
最后，塑造后的产品应该明确不做的内容。这会让团队清楚应该在什么地方停下来。而划定这个边界的应该是一个明确的计划投入——团队在这个项目上可以花费的时间。要在在固定的时间内完成项目的开发就需要划定界限并且舍弃一些具体的内容。
总而言之，粗略的设计为团队留出了处理细节的空间。而明确的方案和界限则扮演着边界护栏的角色。他们共同引导着团队并为其减少风险，确保团队不会开发出过于冗杂的功能、陷入迷茫或困境。
由谁来塑造
塑造是一件具有创造性和综合性的工作，它需要将界面设计、技术支持以及业务优先级相结合。要做到这一点，你需要是一名团队多面手，或者你需要和一到两名成员进行合作。
塑造工作主要是一件设计工作，塑造的理念就是做出用户视角的交互设计。它定义了产品的功能、工作原理以及这些功能在现有流程中的定位。
要进行塑造工作并不一定要是程序员，但你需要有相应的技术修养。你需要了解设计的可能性、难易度，了解系统运作原理能帮助你发现潜在的灵感以及遇见可能遇到的难点。
塑造也同样是一件战略性的工作。要明确计划投入并提出解决方案，需要你对问题报以批判性的眼光。我们要解决的问题是什么？这个问题为什么很重要？怎样才算成功解决了？目标客户群体是什么？投入成本是什么？
塑造也是一件封闭的、创造性的工作，你可能会独自在白纸上写写画画或者与一名亲密合作的成员在白板上推演。在你面前的那些粗糙草图表是其他人都难以看懂的。而当你与人合作时，你会步履匆匆、有话直说，思维快速地在有潜力的想法间跳跃。塑造就是这样一件私人的、粗糙的、早期的工作。
双线并进
塑造工作是没有准确的时刻表的，因为从本质上来说，未经过塑造的计划是充满未知性并且具有高风险的。基于这个原因，我们应该构建两条轨道，一条是塑造工作，另一条则是开发工作。在每一个六周的循环周期内，开发者们会对已经塑造过的设计进行开发，而塑造者则应该着手于落实团队在接下来的开发周期内需要进行的工作。在塑造者确定要「下注」前，塑造轨道上的内容都应该对外部团队保持私密状态。这就使得塑造者有了选择的机会是将其加入到工期中还是舍弃它。
塑造的步骤
塑造主要有四个步骤，我们将在接下来四章中介绍。
- 设定界限。 首先我们要估量一下原始想法值得我们投入多少时间以及如何去定义这个问题。这就为我们后续的工作预先设置好了界限。
- 为核心元素绘制草图。 接下来是一项创造性的工作——为解决方案画出一个草图。这个草图应该比线框图要更加的抽象，以便于我们快速地推进并留出更宽广的探索空间。在这个步骤我们需要输出一个粗略的想法，这个想法需要在计划投入的范围内解决了问题。
- 降低风险和无底洞问题。当我们找到了解决方案就该去仔细地研究它了，找出其中的漏洞以及不确定性。我们会对方案进行修改，删减其中的内容，或者在一些棘手的地方明确细节，以防团队陷入困境或者浪费时间。
- 写「安利」。当塑造的方案具有足够的投注潜力后，我们就会写一个「安利」来包装它。「安利」总结了问题、约束、解决方案、无底洞问题和局限性，并且会被投入到赌局上候场。一旦该项目被选中「下注」，这份「安利」就可以在项目启动时用于向开发团队解释项目。