实时响应设计的几个原则

设计实时响应的用户体验时可能有用的几个基本原则：

1、状态清晰

用户应该清楚系统当前所处的状态，任何时候，程序应该向用户传达清楚当前发生了什么并针对用户的每一步操作给出清晰的反馈。

应用程序本身建立在一个非结构化的系统之上，其试图向用户提供结构化的数据。虽然实时响应的界面并不使用类似于页面刷新器这样的固定标识符，但它同样可以使用恰当的信号来标识状态的改变。

实例：网络连接状态

在我们使用移动设备的时候，难免会碰到网络掉线的情况，这时候最好告诉用户是由于超出程序控制的某种因素导致了这种意外情况。

不好：网络掉线后并没有告诉用户 好：出现清楚的通知告诉用户网络掉线，系统正在尝试重新连接

实例：加载状态

低带宽（网络环境差）、加载数据量大、多点连接等诸多因素都可能引起用户在使用你的程序过程中需要花费一定时间等待。应对这种情况的方法是你要培养自己成为一个具有前瞻性的设计师，通过一定的方法凸显出系统正在响应用户行为并尝试加载新数据，好让用户意识到这一过程。

不好：系统没有告知用户他在与列表项交互后，系统就开始加载内容了 好：头部的进度指示器向用户标明了加载过程，以及需要等待的时间

实例：确认状态

应该积极响应用户的操作，并给出结果的反馈，让用户意识到系统对其行为目标的状态是关心的。

不好：用户到新页面后，系统并没有告知其前面的删除操作是否成功了 好：使用一个提示强化了系统对删除操作的响应

2、有预期的改变

用户应该清楚预期效果是怎样的，就是说程序应该向用户表明在他们操作就将发生什么。

在一套逻辑严谨（按部就班，模式固定）的系统里，出现一些惊喜（意外）并不会令人愉悦。对于一辆负责运送乘客的普通汽车，如果你关心的是其精密的机械结构，那么爆胎和发动机歇火就是在你的关注点之外的意外惊喜。 跟汽车类似的是，一个应用程序通过其精细的设计（相比于汽车通过其精密的机械结构满足人们的需要）来满足用户的某种需求，然而不同于汽车的是，现在的数字媒体（应用程序）允许我们预料到将要发生的变化并提前告诉用户。

实例：（1）传达结果

当系统可能出现较强烈的状态变化时，应该提前向用户预示其行为操作所将带来的结果，这样也就给了用户自己来把控即将发生的事情的机会，进而避免发生出其不意的“惊喜”。

不好：没有任何迹象或动作，新的信息就出现在列表中 好：当新的信息准备好加载后，系统出现提示，用户与之交互后方插入到列表中

实例：（2）使用骨骼框架

为了缓解用户在等待数据加载时的长耗时，并让页面间的转换过渡更为流畅，可以考虑在数据加载出来之前先向用户显示一个内容框架，让用户能够预期到新页面将要填充的数据类型和复杂度。这样做带来的另一个好处就是会让用户感觉到你的程序在响应用户操作时还是相对及时的。

不好：在页面内容未加载完全之前，用户不得不在第一个页面一直等待 好：在页面内容未加载完全之前，页面便跳转，使用占位符向用户标明即将加载的数据类型和复杂度

3. 保持上下文环境统一协调

用户应该清楚他们看到的内容从何而来，是属于哪里的。

在实时响应类型的应用程序中，通常情况下我们不可能看到系统的所有响应变化（有一些中间态可能在某些条件下才能触发），这时候，我们设定并强调一条缓冲带就显得非常重要，它用来揭示每个页面和按钮跟其他元素的关系。这种做法就意味着我们创建了很多个标示，用户依赖它可以在这些关联的页面、元素间流畅切换。

实例：（1）保持布局一致

所有新的内容应该出现在一个可预期的位置，要让用户习惯于在程序中特定的关键位置点间穿梭转换，尽量避免提供多种方式给用户来做同一件事情的做法，这会稀释用户对各个行为路径的关注度和适应性。

不好：新的信息出现在不可预期的位置 好：新信息自当前列表顶部插入。用户便渐渐意识到新信息出现在列表上部

实例：（2）保持良好的状态变化姿势

如果关联信息间的状态改变出现在一个不可预期的位置， 可以使用设计精巧的动效来向用户传达新内容的出现及对周围信息的影响。这种做法一定程度上延缓了用户的体验过程，但能使得状态的变化过程非常清晰明了。

不好：一条信息插入列表后导致相邻的信息依次移位 好：使用一个精细的动画效果凸显新内容的出现和相邻内容的动位，给用户一定的反应时间

实例：（3）记录保存滚动位置

当在两屏内容间来回切换时，要确保用户回到的是返回前在当前页面的最后浏览位置。

不好：滚动位置并未保存，用户要花时间重新定位上次的浏览位置 好：保存了浏览位置，使用户能在页面间放心切换

译自：http://blog.percolatestudio.com/design/design-for-realtime/