当我们执行塑造工作时,我们需要选择适当的抽象层次:既不要太模糊,也不要太具体。产品经理往往会在这两个极端上犯错。

线框图太具体了

当设计领导直接进入线框图或高保真模型时,他们过早定义了太多细节。这样没有给设计师留下创造的空间。一个朋友这样描述:

我会给我的设计师一个现况提,然后对她说:“我知道你在看这个,但这个不是我想要你设计的。我希望你重新思考它!”但是当你给他们一个具体的东西时,很难做到(重新设计)。

过度制定设计也会导致估算错误。尽管这可能看起来有点反直觉,但工具越具体,估算起来可能越困难。这是因为要让界面恰到好处,可能需要解决隐藏的复杂度和实现细节,而这些在原型中是看不到的。当范围不可变时,团队无法重新考虑一个成本超过其价值的决策。

几个词也太抽象了

在光谱的另一端,过于模糊的项目也不行。当一个项目用几个词定义时,没人知道它是什么意思。“构建一个日历视图”或“添加群组通知”听起来很合理,但它们到底意味着什么?团队成员没有足够的信息来做权衡。他们不知道该包括什么或省略什么。一个曾在那种情况下工作的程序员说:

如果你在没有上下文的情况下解决问题。你必须是个读心者。就像“我们会知道它是什么样子。”

关于估算,由于没有边界来定义什么超出范围,未明确规定的项目自然会失控。

案例:点网格日历

让我们看一个如何在适当细节水平上塑造项目的例子。

我们在没有日历特性的情况下发布了Basecamp的第三个版本。它有一个"日程"功能,只是按顺序列出事件,没有任何月、周或日的网格。

发布后不久,客户就要求我们在Basecamp中“添加一个日历”。我们之前已经构建过日历,我们知道它们有多复杂。构建一个合适的日历轻轻松松就要耗费六个月乃至更长的时间。

下面是让日历变得很复杂的事情:

  • 在单元格之间拖放事件来移动它们

  • 在屏幕的边缘折叠多日事件

  • 每月、每周或每日时间尺度的不同视图

  • 拖放事件边缘以更改其持续时间

  • 为不同类别的事件进行颜色编码

  • 处理桌面与移动端交互的不同期望

Basecamp的旧版本有日历,但只有大约10%的用户使用它们。这就是为什么我们没有 胃口 花六个月时间在日历上。另一方面,如果我们能在六周内做些什么来满足那些给我们留言的客户,我们愿意这样做。

只有六周的时间,我们只能构建人们所说的“日历”中的一小部分。问题变成了:哪一部分?

我们做了一些研究(将在下一章讨论),并缩小了一个我们想要解决的用例。最终,我们受到了手机上日历的启发,提出了一个有希望的概念。我们可以构建一个只读的两个月网格视图。任何有事件的日子都会有一个点表示每个事件。事件列表会出现在日历下方,点击有点的日子会将该天的事件滚动到视图中。我们称之为“点网格”。

“点网格”并不是一个功能齐全的日历。我们不会允许在日期之间拖动事件。我们不会在网格上跨越多天事件;我们只会重复这些点。不会有颜色编码或事件类别。我们对这些权衡感到满意,因为我们理解了这个用例。

这是我们用来定义解决方案的保真度级别:

An image to describe post

注意草图有多粗糙,以及有多少细节被省略了。设计师有很大的空间来解释这个应该如何看起来和感觉。

同时,注意这个想法的具体性。它非常清楚地说明了它的工作原理、需要构建的内容、包括什么和不包括什么。

在项目结束时,设计师和程序员完成的作品看起来是这样的:

An image to describe post

特性1 :它是粗糙的

在塑造阶段的工作是粗糙的。每个人都能通过观察看出它是未完成的。他们可以看到开放的空间,他们的贡献将放在那里。过早地过于精细的工作会让每个人都陷入错误的细节中。设计师和程序员需要空间来运用他们自己的判断和专业知识,当他们卷起袖子并发现所有真正出现的权衡时。

特性2:它是能够解决问题的

尽管粗糙且未完成,成形的作品已经过深思熟虑。解决方案的所有主要元素在宏观层面上都已具备,并且相互连接。虽然工作未细化到具体任务,但整体解决方案已明确阐述。尽管仍可能出现意外和冰山,但已有明确的方向指引该做什么。任何我们预先可见的开放性问题或潜在陷阱都已被消除,以降低项目风险。

特性3:它是有边界的

最后,成型的工作表明了不要 做什么。它告诉团队在哪里停止。有一个特定的时间预算——团队被允许在项目上花费的时间。在固定的时间内完成项目需要限制范围并舍弃一些特定的内容。

总的来说,粗糙性为团队留出了解决所有细节的空间,而解决方案和边界则像护栏一样。它们降低了风险,并引导团队的努力,确保他们不会构建过多、四处徘徊或陷入困境。

谁来塑造

塑造是创造性和综合性的。它需要将界面想法与技术可能性与业务优先级结合起来。要做到这一点,你需要作为一个通才具备这些技能,或者与一两个其他人合作。

塑造主要是设计工作。塑造的概念是从用户的角度来看的交互设计。它定义了功能的作用、工作原理以及它如何融入现有的流程中。

你不需要成为程序员来进行塑造,但你需要具备技术素养。你应该能够判断什么是可能的、什么是容易的、什么是困难的。关于系统如何工作的知识将帮助你看到实现想法的机会或障碍。

这也是战略性的工作。设定目标并提出解决方案要求你对问题进行批判性思考。我们要解决什么问题?为什么它重要?成功的标准是什么?哪些客户会受到影响?做这件事而不是其他事的成本是什么?

塑造是一个闭门进行的创造性过程。你可能独自在纸上素描,或与紧密合作的伙伴站在白板前。面前会有粗糙的图表,房间外的人无法解读。与合作伙伴共事时,你们行动迅速,直言不讳,从一个有前景的想法跳跃到另一个。这就是那种私密、粗糙、早期的工作。

两条轨道

你无法真正安排塑造工作,因为就其本质而言,未成形的任务充满风险和未知。因此,我们设有两条独立的轨道:一条用于塑造,一条用于构建。在任何六周的周期内,团队都在构建之前已塑造好的工作,而塑造者则在研究团队未来周期可能构建的内容。塑造轨道上的工作保持私密,直到决定投入其中之前,不会与更广泛的团队分享。这让塑造者有权将进行中的工作搁置或放弃,如果进展不顺的话。

塑造的步骤

塑造有四个主要步骤,我们将在接下来的四章中详细介绍。

  1. 设定界限。 首先,我们确定原始想法值得投入多少时间,以及如何界定问题。这为我们提供了塑造的基本框架。

  2. 勾勒出基本元素。 接着是构思解决方案的创意工作。我们以比线框图更高的抽象层次进行,以便快速推进并探索足够广泛的可能性。此步骤的产出是一个在既定范围内解决问题但未细化所有细节的想法。

  3. 解决风险和陷阱。 一旦我们认为有了解决方案,我们会仔细检查,找出可能让团队陷入困境的漏洞或未解答的问题。我们会修改解决方案,删除其中的某些部分,或在某些棘手的地方指定细节,以防止团队陷入困境或浪费时间。

  4. 撰写提案。 一旦我们认为已经足够完善,可以下注,我们就会将其打包成一个正式的文档,称为提案。提案总结了问题、约束、解决方案、陷阱和限制。提案会提交到决策桌进行审议。如果项目被选中,提案可以在项目启动时重新使用,向团队解释项目。