iOS Wow体验 - 交互模型与创新的产品概念

分享到

发布于2012-11-21,来源: beforweb.com

到目前为止，我们已经了解了足够多的基础理论，这些内容可以帮助你更好的理解那些决定着产品用户体验的设计决策。现在，我们所面临的问题是，在实际项目当中，怎样做出能够与竞争对手的产品形成鲜明差异化的设计决策？怎样才能实现具有突破性的产品概念？本章中，我们将对这些话题进行探讨。

我们将要介绍的并非是某种能够立竿见影的快速指南，你无法在看过这部分内容之后就立刻掌握了其中的“秘诀”。要打造出令人惊叹的应用，我们仍然要进行大量扎实的工作和不懈的思考，以及在这个过程中对于创造力的探索。你必须下决心在这些方面做到必要的付出，才有可能使自己的产品真正脱颖而出，取得成功。

“令人惊叹”究竟指什么？

本书一直会提到的“令人惊叹”究竟是指什么呢？很显然，这个说法并不是一种可执行的设计概念，它是用户对于那些独特而具有吸引力的产品所表达出的具有赞许色彩的反馈。

具体到iOS应用的设计当中，“令人惊叹”的设计要素主要是指那些给用户带来的体验感受可以达到其心中某个“情感阀值”的表现层元素。这个阀值的高低取决于用户自身，因此，如果对产品的目标用户人格缺乏清晰的认知，便难以对这个阀值进行准确地预估与判断。以下三个方面的因素将决定着产品带来的体验感受能否跨越用户心中的“情感阀值”：

符合直觉：设计方案必须能够引导用户做出最符合直觉的反应行为。
差异化创新特征：设计方案中要有明显的创新特征，至少要让用户感受到某些不同寻常的产品体验。
积极响应：设计方案本身要能以积极的姿态去缓解那些由于差异化所导致的与用户预期或旧有习惯不符的陌生感。

而“令人惊叹”的体验效应以及上述三点推动因素又会受到设计方案自身所具有的一些属性的影响：

界面外观：也就是设计方案所呈现出来的界面布局结构、渲染方式以及所有相关的静态视觉组成元素。
交互方式：包括人机物理交互、手势以及其他常规的用户界面输入方式。
视觉交互效果：包括那些能够为设计方案赋予生机的动态的界面元素及视觉效果。这些交互效果通常与某些特定的响应行为相关，对设计方案的整体质量也会起到重要的影响作用，甚至包括那些与交互行为没有直接关联的临时状态。

可以说，如果我们能够在这其中的某一方面做到出类拔萃，那么产品体验就完全有可能达到令人惊叹的程度。其实现实当中有不少这方面的例子。你会发现，某些应用在交互方式和视觉交互效果方面缺乏足够的创新性与吸引力，但它们的界面外观却相当出彩，以至于变相地降低了前两方面因素在用户感知当中所造成的负面影响。相反，某些应用也许会采用一种几乎没有经过任何修饰加工的最小化设计方案，但在交互方式和视觉交互效果方面却打造的非常到位，这也同样会给用户带来良好的体验感知。

当然，仅仅依靠其中某个方面的表现来提升产品整体感知效应的做法是相当有风险的。特别是在iOS当中，这三方面属性所具有的影响力并不是均等的。漂亮的界面外观对于多数iOS应用来说几乎是一个既定命题，用户已经很难在这方面产生真正具有突破性的体验感知了。

所以，能够对产品体验的提升产生最大推进作用的仍是交互方式及相关的交互响应行为。正像我们在第三章里了解到的，如今的用户对于那些能够带来创新体验的应用有着强烈的渴望；要在这方面满足用户对于差异化的渴求，我们必须在设计阶段对产品的交互方式进行更加深入的探索与分析。

构建交互模型的流程概览

通过构建交互模型，我们可以对产品的基本交互方式及视觉交互效果进行规划。构建交互模型的过程通常包括四个步骤，其中前三步是必要的前期工作，而最后一步则是建模工作本身。听上去有些费解，不过没关系，接下来我将对这个流程进行简要的介绍；在对它们有了大致的了解之后，我们还将对其中每一个步骤进行深入而全面的分析。

1.明确需求

首先，我们要对产品的基本需求有初步的了解。具体的需求内容可以在用户体验策略或是正式的需求分析报告当中体现出来。这些信息是所有后续设计工作的根基，所以我们必须确保需求是足够明确并且稳定的，同时，它还要得到团队的一致认可。如果你们更加习惯于敏捷开发，那么需求发生变动的可能性是相对较大的，不过你至少需要对那些定义了产品基本功能的核心需求进行确认，才可以继续接下来的流程。一旦需求确定，我们就可以进入交互建模的下一个环节，需求用例与使用场景的构建。

2.定义需求用例与测试脚本

需求用例，特别是那些更具脚本驱动性的需求用例，是整个交互建模过程的重要组成部分。一个好的用例能够帮助团队了解到用户在使用产品时所经历的大致流程，并对各种需求在这个过程中的实现方式有所认知。有的用例会直接将那些涉及到关键交互环节的测试脚本叙述出来，并通过这种方式来为我们提供明确的需求指导。不过，无论是否以测试脚本的形式出现，需求用例本身的性质及其在产品概念前期工作当中的作用并不会发生变化。如果你对自己产品的概念已经有了比较明确的认知，并且清楚它与用户之间的互动模式，那么你可以在需求用例当中对这些进行详细地描述，从而为交互建模流程中的其他环节提供必要的信息。即便你在当前阶段对产品概念的细节还不能做到心知肚明，那么也不成问题，只要将用户在使用过程中有可能进行的常见行为描述出来即可。

