如何选择设计保真度？来看 IBM 设计师的经验！

次呈上 Beforweb 合者 SL 的译文，《The Design Fidelity Conundrum》，原文来自 IBM 的设计师，探讨何选择设计产出的度。

一、关于设计保真度的难题

在寻求用户反馈时，怎样设计保真度最合适？

△ 个 Dashboard 部件低保真、保真、高保真界设计稿。

没有任何一个产品的设计和完善是一步到位的。样的就是不生。达成一项绝佳的设计，通常是一个想法经不断地尝试、测试、改进并随时间迭代的结果。就是为什么在 IBM 设计中心我们将「Loop」为我们的核心原则之一：

△ IBM 设计思「Loop」——一视形象充分现优的设计品是非的。

我们试将这种思维运用到我们所的所设之中。因此，无论项目研讨会活动、团队会议还一新的设作，我们都会：

• 观察（所涉及的人群：他们的背、目标、习惯等，并检验我们的想法）
• 反思（建立理解并形意图）
• 创造（探索想法和型的可能性）

然后循环往复。

的计被鼓励「在开放的环中工作」——也就是说，要尽早、尽可能频繁地寻求反馈，并且把任何产出都视作型。本质上，希望甚至期待人快速失败，并从收的反馈中学西，然后迭代的想法，直越来越多的计决策得验证。

因此，我们非清楚，当评设计优劣和获取户反馈时，快速且尽可早地获得反馈远于缓慢或拖延。毕竟，我们寻求反馈的原因，是可利获得的信息，进一步改进我们的设计。（如果你一直等到一个东西被基本设计和建好之后才寻求反馈，那么在很大几率上，针对这些反馈进行的修改或是为时已晚，或是必须付昂的代。）

△ 一些非前期的低保真线框图，探索一种可的任务流程。这种前期的低保真设计输有助于获得快速而真实的反馈。

在寻求用户反馈时使用低保真设计稿另个好处是：受访者可以看到你仍然处于早期想法阶段，便倾于更自由地提供他们真实想法和感受。相比下，如你受访者展示高保真设计稿，他们很可能认为已经有很多细节已经在前设计被充分考虑，此，他们很可能不愿意分享任何批评意见以免冒犯你。类似地，他们也可能会认为大设计已经确凿疑，进而会狭隘地针些特定进反馈，比如文、颜色、图标等等。

因此，使用低设计稿以成为一种获取早期、快速而用户反馈的方法。

到目止看起还不错。

△ IBM 的视觉设师 @NatalieCaudell 的早手绘设探索

然而，你也可能听有人告诉你说：如果想测某人在一个定景中的反应，「测」或「模型」越近它所模拟的真实情况，就越能确在测景中的行为将真正代表在真实景中的反应。

，设计师该怎么做？

尽管低保真设计稿与最终品相甚远，我们是否应该尽早用户展示低保真设计构想？是应该等到我们能展示更多高保真设计或原型？

我的观点是：

无论是使用低的构想探索，还是高保真原型，或是介于两者任何形，都应该去积极寻求用户反馈。

简而言，这不是选情况。几乎所有案例，在项目生命期多个阶段积极寻求设计反馈是有意义。随着你从第版设计到第版、第三版、第九版、到第十五版，越来越多部分将被测试、精炼和完善。

二、一个范例

IBM Cloud Event Management 是 IBM Cloud 上项相较新服务，它帮助 DevOps 团队监控事件，识冲突，并为操作员「操作手册」收知识和经测试后步骤指导，以便能够更快地避免或解决将来冲突。

以下图展示 Cloud Event Management 团在探索操守则创建页面时所绘的不同度的设计稿。在每个阶段，用户和益相关者参与评审，为设计团提供宝贵的反馈意见，用指导他们的下一轮设计优化。

△ 来自 IBM Cloud Event Management 设计团的设计稿，图展示它们是何运用不同级别的度来推进设计的。

• 第张图片：设计团队早期手绘草图，探讨了操作守则编辑些关键概念。
• 二图：一个中的框稿，主要集中在编辑器身。里团开始探索使用不同的颜来表示参数、命令和跳转链接。
• 第三张图片：终的高保真设，它不仅包括核编辑器（每一骤视觉区分），还包括标记、参数、命令与特操作守则相关的独立区域。

三、选择与你所寻求的反馈类型最匹配的设计保真度

个项目都是不，是作为个大致指南，下列个阶段都可以提供个很好会来接收有用用户反馈：

• 初始户和场研究。
• 验证项目核心想法、概念、隐喻等（例如，甚至在动笔写前，过口头上与他讨论、剖析和改善它们，你可以开始「测试」你想法了）。
• 早期的低度设计（例显示主要用户界面的纸面草图）。
• 中保真度设（例如展示致页面布局、意义的文本实际界面控件的线框图，用测试设的单用户任务流程）。
• 高保真度计（包括色彩、标识、确的布局等等）。
• 户可与之交互的原（请注意，原本身可是低、中、保真的设计稿）。
• 品某些部分代码原型（例如显示用户界关键功能或微交互等等）。
• 早期演示版（不需要等到所有预期功能完成）。
• 测试版产品。
• 正式发布版产品。

△ 何在产品生命周期的不同阶段使用不同度的设计。(图最初由 Tracy Lepore 表篇文章中，用释「Design Continuum」 的草图。)

关键于仔细考虑需验证的设作具体哪些方面，然后确保分享的设或原型具与之匹配的保真度。例如，如果验证站点导航结构，使用显示不同导航结构的非常低保真的界面模型可能就足够了，但如果您验证一特作流的用户体验，一中到高保真且可点击的原型可能合的。

总结

当选择一合的保真度测试的设时，一刀切的「确」答案，它将始终取决于具体场景。仔细考虑测试的内，然后选择合的保真度。

并且铭记以下点：

• 行一些用户研究总比不研究好。
• 在你之前型基础上，根据收的反馈来评审和改进。记住：计体现在在细节之中！
• 然而，最好要全依赖于用户测试低保真的计，因为它 不可避免地包含着各种「偏差」，低保真计实际上只是基于当所知的最终产品的大概。
• 但是同样的，要等到你有了一个整编写好的原之后才寻求反馈，因为此时基于收到的反馈做更改将之前付更多的代。
• 记住，高保真度并不是意味着大量付出。你可以使用 Marvel 这样工具快速创可击交互原型，而需编写任何代码。
• 说到代码，想要获得特定界面组件的一初始用户反馈，有时一个快速的 CodePen 演示能就是所需的部内容。

有关使用不类型原型（静态是交互等）和不保真度更多信息，请参阅 Nielsen Norman Group 这篇文章。

最，果你认为所有用户测试似乎费时且昂贵，请牢：

不的产品什么，设的每部分终究会被测试到（仔细看）。真的问题：希望这些测试发何时，时间整合反馈意见之还之后呢？

文链：《The design fidelity conundrum》  Arin Bhowmick

注译者的微信公众号：「Beforweb」