常言道「一图胜千言」解释了用户界面原型的意义所在:使用视觉来解释设计和开发准则,告诉人们产品的喜好以及外观。在快速迭代的设计流程中,快速原型法可以帮助快速构建系统的原型,无论是设计网页还是 APP,无论面相的对象时用户、投资人、开发者还是设计师。如此可以快速的在迭代的早期收到反馈,以此来改进最终的设计,并减少在开发阶段的变更。

原型的范围包括从很随意的手稿到高保真可交互的原型。使用快速原型法的关键在于反馈,使用简单的原型来快速修正问题。快速原型可以让团队尝试更多的可能性,在讨论的时候快速原型使用图片来替代文字,以此来统一每个人的理解,并且可以降低风险,避免需求遗漏,其目标是更快更好的设计。

快速原型过程

快速原型需要不断重复这三个步骤:

  1. 原型
    考虑用户体验准则以及最佳方案,并将对解决方案的描述画在图纸上。
  2. 测试
    将原型呈现给用户,看原型是否能够满足用户的需求和期望。
  3. 改进
    根据用户的反馈,找到需要改进或者需要解释清楚的地方。

快速原型

原型从最简单的开始,从一些关键模块开始,然后经过几个迭代的不断深入和扩展,直到完成并交付去开发。整个迭代的过程非常快,从实时的变化到几天的迭代,需求变化的时间取决于原型范围。

确定原型范围

原型简单来说就是图片,包含了应用中所有的功能版本或界面。快速原型并不打算做成全功能的,其目的是帮助用户视觉化和检验最终产品的用户体验。介于次,在画原型前先列出一些关键问题。

什么需要画原型?

好的候选产品通常包括复杂的交互,新的功能设计和流程(技术或设计)上的改变。比如说,如果你想要显著提升搜索体验,那么制作搜索结果原型就很有用。比如使用分面搜索(Faceted Search),或者让用户不离开搜索结果就去预览文档。

原型要做到什么程度?

第一原则是关注与用户会花 80% 的时间去用的那 20% 的功能。一般来说,核心功能肯定是最常用的。要记住,快速原型的关键是展示某个功能如何工作,或者之后的设计看起来大概会是个什么样子。快速原型并不是要展示整个产品。

找出用户场景?

在确定了要画的原型之后,把这些功能集合在一起,放进一个或更多的场景中:原型模拟的是关键路径中的用户体验。比如一个卖鞋的网站中,一个场景可以是用户 Joe 购买一双和他之前买过的一双 Nike 鞋;而另一个场景可能是 Sam 通过筛选 10 号的鞋,来找到他喜欢的牛津鞋盒休闲鞋。

迭代计划

整个产品原型通常不是一次性就做完的,而是一步步去完善的。一个好的方法是从大的范围开始入手,然后选择一个范围深入其中。对一个网站,这就意味着要先从网站的首页和着陆页开始设计(有时候这被称为水平原型 Horizontal Prototype)然后检查并改进这个框架。接下来就可以深入到网站的一个或多个领域(垂直原型 Vertical Prototype);对一个下载视频的网站来说,这可以是用户去找到并下载视频的步骤,或者说用户在线管理自己的美体裤的步骤。

选择适当的保真度

适当的保真度

精确度也就是说原型要有多接近最终的产品形态。这个精确度有几个区间,原型稿可以是任何一种精确度,主要取决于当前的设计流程,以及原型稿的目的来选择合适的精确度。

  • 视觉精度(草图 ↔️ 视觉稿)
    视觉和感受是原型稿的一个重要维度,如果没有控制好的话,可能会转移原型的测试目的。过多的视觉化会让用户关注在视觉设计上,这在早期的原型设计中并不合适。从视觉的角度来看,圆形并不需要像素级完美,但也需要一些规范。比如左侧导航栏的区域在 1024px 的屏幕上为 1/4,并不需要一个像素不差的画成 204px,只要能够表现出相应的意思即可。然后在整个产品的设计周期中,使用一些设计元素、颜色、品牌和图形来逐步增强视觉保真度。
  • 功能精度(静态 ↔️ 动态)
    原型稿应该是说明解决方案(静态)还是可交互的并且可相应用户的输入(动态)?这个维度并不会让用户太过于分心,但是可交互的原型可以增加功能的精确度,而且原型还可以被用来做可用性测试、配型和交流。
  • 内容精度(随意填充 ↔️ 真实内容)
    另一个容易让用户分心的维度就是内容的呈现方式。使用线条或者随意的文本来填充,在早前的原型设计中可以避免用户分心。但是随着原型的改进,在评估原型的时候中使用真实内容可以更真实的反映出用户的感受以及设计上的表现。

设计原型

低保真原型

低保真度是最容易上手的,有纸和笔就足够了。在纸上画出低保真的原型谁都可以做,并不需要特殊的工具和经验。这个方法通常在设计周期的最早期使用。手绘可以快速的创建一些粗糙的原型和概念,然后从用户那里获取反馈。手绘原型通常是在头脑风暴和概念设计中制作的,在一个小房间里使用笔记本就可以,或者在小组中使用白版和马克笔。

手绘稿

在低保真的原型阶段,手绘稿通常是静态的,而且不包含视觉样式和真实内容。这个阶段主要主要是让用户专注于他们如何使用应用,而不是应用看起来如何,而且设计师可以基于用户反馈来更开发的思考设计。

中保真原型