3.规划产品工作流

关于以怎样的方式规划产品工作流的问题，从不同的角度出发会得到各种不同的答案；其中，每种方式都有各自的目标与价值。站在设计的立场上，我们最关心的是产品的工作流是否符合用户的决策逻辑，它能否体现出交互过程中的关键环节，与之相关的功能结构在用户友好性等方面的表现又如何。这是一种以用户为中心的规划方式，它可以帮助我们通过确立产品的特性与功能这两者之间的关联来定义整个应用的架构。一个经过良好规划的产品工作流可以为你的应用提供精准的路线图，但它不会对任何具体的功能或交互机制做出假设。

4.构建交互模型

这显然是交互建模流程当中最核心和本质的环节。当你明确了应用的基本工作流及各功能之间的关联后，就可以进一步去思考应该通过怎样的交互方式向用户呈现产品了。

用户必须通过某些关键交互行为，来完成工作流中所定义的典型需求任务，而交互建模正是以这些关键交互行为作为基础，对应用整体的交互模式进行定义的。这其中涉及在不同的用户界面视觉模态下对屏幕的实际可用面积进行的管理 (例如应用的布局与功能随着屏幕方向的调转而进行相应的调整)、导航结构的呈现方式、基本的操作手势等等。换句话说，交互建模的过程定义了应用的操作方式，但它不会决定应用具体会做哪些事情。

一套产品工作流往往能衍生出若干数量的交互模型，它们能够表现出的交互体验模式大有不同。关于这一点，我们会在本章后面的内容当中看到一些具体的例子。

对建模流程的深入分析

对建模流程当中的每个环节进行了大致的了解之后，我们将要对整个流程进行更加细致和深入的分析，包括对工作流的思考、交互模型的构建方法、相关问题的解决方案，以及怎样通过具有标志性的交互方式使整个产品的用户体验在同类应用当中脱颖而出。

对工作流的思考

对于工作流的规划与定义，是产品交互设计工作的精髓之一。我们正是在这个过程中制定了用户与产品的互动规则的。很多时候，你只需要在抽象的层面对其进行定义，而不必在意功能细节或是某些特定的交互方式；而在另外一些情况下，你必须对所有的交互方式、行为事件、状态变化等方面的逻辑进行详细地定义，才能为产品的人机交互方式规划出一个最清晰的画面。

交互模型的构建方法

正如我们在前文中提到的，交互建模用来对应用当中的交互模式进行定义，它同时还诠释了这些交互模式是以怎样的方式被整合成为具有高度一致性的、容易被用户理解的交互模型的。我们曾经在第二章里对iOS交互环境的概念模型和空间模型进行了解析。其中，交互空间及其三个组成层面的概念共同构成了iOS中的基础交互模型 (见图 6-1)。这个例子充分地体现出了交互建模的设计思想所具有的强大力量。

图6-1 iOS空间模型及它的三个层面

在构建交互模型的工作中，要尽量保持一种抽象化的思维方式。我们需要在不触及具体功能和内容的前提下，对产品有可能涉及到的交互行为进行思考，了解它们是怎样被用于控制界面交互对象的。在这方面，iOS为我们提供了大量的候选方案。诸如缩放、拖移、滑动、轻扫、滚动等基本手势都可以被赋予很多有意思的功能；无论是各自为战，还是协同配合，这些操作行为通常可以帮助我们创建出具有差异化的交互方式。

你可以对各种模式进行自由的尝试，并思考它们能够以怎样的方式帮助你解决在设计方案当中遇到的问题。除此之外，能否使设计方案具有足够的弹性及扩展性，并且能够被用户很好地理解，这同样是需要我们思考和解决的问题。

我们来做一组小练习。首先，想象出一个简单的用户界面，譬如一个列表视图。列表是一种最常见的用户界面对象，它具有很广泛的用途。传统意义上的列表通常由多个文本对象在纵向上排列而成。

图6-2 一个典型的列表

从抽象的层面来说，列表到底是什么呢？列表的基本概念，就是一个由若干可选择对象所组成的队列。进一步思考，你还会发现，其实列表项并非一定要以纵向的方式进行排列，而且每一行也未必只能包含一个列表项。所以我们可以问问自己，对于在实际设计方案当中需要解决的具体问题来说，是否有更好的列表形式可以胜任？关于这个问题的答案通常不是显而易见的，我们需要思考并尝试一些不同的方案，看看它们能否带来有一些意思的变化。如果典型的单列纵向列表无法满足我们的需求，那么横向的方案又如何呢？(见图 6-3)

图6-3 横向列表

看上去很有趣，不过也许你已经注意到了，在这种模式里，屏幕可视区域当中的列表项数量是非常有限的，特别是在竖屏状态下。如果不考虑任何上下文环境，那么这也算不上是很大的问题；但在实际使用当中，如果没办法一次看到很多列表项，那么要对整个列表进行快速浏览的话，用户必须频繁的执行滚屏操作。很显然，这种方式在效率方面存在很大问题。在横屏状态下，情况会相对好些，但仍然不是很理想。

让我们继续扩展思路，看看是否还有其他更加合理的差异化解决方案。如果说单列形式的列表无法令人满意，那么如果我们将其中的每一行扩展为一个队列，使整个列表变成网格形式，情况又会如何呢？(见图 6-4)

图6-4 网格状的列表模式

事情开始变得有趣了。在这种模式下，我们可以同时看到更多的列表项，相比于传统的单列纵向列表，这确实是一个不错的改进。但它所带来的弊端也是很明显的，那就是每个列表项的实际尺寸都变小了，这给其中的文本对象造成了很大的局限。不过我们还是可以通过控制文本对象的字号来从一定程度上解决这个问题。

