6 章节4: 找准要素
董正选 保存 显示目录
现在我们已经清楚了问题是什么，也明确了预计投入，是时候从文字描述的想法中提炼处解决方案的要素了。我们可能会找到许多不同的方案来解决问题。那么能够快速的将这些想法都检视一遍而不拘泥于其中某个就显得非常重要了。
把握好推进速度
有两件事可以使我们在这个阶段推进地不紧不慢。
首先，我们的房间里应该只有合适的伙伴或者独自一人。我们要么独自工作，要么就同值得信赖并且能够和我们同步的伙伴一同工作。拥有相同背景知识的同伴可以让我们之间的交流保持简洁，并非且能够在我们想法漫天飞舞时坦诚交流。
其次，当我们在绘制草图时需要小心错误的细节层级。如果我们一开始就从线框图或者特定的视觉布局下手，我们会陷入无意义的细节中从而丧失了大局视野。
而这其中最大的挑战就在于，如何具体到足以推动特定方案，同时有不会陷入细节中。我们会尝试去回答这些问题：
- 新事务和当前系统的契合点在哪里？
- 你是如何做到的？
- 关键组件或者交互是什么？
- 你将被引导向何方？
为了在保持正确的细节层级的同时及时捕获到灵感。我们会着手使用一些原型技术：面包板 以及粗记号笔绘制草图。这使得我们可以快速地绘制出一个流程的多个版本，以便于我们分析每个方案的优缺点，并保证我们额讨论不会偏题。
面包板
我们从电气工程中借用了一个概念来帮助我们在合适的抽象层级上进行设计。面包板是一种电气工程原型，它具有真实设备的所有组件和线路，但没有经过工业设计。
决定制作一个指示灯以及一个旋钮与争论底盘用什么材料、旋钮在灯的左侧还是右侧、角度有多大等问题是完全不同的。
同理，我们可以对界面构思的关键组件和交互进行讨论或者绘制草图，而不去深入到具体的视觉设计。为此，我们可以使用速记的方式。我们要画出基本三要素：
- 界面：这些是你可以通过导航去到的地方，比如页面、对话框、弹窗。
- 示能：这些是用户可以操作的内容，比如按钮和字段。我们认为备注界面也是一个示能，它可以为用户的后续操作提供信息。
- 连线：这些连线会显示示能是如何将用户从一个位面带到另一个。
我们会使用文字来代替图片，重点在于我们需要识别这些组件以及它们之间的链接。它们使得我们可以提出想法，并判断我们的一系列操作是否符合我们要解决的问题初衷。
案例
假设我们的产品是一个开票工具。我们正在考虑增加一个新的“自动转帐”功能，使我们的客户的客户可以自动支付将来的付费。
如何开启自动转账？它应该关联些什么？我们应该先选择一个起点，比如说用户会进入到的出票页面，这就是我们的第一个页面。我们可以画出它的名字并加上下划线。
在出票页面，我们觉得可以添加一个「开启自动转账」按钮，这也是一个示能，它位于下划线的下方以表示它可以在这个页面找到。
这个按钮会跳转到哪里去呢？当然是设置自动转账的地方。我们不用去指定它是一个页面或是弹窗或是其他的方式。从「甲—链接—乙」的角度（拓扑）来说都是一样的。我们只需要在按钮和自动转账页面间画一条连接线。
现在我们可以来聊聊页面上应该有些什么了。我们需要在这里要求填写信用卡么？档案里是否包括已有信息呢？ACH和其他的支付方式又如何呢？
为了搞清楚在每一栏需要填写什么，就需要探讨一下我们要开发什么？
我们在仔细考虑后，决定在这里询问信用卡的详细信息并显示金融机构的标志（该特定产品领域的一个方面）。
这样做的逻辑非常直接。可是我们到底有支付最初的票据呢？所以说，现在我们在界面和功能上都存在了问题。启用自动转账实际上是在做什么呢？它是从第一次启用时的票据支付就生效，还是只对后续的支付生效呢？我们应该在哪里向用户解释这个操作逻辑呢？于是我们通过面包板上的寥寥数语和一些箭头就引出了更深层次的问题和讨论。
由于我们使用的是这种轻量型的符号，我们不会受困于线框图，因此我们可以快速地过一遍方案并且尝试各种不同方案的可能性。
我们还可以在安装界面增加一个选项。
但是我们现在的做法让确认页面承担的任务变得更加复杂了。如果您现在付款，我们需要向您出示收据。确认信息是否应当显示出您刚刚付款额度的收据呢？
那么何不尝试一种截然不同的方法呢？与其在出票时询问自动付款，我们何不将其做成付款时的一个选项呢。这样当我们对当前订单是否已经支付的问题就不存在歧义了。我们可以在当前的支付确认界面上加上一个额外的标注「启用自动转账」。
草图还提醒了我们，目前支付方式除了支持信用卡外还支持ACH。我们在讨论后确认我们也可以使用ACH。
那么启用自动转账以后用户该如何关闭它呢？到目前为止，系统中的很多用户依旧是没有账户名和密码的，他们根据令牌化的链接逐一支付票据。人们可能会很自然地认为，既然用户有了类似于自动转账的功能，他们就需要有用户名密码以及一些登录页面来做管理。
在这种情况下，团队认为如果增加用户名/密码流超出了他们的预计投入。于是他们基于对用户的了解从战略上进行了分析，如果票据供应商的客户联系他们并要求关闭自动转账服务，这是没问题的的。在这个场景下，我们可以在提供给票据供应商的用户详情页上增加一个选项「关闭自动转账」，我们这样绘制了这个流程：
这个例子说明了在面包板阶段要达到的思维水平和推进速度是怎样的。绘制出流程后，我们需要面对一些我们最初没有考虑到的问题，这会激发我们的灵感，但同时不会被视觉设计问题的分散精力，目前阶段视觉设计并不重要。
当我们的流程设计完全契合了用户的使用场景时，我们就需要继续推进，敲定更多的要素来使我们的项目更清晰。尽管目前仍然遗留下了大量的细节，但我们的设计已经变得越发具体。
用粗体记号笔绘制草图
有时候我们脑海里的想法会是一个图像。但面包版无法解决要素的二维排列，这就会使得我们丢失很多关键点。因此在这种情况下，如果我们在线框图或者不必要的高保真度上浪费时间，我们就会用粗体记号笔来绘制草图。
粗体记号笔草图受限于绘制时使用的笔尖尺寸，基本无法添加细节。我们最初使用宽笔头的 Sharpie 记号笔在纸上绘制。时至今日我们在 iPad 上也会将笔尖尺寸调大。
举个例子，我们发现自己经常在 Basecamp 的待办清单中创建假的待办任务来当作分隔符。我们创建了一个叫做「——待测试——」的待办任务，并将其他待办任务排在它下面。因此我们想在我们的待办事项工具中加上官方的分隔符功能来将工作台转变为待办清单的一级功能。
我们必须要理解添加分隔符的含义是什么。我们有了一个粗略的想法，在待办清单中添加一个分隔符，其上方是「未分组」的待办任务，下方是「已分组」待办任务。在上方的「未分组」待办任务间添加更多分隔符就能增加更多分组。
我们可以在每个分组内以及「未分组」区顶部加上一个按键来支持增加任务。
我们有些担心添加太多的按钮会破坏待办清单的格式，这些分组会使得页面上的待办清单过于支离破碎。所以我们讨论了另一种方案的可行性。将「新增」的按键放在我们每个已有的待办任务的左侧菜单中。
相比于面包版的局限性，这种简写方法受到的限制会更小。我们可以绘制一个侧边栏附加到我们布局中，即便它并不是核心元素。不过只要我们多留意，这也比过早地创建线框图以致于陷入杂乱中好。
把用粗体记号笔绘制草图称作一种技术或者一种工具听上去似乎很傻。早早地向大家介绍它是因为我们太容易跃进至错误的保真度了。给这个粗略的早期阶段起个名字，并且再使用一种特制工具来帮助我们细化拆分我们的创造过程，确保我们会急于详细描述一个具体想法而略过了分析的工作。
输出要素
在「自动转账」的范例中，我们最终提取出了一些明确的要素：
- 在「确认支付票据」页面增加一个「使用自动转账」的选择框。
- 在票据供应商端增加一个「禁用自动转账」选项。
对于「待办事项分组」的案例来说，要素是：
- 最上方的「待分组」待办任务是直属于上级分组的。
- 「分组」待办任务位于「待分组」待办任务的下方。
- 我们乐意在每个分区中增加一个俺家，但如果这会让视觉效果很糟糕的话，我们也接受通过操作菜单的方式将待办任务插入到对应的位置。
同理，当我们在绘制「在日历上标记事件」的简化方案时，我们也使用了粗体记号笔。
这能够帮助我们找出解决方案的关键要素:
- 一个以两个月为单位的日历阵列图
- 当你点击一个点时，页面就会滚动到下方以日程清单显示的事件上。
同「月历」相比，这个要素清单的范围就收缩得更小也更加具体，这也是正是我们希望在塑造过程中实现的收缩效果。
留给设计师的空间
当你将任务交付给设计师的时候，你不会希望对他说：「我知道我是这么这么画的但是请你无视它。」但是无论你怎么说，你之后接手的成员都会受到具体的模型的影响——尤其是当你的职务层级比他们更高时。他们会将原始模型中的每个细节都视作一个设计方向，即使这不是你的初衷。
恰当的「抽象层级」不仅可以保证我们推进速度正常，还可以为后期的设计留下重要的空间。
通过忽略细节、面包版、粗记号笔绘制草图等方法可以为后续阶段的设计师留下更多发挥空间。
这就是塑造这个过程的重点。我们正在让项目更加的具体和逼真，但是依旧为后续留有大量的空间去更好地做出决策和选择。这不是一种规定，它更像是一种游戏的规则限制，一旦进入到游戏中，它就能展开数不尽的可能。
尚未交付
这个塑造的过程依旧是处于你很私人的领域中，这些产出设计无论是画在墙上还是在笔记本上，对于没有和你一同参与塑造的人来说都是难以理解的。
我们已经将一个模糊的想法，比如「自动转账」或者「待办任务分组」，变成了具体的方案或者一些要素。但是我们目前的表现形式依旧是粗略的，大多都是一些大纲。
我们之前所做的就是找到解决这个问题的方案。但在我们确认信息都是安全可靠的并交给团队开发前，可能仍有一些很关键的不确定性和问题需要我们排除。
接下来要做的就是抗压测试和降低风险，我们希望借此尽可能的排除漏洞和挑战，这些因素都可能成为我们按照预期发布项目的阻碍。
在那之后，我们就将把塑造成型的概念写成一篇好的「安利」。
及时止步
要时刻记住，在这个阶段我们还可以放弃项目，我们还没有真正投注。也没有对此作出任何承诺。我们所做的只不过是通过改善可实践性来增加了原始想法的价值，当我们需要拨出资源的时候将其推后也是一个不错的选项。