当我们使用电脑工具比如 Vision 和 Omnigraffle 来画图的时候,就会输出中保真的原型。我们会创建线框图、任务流程以及场景等等,这个时候原型看起来会更加的规范。这个时候一般都不会加入设计元素、品牌和色彩等,专注于应用的行为。一些交互方式可以使用简单的页面链接来完成,如果有更完整的交互体验会更好。该阶段原型主要是为了评估用户的需求是否实现,以及用户体验是否最优。

中保真原型

有两个原因会让一个中保真的原型看起来并不中保真:

  • 首先,使用 Balsamiq 或者 Visio 的手绘模版来绘制低保真原型,这样会迫使用户觉得这是一个草稿或者未完成的作品,而不是一个优雅的完成稿。
  • 其次,使用高保真的视觉稿(比如在 Photoshop 中制作完整的排版),这会让用户专注于视觉感受,包括一些色彩、字体、布局、LOGO 和图片。

快速绘制中保真原型的方式是使用模版、组件和一些可复用的插件和元素。最终的速度就取决于你对使用的工具的熟练程度了。

高保真原型

高保真原型经常会让人误以为就是最终的产品,但却是非常耗时的。在几年前,创建高保真的原型需要编码,设计师经常需要和开发者合作才能完成。而现在,设计师仅仅需要拖拽一些 UI 插件就可以创建高保真的原型了,包括完整的功能,甚至是业务逻辑和数据交互。Axure 和 iRise 是两个经常被用来创建高保真原型的工具。

高保真原型通常是当需要高保真的视觉和功能时才被创建的。比如,引入一种去全新的技术(比如从主机应用转移到网页应用)。多数高保真原型并不能转换为可直接使用的代码,但却对开发者来说非常具有参考价值。同时可以被用来做可用测试和培训用户。

高保真原型

高保真原型是相对快速的,可以使用一些拖拽工具来快速实现,具体就要考虑交互和保真度的需要了。除此之外,一些工具还可以加快收集用户反馈,帮助编写需求文档,加快设计流程。虽说这些工具有一定的入手难度,但相对去学习一门编程语言就简单多了。

选择合适的保真度

选择什么样的保真度并没有正确的方法。大多数新产品的设计都是从手绘稿开始,然后转移到中保真或高保真的原型中,取决于系统的复杂度和需求的维度。

在与一间制药厂合作的时候,我们从白板开始到可交互的原型,包括全部的功能和真实内容,但是依然是低保真的。相较于界面效果,他们更关心是否遵循企业的设计规范。

而对于另外一个零售行业的客户,我们的可交互原型就是高保真的。但是内容却不是很真实的,因为客户会重新安排内容。对他们来说,界面的视觉和感受就显得尤为重要,因为这是他们第一次执行 SharePoint,而他们也希望入口看起来一点也不 SharePoint。

选择合适的工具

制作原型有很多的工具可供选择,主要取决于你使用的方法。Dan Harrelson 在他的博客 Adaptive Path 里面推荐了很多流行的工具。

每个工具都有自己的特点,基于你自己的需要和项目的需求,检测哪个工具更为合适。你可以思考这些问题来帮助你选择合适的工具:

  • 工具的入手难度如何?
  • 是否可以兼容 Web 原型,或者打包成桌面和移动应用?
  • 是否有大量的组件、模版和插件的支持?
  • 原型能否方便的分享给其他人来做测试?其他人能否通过工具来提供反馈?
  • 能否实时的真对反馈做一些修改?
  • 是否支持团队协作?
  • 使用的成本有多大?

应该做和不该做的

当你开始设计原型的时候,你应该谨记下面这些原则:

应该做:

  • 和用户、商业以及 IT 利益相关者一起合作设计原型。除了能够给予反馈外,他们会觉得最终的产品是在自己的控制下完成的。
  • 避免在进程中设定一些期望而造成的「原型蠕变」,比如修改原型的目的、保真度、范围和交付日期。要提醒每个人,包括你自己,快速原型虽然有一个结束,但并不是设计原型本身的结束。
  • 在制作高保真原型的时候,要加入一些真实的等待时间(比如刷新或者下一步的动画),这样用户在使用真实产品的时候能够预期到这种延迟。
  • 重复使用!重复使用!重复使用!对于使用计算机制作的原型,重复使用模版、组件和插件意味着节省大量时间。
  • 最重要的事,每次测试原型的时候一定要事先声明这仅仅是个原型,并不是真正的产品。这会让用户了解产品还在设计中,并能够鼓励用户反馈,特别是在高保真的原型中,也会避免用户误解。

不要做:

  • 不要在原型中展示那些几乎不能做到的功能。如果你对某个功能的可行性有疑问,要在原型前就和开发确认。
  • 不要把测试中给出的所有反馈都当作是需求。快速原型可以帮助我们捕捉一些缺失的需求,但新得到的这些需求要谨慎的验证。有些需求可行,有些则几乎没有可行性。
  • 不要再没有明确指导原则的情况下去做测试。要非常清晰了解测试的目的(操作的逻辑是否合理?导航是否清晰可用?),如果你没有这样的目的,那你就准备好应对「我不喜欢头部的蓝色」或者「我们能换个字体么?」还有「你能把这玩意弄的更骚点吗?」
  • 不要追求完美。多数情况下,原型不会达到百分百完美,只要能够让测试者看懂并理解就好。
  • 不要把什么都塞进原型里。多数情况下,你都不要这么做。

推荐参考

原文链接:Design Better And Faster With Rapid Prototyping
作者:Lyndon Cerejo
翻译:Max Cheung