在这组小练习当中，我们仅仅对一个简单的列表进行了差异化的思考与扩展性的尝试，就几乎已经彻底改变了这个对象的基本概念及呈现方式。而实际上，对于这个列表来说，我们能做的还远不止这些。接下来，让我们换一个角度，对涉及到列表对象的交互行为进行探索。在iOS当中，我们可以通过上下滚屏来浏览一个典型的单列纵向列表，那么这种方式同样适用于网格状的列表吗？(见图 6-5)

图6-5 纵向滚屏的浏览方式应用在两种列表方案中

完全没问题。不过必须记得，滚屏浏览的方式虽然适合于我们当前的这个特定的案例，但它未必在所有的情况下都适用。要在某种新的界面对象模型当中使用现有的交互方式，你必须做好充分的评估工作。

回到这个例子当中。接下来让我们对这个网格形式的列表进行一些抽象化的分析。标准的iOS单列纵向列表对象通常是支持滚动操作的，而且滚动的方向仅限于y轴上，因为列表项都是纵向排列在同一列当中的。那么对于拥有两个维度的网格状列表来说，滚动的方式能否得到相应的扩展呢？

图6-6 多维滚动与行内滚动

如图所示，我们可以通过多种方式将滚动行为运用到网格状的列表当中(见图 6-6)。通过这一系列的实例，我们可以看出，基于已有的对象模型及交互方式来构建新的概念其实并不是非常困难的事情。列表的例子只是一个起点，你还可以对很多模型和元素进行差异化的改造。这种设计思路可以帮助我们在产品当中打造各种丰富的交互方式。

相关问题的解决方案

我们已经大致了解了应该怎样从现有的基本概念出发，来定义全新的交互对象。不过在实际项目当中，我们有可能会在这方面遇到一些潜在的问题，这些问题甚至会导致设计开发工作进入死胡同。在你的设计方案当中，一些高度定制化的交互模型也许很难被准确地实现出来，而另一方面，你也有可能发现它们无法很好地被用在产品的其他地方。面对这些情况，你必须掌握一些最基本的解决方法，才能让自己摆脱困境。

我们曾经在前一章当中了解了一些能够帮助设计师实现设计方案的相关开发技术。其中，核心动画 (Core Animation)为开发者们提供了一系列强大的工具，用于将高度定制化的动画效果整合到交互元素当中。动画的概念，不仅仅是随便为一些元素添加有趣的视觉效果这么简单；对于交互设计来说，它更是一种用来与用户进行互动沟通的强大工具。

在最基础的层面，动画是一种能够使交互对象的某种属性随着时间而发生变化的机制。“时间”是这个概念当中的核心，它可以帮助我们解决交互设计当中的一些关键性的问题。

当你发现交互环境当中的空间过于有限的时候，以时间概念为主导的解决方案往往可以发挥巨大作用。要在狭小的界面当中内呈现大量的信息是很困难的，通常只会出现两种情况，要么是通过缩减字号来提高单位面积当中的内容密度，要么保持字号不变而对内容进行截断处理。这两种方式都是有很大弊端的。高密度的信息很难被用户良好的阅读和理解，而经过截断处理的内容又是不完整的，难以保证信息的准确传达。

我们可以通过之前列表练习当中的实例来直观地理解这一点。当我们以网格的形式改造了单列纵向列表之后，如果列表项的标题文字变长，我们就必须对字号进行必要的调整，才能使内容完整地呈现给用户，正如我们可以在下图左侧屏幕当中看到的。反之，如果不缩减字号，只进行截字处理，那么最终的效果就会是下图右侧屏幕所展示的样子：

图6-7 缩减字号与截断文字的效果对比

那么，以时间概念为主导的方案能否帮助我们解决这个问题呢？我们不妨在这里回忆一下，过去那些小屏幕手机在这方面通常是怎么做的，也许我们可以从它们身上找到一些答案。

图6-8 将被截断的文字以跑马灯的形式完整的呈现出来

跑马灯效果在过去的那些设备当中是非常流行的。在这种解决方案里，“时间”扮演着重要的角色，因为文字会以动画的方式逐步进入可视区域当中，随着文字从右向左的行进，用户最终会阅读到完整的信息(见图 6-8)。在这个实例当中，“时间”作为一个额外的维度，可以在某种程度上帮助我们解决问题。

这种方式确实适用于一些特定的情况，但出于某些原因，它依然无法彻底解决网格布局当中文字空间限制问题。不妨设想，当这个界面加载完成的时候，每一个格子当中的标题文字都在滚动，这种高度密集的文字动画效果对于用户来说是难以接受的。你很难将注意力集中在某个单独的格子当中，而且必须对时间进行准确的把握，才能在最短的时间内，也就是一个循环周期当中完整的阅读一串文字，否则你所能看到的仍然是一些被截断的内容。我们已经在解决方案里加入了以时间概念为主导的动画效果，那么这个模型当中还缺少哪些关键元素呢？答案就是用户控制。

用户控制的概念是很显而易见的。当前话题的重点在于怎样创建交互设计解决方案，而所谓“交互”，自然离不开来自用户的某种控制行为。不过在这里，我们需要从“状态”的角度来思考用户控制这个概念。

对于交互模型来说，“状态”是一个非常重要的概念，它同样可以帮助我们解决在设计过程中遇到的一些棘手的问题。与“时间”类似，以状态概念为主导的解决方案通常可以完成那些对于静态方案来说几乎是不可能实现的任务。从某种程度上讲，它们都可以从另外一个维度上改变交互模型当中的界面元素及信息内容。

