Prototipagem
UX
Checklist de Produto
Validação
Gestão de Produto

高保真原型:批准和构建之前的清单

批准一个漂亮的原型很容易;该清单旨在确保它涵盖了实际将成为产品的内容。

高保真原型的批准会议具有误导性。画布看起来很漂亮,每个人都点头,有人说“看起来很棒”,项目就向前推进了。几周后,开发因房间里没有人问过的问题而陷入停滞:当列表为空时会发生什么?错误状态又如何呢?那么离线呢?

完成工作的原型和隐藏问题的原型之间的区别并不在于美观。这是审查的严格性。根据外观进行批准是产品工作人员所犯的最常见和最昂贵的错误。

本文适合那些即将做出决定的人:我们要建造这个吗?他没有解释什么是高保真原型,而是提供了一份审查清单,这些问题将准备成为产品的原型与将产生返工的原型区分开来。

为什么根据外表批准是有风险的

高保真度会欺骗大脑。当某件事感觉真实时,我们就认为它是完整的。这是一个众所周知的偏见:视觉现实主义创造出一种准备就绪的感觉,而这种感觉通常与所想的深度不相符。

结果是重要的决策变得不可见。原型显示了幸福的道路,用户做的一切都是正确的,连接有效,数据存在。但真正的产品却以不幸的方式存在:错误的字段、不稳定的连接、空列表、拒绝权限。

仅涵盖快乐路径的高保真原型尚未准备好接受批准。它已经准备好接受质疑了。结构化提问是清单所保证的。

论文:清单可以防止乐观情绪

我主张每一个高保真原型的批准都经过深思熟虑的审查,并提出固定的问题,无论它看起来多么令人信服。不是因为不信任,而是因为乐观是刚刚创造出美好事物的人的自然状态。

清单不是官僚主义。这是将注意力从“看起来不错吗?”转移的方式。到“它是否完整且可构建?”。当它仍然便宜时,它会在提交之前强制进行困难的对话。

采用这种规则的团队会发现返工率确实下降了。 sprint 3 中出现的问题会出现在原型评审中,需要进行对话而不是重做。

状态和异常的清单

审查的第一个方面是最容易被忽视的:那些不是幸福之路的国家。

对于每个重要的屏幕,询问:它如何显示为空、没有数据?怎么显示正在加载?出现错误时如何显示?当数据太多、包含数百个项目的列表、名称太长、文本压倒布局时该怎么办?

进一步讨论连接异常:用户离线时会看到什么?如果操作中途失败怎么办?当他试图做的事情没有获得许可时怎么办?

如果原型没有回答这些问题,那不是错误,而是不完整。批准一个不完整的原型就好像它已经准备好了一样,将问题转移给开发人员,开发人员将在最后期限的压力下发明答案。

内容和清晰度清单

第二条战线是内容。高保真原型通常使用精心挑选的文本以使其美观。真正的产品没有那么奢侈。

检查文本是否真实可信,未针对布局进行优化。用最长的名字、最高的值、最长的标题进行测试。确认按钮标签说明了它们的作用,错误消息具有指导性而不是吓人性,并且技术术语没有泄漏到最终用户界面中。

在数字化公共服务中,这种关怀更加严重。公民需要在不了解该机构内部词汇的情况下理解所询问的内容。福利表格上的模糊标签可能会导致大量填写错误和面对面服务,而数字服务本应避免这种情况。

内容是体验的一部分,而不是点缀。未经文本审查而批准的原型正在推迟一个有保证的问题。

技术可行性清单

第三条战线要求工程参与评审,而不仅仅是设计和业务。

问:这个流程可以在预期的时间范围内构建吗?是否有一些交互在原型中看起来很简单,但实施起来却很昂贵?屏幕上显示的数据是否确实存在于系统中,或者是为了让原型看起来漂亮而发明的?

最后一个问题推翻了许多原型。设计屏幕时通常会包含系统无法提供的信息,或者依赖于不存在的集成的信息。在评论中发现这一点需要进行对话。在实施中找出答案需要重新设计。

让工程获得批准并不是对设计的不信任。人们认识到可行性是原型质量的一部分。一个美丽的、无法建造的原型是未来挫折的记录。

期望和范围清单

第四条战线是关于房间里的人,而不是屏幕。

在结束批准之前,请明确:该原型涵盖哪些内容,不涵盖哪些内容?它代表最终版本还是只是一部分?该原型与交付的产品实际需要多长时间?

这种一致性避免了典型的磨损,即利益相关者看到现实的原型并开始将其视为几乎完成的产品。当交付的内容与原型的辉煌不符时,人们会认为是失败,而实际上这只是模拟和构建之间的自然距离。

记录原型的范围,即使是一句话,也可以保护团队并保护与项目发起人的关系。

将清单变成一种习惯

检查表只有在一直使用时才有效,而不仅仅是在项目很大时才有效。当原型“看起来很明显”时,人们会倾向于跳过审查。正是在这些情况下,被遗忘的状态才被忽视。

整合这一点的最佳方法是让它变得轻松:一个简短的列表,一起审查,在同一个对话中包含设计、产品和工程。它不必是很长的形式。在“通过”之前需要有一个刻意的停顿。

领导力决定了这一点是否能够坚持下去。当领导在审核过程中提出难题时,团队就会明白批准是一种责任,而不是一种形式。当领导层根据外表进行批准时,团队就会学会专注于展示而忽略实质内容。

最后,清单是对未来诚实的行为。他用“它看起来很漂亮,得到认可”的安慰来换取确保美丽的东西也是完整、清晰和可建造的工作。这项工作并不光鲜亮丽,但却是交付团队与重做团队的区别所在。

如果您正在设置原型审批流程并想要构建这样的审查,博客上还有关于原型设计和产品质量的其他文本。如果您想讨论如何根据您的情况调整清单,只需致电交谈即可。

另请阅读

  • [高保真原型:它是什么以及何时值得付出努力0
  • 【高保真原型:快速指南,不浪费时间11
  • [产品发现 - 带清单的框架2
  • [应用原型实践:如何在使用代码之前测试想法3
  • 【应用原型:如何将原型转化为产品例程4
  • [应用原型设计:实例优化5