状态究竟是什么呢？它所指代的是当某个交互对象正在被用户观察或是被某种控制机制管理的时候所体现出来的属性和特征。

到目前为止，我们所创建出的网格列表交互模型只拥有唯一的一种状态。也就是说，它只有一个形态，目前还不会发生变化。如果我们可以控制它的状态，在必要的时候对交互模型的结构进行调整，那么就可以真正地解决掉我们之前所遇到的问题。

现在可以将状态的概念与用户控制行为联系起来了。前文当中之所以会提到要从“状态”的角度来思考用户控制，是因为我们可以通过用户输入机制来改变界面交互对象的状态。

那么，我们应该怎样从用户控制与状态调整的角度来解决网格列表交互模型当中的问题呢？当前的状况是，我们认为网格状的列表非常符合差异化的交互体验设计思路，而且在这种模式下，用户可以同时看到很多列表项；但同时，每个列表项的尺寸都变小了，狭小的空间无法完整地将其中的文本对象呈现出来。我们试着通过以时间概念为主导的方案，即跑马灯的动画效果来解决这个问题。虽然这种方法确实使文字内容摆脱了空间的限制，但从界面整体的角度来看，动画效果的密度过大，视觉体验非常糟糕。那么接下来，就让我们一同看一看，当用户控制及状态的概念被整合进当前的交互模型之后，事情又会发生怎样的变化。

图6-9 通过轻扫操作，将被遮挡住的文字拖出

如图所示(图 6-9)，我们可以保持格子当中的文字静止不动，由用户通过轻扫操作将所需的文字对象拖出被遮挡的区域。这种方式将直接操纵的理念融入到了交互模型当中，我们就不必让用户面对着充满文字动画效果的界面了。他们可以在觉得需要的时候对任意一个格子进行交互操作，浏览其中的完整内容。

在这种解决方案当中，我们为文本对象赋予了一定的交互行为，这是相对简单的一种方式。我们还可以扩展一下思路，去尝试一些更具创意的方式。除了文本对象以外，我们其实还可以通过用户的控制行为使整个格子单元的状态发生变化。

图6-10 通过双指张开的操作来扩展格子，以获取完整信息；结束操作后格子自动收回

我们可以让用户通过双指张开的操作将网格单元进行扩展，从而获取完整的文字信息；当手指离开屏幕之后，格子便会自动恢复到默认的状态。只需要一个简单的手势，我们就可以人为地创造出更大的空间，这使得整个交互模型具有了高度的动态性 (见图 6-10)。通过这种方式，不仅文字内容变得完整可读，而且由于整个格子的空间都被扩大，我们甚至可以在其中加入更多有价值的信息。

曾经一个最普通的单列纵向列表，到目前俨然已经成为在用户体验方面具有高度潜力的交互模型了。交互模型在这方面所体现出的扩展性具有很高的实际运用价值。那么，除了能够在某种特定的需求上下文当中提升对象的交互体验以外，这种扩展性如何帮助我们实现更高层次的设计目标呢？

首先我们需要知道一点，在打造交互模型的过程中，我们不能对其进行子虚乌有的构想。交互模型永远是一个完整系统当中的一部分，产品最终带给用户的交互体验必然是一种整体效应的体现。如果你相信设计方案当中的某个交互模型所具有的强健性足以驱动一款产品，那么你考虑清楚应该以怎样的方式将它整合到产品的其它地方，才能在整体层面上实现最佳的体验效应。这也正是我们在前文当中提到交互模型的弹性与扩展性时所要表达的意思。如果你所打造的各种交互模型确实只能适用于各自的功能情景，而无法很好的运用在产品当中的其他地方，那么你至少要在头脑中建立一个更庞大完整的产品级别的交互模型，其中包含着局部当中的各个独立的交互模型；这个大模型必须为用户提供清晰并且一致的交互体验。然而另一方面，一个拥有太多独特交互模型的应用最终只会导致用户产生迷惑和挫败的感觉，这更是完全地背离了我们的初衷。在这种情况下，其实谈不上任何模型的概念了，整个产品只是一堆怪异交互模式的组合。

要避免这种情况的发生，我们在设计工作中必须始终站在全局的角度对每一个交互模型的适应能力进行考虑。这是一种系统化的设计思路，你需要让自己的思维模式上升到抽象的层面，才能对某个交互模型在上下文环境当中的适应能力进行充分地认知。不要只看某个交互模型能够解决眼下的哪些局部问题，而是要判断它所勾画出的交互模式能否在应用中的其他地方同样适用，有没有可能成为某种具有普遍适用性的多用途交互行为模板。

一款应用产品当中使用到的交互类型越少，其交互模型的健壮性就越强。少即是多的原则在移动应用的设计工作当中是绝对适用的。要以降低用户的认知负荷为目标，尽可能使用那些用户已经在你的产品中接触过并理解了的交互模式。

当然，你也不必为了减少交互类型而将某些模式强加在那些确实不适用的地方。简单一致的交互方式固然是我们所追求的，但同时，你也要了解产品中的哪些地方的确需要相对独特的解决方案，否则在这些地方尝试通过具有普遍性的交互模式进行处理的话只能是浪费时间。可以说，如果某种交互方案在你看来并不是非常明确和易用的，那么在用户看来多半也会如此。

也许你已经注意到了，我们一直在不同的地方反复使用着“交互”、“行为”和“模式”这三个概念。在本书所讨论的话题当中，这些概念各自包含哪些含义，它们之间又具有怎样的关联呢？我们在这里简要地了解一下：

交互：单元级的人机互动行为，例如点击一个按钮或是轻扫屏幕当中的某个区域。它的本质是用户在系统的某种提示下所做出的输入操作。
行为：包括用户的输入操作以及相应的系统回馈方式。它是“交互”的一种整体化可感知效应，由系统环境呈现出来。
模式：若干“行为”在某种特定的组织方式下共同作用所产生的累加效应。

你可以在其中任意一个层面上对交互模型的一致性进行规划。你可以从宏观的角度出发，首先思考具有全局性的交互模式，也可以从细处入手，定义那些相对独立的局部交互模型，并对它们的交互体验一致性进行持续的考量。你在交互模型相关工作当中所做的规划，将决定着最终的产品能否以正确的方式解决某些特定的需求

面对竞争对手的产品，积极主动地寻求具有差异化的用户体验设计之道——这个过程会顺理成章地引出“标志性的交互模式”这一话题。所谓“标志性的交互模式”，就是指那些能够帮助用户对你的应用产品及公司品牌产生辨识和认知效应的独特交互模式。

这项工作并不意味着要在现有的产品设计开发流程当中做出某种额外的技术投入，它所关系到的是一种能够在设计方案当中体现出来的观念模式和设计目标。其实，打造具有差异化的用户体验这个过程本身就是对标志性的交互模式的定义，只不过我们一直以来所讨论的对象都是单一的应用产品。如果你所在的公司或团队同时拥有数款系列化的应用产品，那么你在系统层面的全局化设计思路就必须同时扩展到其他产品及相关功能当中。这也意味着你需要扩展交互模型设计方案的作用范围；其中的每一个设计决策都有可能影响到产品家族当中的其他成员。

打造标志性的交互模式

回顾一下我们在前文中探索的网状列表交互模型，其中，网格单元的展开浏览方式以及相应的操作手势的运用，其实算得上是一种标志性的交互模式了。当时，我们的主要目的还是解决文字内容无法完整显示的问题；现在，站在产品全局的角度进行思考，我们还可以将这样的交互模式通过怎样的方式运用在哪些地方呢？不妨在导航方面试试它的可行性。假设这个网状列表其实是应用中的导航结构，其中每一个单元格都对应着一个导航项，那么这种展开并浏览的交互方式用在这里是否得当呢？答案是肯定的。

图 6-11 通过双指张开的方式展开一个导航项，超过一定程度之后，格子自动扩展为全屏

这次，我们对网状列表交互模型进行了适当地改造，不过其中的基础模式仍然是展开浏览。用户可以通过双指张开的方式展开网格单元，阅读其中的导航文字内容。如果展开的程度没有超过某个预设值，那么当用户的手指离开屏幕时，格子就会自动恢复到默认的尺寸；一旦展开的程度超过了预设阀值，那么单元格就会自动扩展至全屏，这个导航项所对应的下级界面就会完整地呈现出来。另外也必须考虑到，用户有可能更加习惯于直接点击单元格来进行导航操作，所以我们不妨将这种方式也加入到当前的模型当中，用户可以根据自己的习惯或是喜好来进行操作。

我们正在打造一种与常规做法截然不同的交互模型。传统的线形空间模型通常会给我们带来一种“节点化”体验，而在我们当前所打造的这个交互模型当中，用户不再需要通过“从A点到B点”的方式在信息结构中行进，他们可以在任何需要的时候直接触发相应的内容与功能。从工作流的角度来说，这两类交互方式没有本质区别，因为它们所实现的需求目标是相同的；而站在体验差异化的角度来看，这两种模式带给用户的感知几乎是完全不同的。

文档化

撰写交互模型文档同样是一件非常重要的工作。你需要抓住头脑中的模型概念，将这些信息落实到文档中，并在设计开发团队当中与大家进行分享和交流。这样做可以帮助你对自己的想法进行验证，确保由这些概念所演化出的实际应用界面可以被用户很好的理解和使用。

你可以采用任何你喜欢的形式来创建文档，只要确保在其中落实以下两个方面的基本要素即可：

以一种简洁而清晰的方式，可视化地将交互模型的本质描绘出来。
为那些难以通过可视化的方式准确表达出来的交互模式提供附加描述。

请记住一点，交互模型文档并不是用来描述用户界面的设计方案或是像线框原型那样对交互对象进行布局规划的。在制定文档的过程中，要尽量避开这些细节层面的问题。因为交互模型本身的作用是描述产品整体或局部当中的交互行为模式，以便为后续的交互及视觉设计相关工作提供明确的目标方向。

下图所展示的是一个可视化的交互模型文档范例，它描述了我们之前创建的网状导航结构。

图 6-12 将交互模型文档化

案例学习

接下来，我们将通过一个虚拟案例来进一步理解这些理论知识在实际工作中的运用方法，并籍此梳理出一套具有普遍适用性的工作模型。案例中的客户和产品都是虚构出来的，我们将通过完整的交互模型设计过程来了解实战中的设计思路和问题解决方式。

X公司

首先，让我们假设出一个客户，也就是X公司。该公司目前有一款桌面软件产品，并且已经在相关市场中取得了一定的成功。X公司最近意识到，他们必须通过一款iPhone应用来打入移动市场，以保持公司业绩的增长。另外，来自用户的呼声以及投资方的压力也迫使着他们必须尽快地做出这方面的决策。

X公司了解到你是一名出色的移动应用交互设计师，所以决定把这个项目外包给你做。他们希望最终的产品可以在应用商店中一鸣惊人，并一举战胜他们的竞争对手刚刚推出的一款同类应用。

X公司的主要业务方向是文化娱乐。在他们的桌面应用中，用户可以浏览那些来自各方面内容源的文娱信息。内容形式以视频为主，音频和图片也会占一定的比重。这款桌面应用能够很好地组织和管理大量的内容，使用户可以很轻松地检索到自己感兴趣的信息。比起竞争对手而言，这也是X公司所具有的优势。

现在，X公司面临着新的挑战：虽然他们的桌面应用很棒，但要对其进行移动化改造，使之成为一款同样成功的iPhone应用，却不是一件很容易的事。桌面应用的用户界面当中有大量按钮一类的控制元素，而且它们显然都是针对键鼠输入方式而设计的。在内容的组织与浏览方面，导航结构多数都超过了三层。

X公司的需求

了解了这些背景情况之后，你就可以着手准备实际的设计工作了。首先，你要根据客户的实际需求来定义产品的核心功能。经过了与X公司相关决策者的访谈交流，并对其桌面应用做了进一步的了解之后，你认识到，他们的iPhone应用需要满足以下几个方面的需求：

帮助用户访问内容库当中的全部信息。
为用户提供一种机制，帮助他们快速高效地发现新内容。
用户可以将内容分享给朋友。
用户可以对内容发表评论。
用户可以发布他们在iPhone上创作或拍摄到的内容，并通过内容库分享给全部用户。

这些需求目标已经得到了X公司相关团队及决策人员的确认。虽然其桌面应用的很多功能并没有体现在这个列表中，但是根据移动应用上下文环境中的用户实际需求来看，目前的这些功能已经足够了。

明确了产品需求，我们就可以对工作流的组织方式进行构思了。在这方面，最好多花些时间和心思，从细节层面对工作流进行深入地挖掘与定义，这样做可以使接下来所创建的交互模型能够最大程度地发挥出自身的潜力和价值。

这份需求列表可以帮我们看出这款应用的本质。其中，绝大部分需求与内容有着直接的关联，而类似分享和评论这样的辅助功能也是依托于内容的基础之上的。所以我们可以得出结论，内容是这款应用在功能与用户体验等方面的核心。当你与客户进行沟通交流的时候，还会对一些将要在后续工作当中面对的关键问题有所预见。例如，我们可以了解到，对于这款以内容检索和浏览为核心的应用来说，用户所做出的交互行为多数是为了获取内容而在层级化的信息结构中进行的导航操作。

要将这一点体现在工作流文档中，有两种方式供我们选择。一是在文档中准确地反映出涉及内容浏览和导航的层级结构；另外还可以将这方面的工作流简化成为文档中的一个节点。让我们通过一张流程图来看看这两种方式之间的区别（见图 6-13）：

图 6-13流程图被简化前后的信息结构对比

这给我们带来了一个值得思考的问题：究竟是否有必要将工作流完整无缺地体现在文档中？这个问题的答案还要视具体情况而定。对于那些会对用户界面设计方案产生直接影响的交互流程，你需要在文档中将它们尽可能完整而详细地体现出来。而对于那些有可能在用户界面设计过程中得到一定程度简化的交互流程，不妨直接在工作流文档中将它们打包成为一个节点，避免工作流的组织方式被复杂化。

在当前的案例中，我们需要为用户提供一种机制，帮助他们在移动应用的上下文环境中快速高效地发现并浏览内容。可以预见的是，为了实现这个需求，我们必须在将来的某个设计环节当中将桌面版应用原有的信息结构进行最大程度地简化，例如可以在构建交互模型时，将内容的导航与浏览整合到同一个交互过程当中。在这种情况下，我们完全可以选择简化版的流程图来指导我们接下来的工作（见图 6-14）。

图 6-14 做出了信息结构会被简化的预见之后，采用简化版本的流程图

随着核心需求的基本工作流被逐步确定，我们也能越发清晰地看到，这个案例带给我们的一个很大的挑战，就是能否找到一种与移动应用上下文环境的关联更加紧密的方式，来帮助用户获取内容。接下来，我们将带着这个问题进入到交互模型的构建阶段

应用的细节

为了能够在X公司的iPhone应用中实现更加合理的内容浏览机制，你决定首先从他们的桌面应用入手，进行更加细致的分析。经过一番实际的使用，你发现，在桌面应用当中，内容被划分为十个主类别，其中每个类别之下都有十个左右的子类，而每一个子类当中又包含着若干独立的内容对象。整个系统当中大约有几千个内容节点。

桌面应用中的交互模型是很容易理解的。它会向用户呈现一个网格状的选项列表，其中每个单元格都对应着一个内容主类别。选择了其中的某个主类之后，整个列表会被刷新，这个主类所包含的子类会依次填充到每个单元格当中。继续选择其中的某个子类，整个列表会再次刷新，并且被这个子类所对应的内容对象重新填充。这些内容对象通常可以填满多个界面，你可以不同的界面中切换浏览。

另外，这款桌面应用在导航方面做的不是很理想。用户必须至少进入到子类列表界面之后才能发现一个所谓的全局导航，而且当你深入到内容层面之后，会发现这个导航只能帮你回到顶级的主类列表界面。另外，在内容层面当中缺乏必要的上下文指示，用户很难发现当前的内容对象从属于哪个子类。

在你对这些流程进行实际体验的时候，要记得将自己的观察和想法及时地记录下来。这些记录也许会对交互模型的创建起到重要的指导作用。正像我们在列表模型改造练习当中了解到的，某些在表面看来无关紧要的零星想法，却有可能被扩展成为很有价值的交互概念。在某些情况下，你完全可以将那些从观察记录里归纳出的想法加入到交互模型文档当中。

根据当前案例的实际情况，你有针对性地在内容层级结构这方面做了特别的记录与分析；这些信息将对交互模型的构建方案产生决定性的影响。目前，我们对于内容结构的理解大致是这样的（见图 6-15）：

图 6-15 X公司桌面应用当中的内容结构

桌面应用的交互模型当中有一个很严重的问题。正如我们在前文当中了解到的，当用户处于内容层面的时候，必须首先通过全局导航回到主类列表界面，才能再次进入子类列表界面或是某个子类当中的内容对象列表界面。而这只是众多问题当中的一个。你现在还不清楚桌面应用当中的这种网状模型能否适用于iPhone的用户体验模式。

既然我们已经在之前的练习中打造过一个网状模型，那么不妨试着对这个概念进行再利用，并且将我们先前定义好的交互机制运用到当前案例的信息结构当中。（见图 6-16）。

图 6-16 在网状模型中，从主类列表界面导航至子类列表界面

由于具有几乎相同的网格结构，这个交互模型与X公司的桌面应用在体验方面是具有很大相似之处的。对于那些已经熟悉了桌面应用的用户来说，这是好事。不过毕竟，这种模型在小屏幕设备当中受到的空间局限还是很大的。在iPhone当中，我们最多只能使用3行3列的网格，而在桌面应用中，网格可以达到10行15列，具体的列数还会随着显示器的规格不同而变化。

正像我们之前在模型改造练习当中定义过的，用户可以通过双指张开的方式展开网格单元，也可以直接点击单元格进入下层结构。不过在当前的案例中，我们要降低第一种方式当中的那个状态阀值，使系统在接收到双指张开的手势之后，能够立刻将单元格进行扩展，直至全屏状态。

这个交互过程中的关键要素就是单元格在展开时所表现出的过渡动画效果。我们希望给用户带来一种感觉，仿佛每一层界面都是嵌套在上一层界面当中的一个网格单元里的；当用户使用双指对某个单元格进行展开操作的时候，可以看到下层界面正在从格子当中呈现出来，并随着单元格的扩展而填满全屏。这种视觉交互效果可以准确地体现出这款应用的信息组织方式，而且对用户来说，这种交互模式也是非常直观的。

遗憾的是，这个模型当中还存在一些弊端，例如回到上层结构的导航方式问题。使用相反的操作手势，也就是双指捏合的方式进行回退操作是具有一定的可行性的，但是对于内容较为复杂的界面来说，这种交互方式的视觉效果缺乏干净利落的感觉。所以，网格模型的概念也许可以在某些特定的需求当中发挥其真正的潜力，但它似乎不适合当前案例中的应用。可以说，这种交互模型的扩展性并不是很强，我们无法将它很好地运用到一些常见的需求当中。

另外，这个交互模型是一种典型的双手解决方案，用户必须一手持机，同时使用另外一只手进行相关操作。这种交互方式本身谈不上不好，但是考虑到最终产品所处的移动上下文环境，这并不是一个很理想的模式。

对于当前的案例，有没有其他更加适用的交互模型呢？让我们回过头来重新思考一下常规列表的可能性。传统的单列纵向列表非常便于单手操作，而且很适合用来展现层级化的信息结构。这种特性几乎使其成为了iPhone当中最具普遍适用性的导航方案。不过也正是因为它的适用性太强，所以通过这种方式打造的交互方案通常会缺乏足够的创新性。有什么办法可以帮助我们以全新的方式来使用传统的列表模型呢？

在之前的练习中，我们曾经对单列纵向列表进行过天马行空般的改造，这次，我们不妨在保持标准列表原貌的基础上寻求一些局部当中的改进方法。在实际产品中，我们不能仅仅为了标新立异而刻意吹捧差异化的原则，尤其是不能在还有相关问题没有得到解决的情况下片面地采用并不适宜的方案。在当前的案例中，网格模型不能很好地帮助用户实现回退方面的导航功能，而且不便于单手操作。另外，正像我们在前文当中提到的，目前的桌面应用当中还存在着其他方面的问题，例如在内容层面当中缺乏必要的上下文指示，用户很难发现当前的内容对象从属于哪个子类，而且当你深入到内容层面之后，只能通过现有的导航机制回到顶级的主类列表界面等等。接下来，我们将致力于打造一个能够解决所有这些问题的新模型。

图 6-17 拥有独特交互方式的传统单列纵向列表。用户可以在某个列表项中向左轻扫，使原本处于隐藏状态的二级列表结构呈现在这个列表项当中。

这个解决方案第一眼看上去很普通，也很容易理解，它似乎就是一个内容类别列表。然而这个模型在很多方面都与iOS当中的标准列表有所区别。用户在前两层信息结构当中进行导航操作的时候，整个列表的视图模式是不会发生变化的。当用户选择了某个主类之后，对应的子类列表会直接出现在这个主类所在的列表项当中。这个过程所涉及到的状态变化只会发生在当前列表项的可视区域里。用户可以在这个列表项区域当中通过上下滚动的方式来浏览子类列表，而当前区域以外的部分则始终保持不变，也就是说，用户无需离开当前界面就能随时访问其他主类当中的子级分类。

我们可以让用户通过向左轻扫的方式将子类列表“拖入”主类所在的列表项可视区域当中，也可以让他们对某个其他位置上的目标对象进行相关操作，来触发某种动画效果，使子类列表移入可视区域。你可以对各种方式进行构思和尝试，并从中找到一种操作体验最自然的、误操作几率最低的来加以使用。

这种交互模型在导航和浏览方面的效率很高，用户可以在同一个界面当中同时查看两个层面的信息。不过这里同样存在一些很明显的问题，例如子类列表会被局限在一个非常有限的可视区域当中，用户一次最多能完整看到一到两个条目。另外，这种模式本身只支持两个类别层面之间的导航，要查看最终的内容对象，我们还需要使用另外一个模型将内容完整的呈现在屏幕当中。所以，这种模式也难以很好地适用于当前的案例。

我们希望找到一种新的方式，它即可以沿用上面这种模型在导航方面的灵活性，同时又能使内容具有更好的可读性。另外，在上面的模型当中，主类条目的表现形式以及对有效空间的占用率也可以得到适当的优化。需要记住，这款应用的核心需求当中要求我们提供一种快速高效的机制，以帮助用户更好的浏览内容。我们对于交互模式的思考必须围绕着这个中心思想进行展开。

我们继续在列表的概念上做文章，不过这次，我们可以试着为列表增加一些不同的属性，使阅读方式更具流动性。如下图所示，这种模型当中不存在彼此分离的视图状态变化，它是一种连贯的、更具动态化的解决方案，而且对用户的交互行为具有更好的响应性。

图 6-18 该模型将主类与子类列表整合到同一个层面中，使浏览更加迅速。用户可以通过纵向滚动来浏览主类列表，在某个主类当中通过横向滚动来浏览子类列表。

这个交互模型与之前的那些有所不同。初始状态下，界面为导航结构和其他功能保留了一定的空间。说到这款应用当中的其他功能，我们并没有进行过相关的描述，因为对于当前的案例练习来说，那些细节问题并不重要，我们的主要目的是站在一个较高的层面上，构筑整个产品的核心体验模式。所以目前，我们只需要将注意力放在与内容的导航与浏览相关的交互模型上就可以了，因为这些方面才是整个产品的基础与核心。

最初，这个模型只会呈现出一部分主类导航项。每个主类都以文字标签的形式出现，用户无需任何操作即可直接获得子类列表当中的分类信息。这种二维导航结构可以帮助用户以非线型的方式在同一个层面中浏览原本属于不同层面的信息。

要查看更多的主类以及它们对应的子类列表，用户只需执行纵向滚屏操作。当主类列表接触到屏幕的上边缘时，排在最前面的几个主类条目就会自动收起，以便为后面的留出显示空间。在这个过程中，用户不需要进行任何控制，纵向滚屏这个操作本身就会触发这种类似手风琴风箱折叠一样的效果。

要查看某个子类当中所包含的内容对象也是很容易的。当用户在默认视图中选择了某个子类时，界面会过渡成为一个新的网格内容模型，这个模型即可以像默认视图那样对内容进行分类呈现，同时也支持没有文字标签的单列网格单元（见图 6-19）。要查看某个内容对象，用户只需要点击横向列表当中的某个单元格，内容对象就会扩展至全屏。

图 6-19 子类列表视图。在横向的内容对象列表当中点击某个单元格，内容对象就会扩展至全屏。

在这个模型当中，我们可以将用于回退的导航控制元素放在界面顶部。这个控制元素既可以是一个简单的返回按钮，也可以是相对复杂的类似面包屑的形式。最重要的是，相比于之前的几个模型，这次我们终于能够以一种比较合理的方式来实现导航控制机制了。

可以说，这是到目前为止我们能够找到的最佳解决方案了。你可以将这套方案落实在交互文档当中，并直接通过这个文档向X公司的相关决策人员及团队做以讲解，引导他们站在用户的角度去理解这款模型的出色之处。从这个交互模型当中，他们也能很直观地体会到这款应用与竞争对手的产品相比所具有的创新性。你完全不用花费时间去打造线框原型、视觉稿或是高保真原型来完成这项工作。

对交互模型的创建过程进行了完整的了解之后，你还可以沿用在这个案例当中学到的方法，继续通过其他产品概念进行练习和尝试，看看能否从中得到一些新的感悟。

总结

令人惊叹的设计要素

“令人惊叹”的设计要素是指那些给用户带来的体验感受可以达到其心中某个“情感阀值”的产品表现层元素。要使应用产品达到令人惊叹的效果，你必须让用户对于设计方案产生某种特别的反应。以下三个方面的因素将决定着产品带来的体验感受能否跨越用户心中的“情感阀值”：

符合直觉：设计方案必须能够引导用户做出最符合直觉的反应行为。
差异化创新特征：设计方案中要有明显的创新特征，至少要让用户感受到某些不同寻常的产品体验。
积极响应：设计方案本身要能以积极的姿态去缓解那些由于差异化所导致的与用户预期或旧有习惯不符的陌生感。

而“令人惊叹”的体验效应以及上述三点推动因素又会受到设计方案自身所具有的一些属性的影响：

界面外观：也就是设计方案所呈现出来的界面布局结构、渲染方式以及所有相关的静态视觉组成元素。
交互方式：包括人机物理交互、手势以及其他常规的用户界面输入方式。
视觉交互效果：包括那些能够为设计方案赋予生机的动态的界面元素及视觉效果。这些交互效果通常与某些特定的响应行为相关，对设计方案的整体质量也会起到重要的影响作用，甚至包括那些与交互行为没有直接关联的临时状态。

如果我们能够在这其中的某一方面做到出类拔萃，那么产品体验就完全有可能达到令人惊叹的程度。当然，这种做法是相当有风险的，要更加有效地提升产品整体的感知效应，这三个方面的良好表现是缺一不可的。

交互模型

通过构建交互模型，我们可以对产品的基本交互方式及视觉交互效果进行规划。构建交互模型的过程通常包括四个步骤，其中前三步是必要的前期工作，而最后一步则是建模工作本身。这四个步骤包括：