隐藏在背后的交互设计

 　　外行人对交互设计的第一印象是什么?画线框图的?做草稿的?

　　的确，大家所看到交互设计师的日常工作成果都是一些线框图，从表面上理解的确是这样。

　　其实，交互设计师做的远远不止这些。往深一步想，信息架构、界面、流程，都是设计师需要考虑的问题。下面，想谈一下我理解的交互设计。

　　交互设计最重要的两个因素：信息&互动

　　一：信息

　　人们每天面对那么多信息，在杂乱的信息中筛选出对用户有价值的，呈现给用户，帮助用户做选择，指引用户完成任务。信息的筛选直接影响着用户使用，在用户需要的时候无法提供有用的信息，将导致任务无法进行下去。所以信息是交互设计师需要关注的第一要素。

　　二：互动

　　有了信息后，就需要设计用户如何与这些信息进行互动了。信息的分类、布局将影响用户与信息的交互。用户获取信息后，做出了反应，采取了行动，应用也需要有来有往地给予足够的反馈，来协助用户完成任务。

　　以上2要素，都是从用户直观感受上去体现的，也就是说往往是表现在用户界面上。我们可以把它称之为“看得见的交互设计”。

　　具体的形式包括：

　　信息架构：把筛选好的信息进行分类，通过页面来承载这些信息，并且把信息(页面)的层次规划好

　　界面设计：把信息在一个页面上进行布局

　　流程设计：把一个任务中涉及的页面信息串联起来，使任务形成一个线性流的关系

　　以上三个关键点，是对交互设计师的基本要求，很多情况下，非专业人员也能做得7788，但还有一部分的交互设计，并不是直观能看到的，也许用户会轻微感受到，但他总在不经意间使用户使用得更加流畅。我们可以把它称之为“看不见的交互设计”。而这些看不见的交互设计，也是初级交互设计师容易忽略的。

　　如今移动互联网发展迅速，移动产品对这些看不见的交互设计更为注重。因为移动应用的使用场景、网络环境、使用心态都与用户在使用web产品时有着大大的不同。所以在了解这些看不见的交互设计时前，需要对移动应用的情景有一定的了解。

　　1.使用场景

　　用户在使用移动产品，有可能会在户外人多的公众场合使用，这时候需要特别注意移动应用设计的隐私安全。

　　用户有可能在家里、在床上、在厕所，用着各种姿态使用产品，所以对交互的便利性和容错性要特别注意

　　2.网络环境

　　网络环境是“看不见的交互设计中”非常关键的一点。用户会在2G、3G、wifi甚至无联网的情况下使用产品，所以对于各种网络环境进行合理的交互设计是移动产品交互设计师需要考虑的重中之重

　　3.使用心态

　　产品的存在是为了解决用户的问题，而移动产品是用户的贴身工具，当用户需要时，能立刻开始运作，需要快速、直接、有效，用户不喜欢等待。有研究结果表示：

　　在移动产品这种特殊的环境下，“看不见的交互设计”会相较于web产品更为重要，特别是针对网络环境和用户等待的体验需要特别注意

　　下面将展开讨论一下“看不见的交互设计”

　　总的来讲，可以归结为三大点：

　　1.加载机制

　　2.刷新机制

　　3.缓存机制

　　加载机制

　　通常情况下，我们使用的绝大部分是网络App，他的工作原理是这样的：

　　用户在客户端的界面上进行操作，客户端发送请求到服务器，服务器处理请求，返回数据给客户端，并显示给用户。

　　其中，客户端和服务器的交互过程，用户是感知不到的，而他确实会耗费时间，在不同的网络环境下耗费的时间也会有所差异，如何让用户在这段时间里有友好的体验呢?这时候“加载过程”起了作用。

　　加载过程的关键可以总结为：

　　1.让用户感知产品正在努力为他运作

　　2.让用户有基本的心理预期需要等待的时间长短

　　3.让用户在无聊的等待中获得更多乐趣

　　进度条是一个针对加载过程很好的设计。

　　动态的加载进度表示产品正在工作，总进度和当前进度能让用户及时了解情况，让用户能根据这些信息预判时间，有了心理预期。

　　有趣的进度条设计or在加载过程中展示一些功能介绍提示(常用于游戏)能有效减少用户等待时的焦躁心理，也能有效地提高用户的容忍度。

　　这里我们收集了几组不同风格但同样有趣的进度条，你可以找下灵感。

　　进度条是web产品时代的产物，还有另外一种加载设计，就是加载图标

　　由于移动产品请求的数据量并不大，所以进度条往往会在一瞬间就完成了，在这种情境下，简化了加载的设计，很多移动产品转而使用加载图标来表示加载过程

　　以上为两种比较常用的加载方式，下面将具体介绍他们与移动产品结合的用法

　　1、页面加载机制

　　移动产品的信息都是通过页面来承载的，页面的加载方案设计是交互设计师面临的一个重要难题。

　　方案一：单页面整体加载

　　这种加载比较简单，一般运用在页面内容比较单一的情况下，所以直接一次性加载完所有数据后再显示内容。

　　单页面加载失败的状态也比较好处理。

　　方案二：单页面分块加载

　　这种方案的特点是，能让用户逐步看到内容，在这个渐进的过程中降低用户的焦虑心理。

　　其中又可以分为，模块间有关联性的，先加载父内容，再加载子内容。

　　如优酷，先把栏目加载出来，再加载各栏目的内容。

　　模块间没有绝对关联性的，可独自加载各自模块内容，根据请求的速度不同分别显示。这样处理有一定几率让用户在没完全刷出数据的情况下就能找到自己需要的功能，如大众点评、淘宝客户端。

　　框架固定，内容更新的，可先把框架显示出来，再把各模块的数据各自加载显示，如各种iOS自带应用，云音乐。

　　这种分模块加载的需要特别注意加载失败的状态，毕竟每个模块都提示加载失败，点击重试是很挫的一件事，可以根据信息的优先级来决定哪些数据失败了采用默认状态，哪些数据采用失败提示。

　　方案三：跨页面加载

　　父页面&子页面 or 同一app内，页面间字段可以复用的，在加载子页面时不需要重新加载新数据。

　　方案四：预加载

　　这种加载方式的特点是，在加载一个页面内容的同时，预测用户的下一步行为，并为他下一步需要使用的页面加载内容，使得他在下一步的操作中能立刻获取信息而不需要加载等待。

　　预加载提供给用户无缝的产品使用体验，使得用户在使用产品的过程中更直接流畅，没有被打断的感觉。

　　具体的例子有：

　　在浏览图集的时候，当看到第一张的图片时，就自动后台加载第二第三第四张图片，用户浏览完第一张图片切换到第二张时就不会有加载等待的过程。

　　在浏览新闻列表时，就把每篇新闻的内容在后台进行预加载，用户选择看某篇新闻时，能立刻阅读到内容。

　　但是这种方案需要面临很多的问题，最直接的是流量问题，因为会自动跑掉很多用户可能根本用不上的数据流量，所以一般情况下可以设定在wifi环境才采用这种加载模式。又或者设定加载规则，只把主要内容预加载，而部分次要内容可以在用户真的用到的时候才加载，例如预加载新闻正文的情况，可以只加载文本信息，图片信息等到用户进入内页才加载。这种预加载与分块加载结合的方式也普遍运用在各个场景。

　　另外，预加载也需要时间的，他只是不在客户端显示给用户，默默在后台运作而已，需要特殊考虑未加载完用户就使用到那些信息的情况，所以在做预加载设计时需要同时考虑另一种适合该情况的普通加载方式。

　　预加载需要根据具体的场景来进行设计，设定好信息优先级，综合考虑各种类型信息的具体大小流量，整体考虑预加载的方式，这些都是需要经过精心分析思考的。

　　随着网络环境的发展，预加载将成为以后产品普遍的加载方式，他提供给用户的无缝使用体验大大地提升了产品的可用性。

　　2、操作加载机制

　　除了页面的信息需要加载，页面内的操作也是需要通过给服务器发送请求记录的

　　方案一：加载层

　　进行一个操作后，弹出模态的提示层，告知用户正在加载。

　　采用模态的提示主要是防止用户在该过程中进行其他操作，导致当前加载出错。由于采用模态的提示，并且有可能因为网络原因导致长时间处于加载状态，建议提供一个“关闭”的操作，中止本次加载，恢复App可用状态。加载失败时可在当前浮层变换为失败提示。

　　模态提示层是最稳妥的方式，但他会使用户在使用过程中有打断的感觉。

　　方案二：控件自身加载状态

　　这种方式是把操作加载的状态与控件的样式结合起来了，对某个控件进行操作后，控件变换为加载状态，此时控件不能重复操作。

　　由于这种加载方式是控件的自身状态，不影响其他操作，所以用户也可以对页面进行其他操作，可能会导致同时有多个请求的情况，增加了加载失败的风险，这也算是这种方式的弊端，不过这种极端情况很少出现。请求失败后，可配合Toast提示告知用户失败的原因。

　　方案三：后台加载

　　用户在操作后，客户端立刻反馈操作成功，然后把请求放到后台与服务器交互，这一过程用户不需要了解，不需要等待，在正常情况下体验是非常棒的。

　　但是在极端情况下会出现一些莫名其妙的状况，由于是后台记录请求并与服务器交互，所以实际请求是否成功客户端是不说明的，全部以操作成功来显示，这就会导致用户误以为操作成功了，但实际上下次来看发现没有成功。所以这种加载方式是需要根据具体使用场景来权衡使用的，对于一些重要的操作，建议还是使用模态的方式加载，对于一些小操作，如点赞、订阅、关注，可采用后台加载的方式。

　　刷新机制

　　刷新机制也是设计师很容易忽略的问题，合理的刷新机制能让产品使用起来更流畅

　　普遍情况下，刷新机制有以下三种：

　　方案一：手势刷新

　　通过手指在屏幕上的左划右划上划下划达到刷新的目的，也包括一些浏览器产品的自定义手势，如横折折勾，进行刷新

　　最常见的下拉刷新也属于手势刷新的一种

　　方案二：点击刷新

　　通过点击一个按钮达到刷新数据的目的，但是如今刷新按钮的存在已经成为一种过时的表现，况且在手机那么小的界面上还需要为刷新按钮腾出空间，会挺费劲的。不过避免形式主义，用得恰到好处才是设计的精髓，这种刷新方案还是按需使用吧。

　　方案三：自动刷新

　　根据设定好的规则，如时间、事件规则自动向服务器获取新数据并替换旧数据。使用自动刷新需要根据场景来考虑是否合适

　　场景一——对于频繁更新的内容、有时效性的内容，用户在一个设定的时间没有使用，则可考虑在下次使用时，自动刷新，把新的内容推送给用户

　　类似微博、新闻这种具有时效性的产品，用户在24小时内未打开产品，则在下次打开时帮用户自动更新Timeline

　　场景二——对于一个相对稳定，数据不会经常变化的页面，可以考虑设定时间规则，在后台为用户默默更新数据并替换旧数据

　　缓存机制

　　“缓存”这个词在web时代也经常听到，但在移动产品上，他的重要性得到了很好的重视

　　一张图解释什么是缓存和缓存的作用。

　　“缓存”就是把已经加载过的数据保存起来，并在下次需要重复使用的时候，不需要向服务器加载，直接获取本地数据。

　　我理解的“缓存”可如下分类：

　　临时缓存常用于一个功能页面内，保存各栏目的缓存。同一个功能里会把子功能分为多个栏目进行划分，每个标签栏目下的内容在本次使用中都可保存为临时缓存，在该功能里切换栏目，不需要重新加载数据，使用缓存显示。对于用户来说，使用时达到了无缝切换浏览，对于服务器来说，在短时间内数据很少会有更新，所以在一般情况下能满足用户的正常需求，并达到体验优秀

　　临时缓存的清理机制是：退出该功能模块就清除之前的缓存。也就是说下次进入该功能模块，需要重新获取一次数据。

　　很多时候我们都会用到临时缓存，因为那些信息真的不是那么重要，而且不需要经常反复查看，那对于那些我们经常使用而且经常需要反复查看的信息，我们就会采取固定缓存保存在本地，方便下次翻阅时不需要再一次向服务器请求数据了

　　其中又会细分为可手动清理的缓存，和不可手动清理的缓存

　　第一种是我们最常见的缓存，几乎所有产品都采用这种缓存方式。平时用户浏览文章、图集加载的数据就以这种形式缓存在本地，下次看回这篇文章、图集时就不需要加载了。用户也可以手动把这些缓存清理了，释放空间。

　　而对于某些特殊场景，例如一些相对固定的数据，我们不愿意一开始就打包进App里，这样会占太大容量，造成产品包很大，也不愿意每次进入页面都向服务器加载这些信息，那怎么办?解决方法就是我们可以只加载一次就永远存在本地了，这样安装包也不会大，以后也不用加载了。

　　例如一些页面的背景图，相对固定不常更换，所以在用户首次进入该页面时就加载背景图并保存在本地，这种缓存是不可清理的，下次再进入该页面就读取本地缓存显示即可。

　　这种缓存方案使用得很少，因为场景太少，具体使用场景还有待开发。

　　对于这些保存在本地的缓存，都是会占空间的，手机的容量是有限的，那产品是通过怎样的方式清理缓存的呢?

　　大家熟知的有手动清理，一般App都会在“设置”里提供一个清理缓存的功能，一键把空间释放。除此之外，App最好要设计自动清理机制。

　　可以通过两个维度来设计这个机制。

　　时间

　　通过设定一个固定的时间，或者根据用户使用周期灵活设定时间来清理缓存。每个产品的场景不一，用户使用频率不一，设定这个机制的时候就需要结合实际情况考虑了

　　容量

　　一般是设定一个容量上限，采用堆栈的设计原理进行缓存清理，溢出堆栈的旧数据将自动清除

　　小结

　　这些“看不见的交互设计”就是纠结在那些细节，但作为交互设计师千万不要以为这些是很细小的点，其实他是有大文章可作的。

　　刷新、加载、缓存机制的设计，我不清楚是否应该归纳进交互设计师的职业范畴，但是作为一名用户体验设计师，这些点或多或少地影响着用户的使用体验，我们都应该给予足够多的重视。

　　这些机制，独立来看都有现有模式可参考，但是交互设计师不应该把他们割裂地设计，他们往往是合并在一起时才会有意义。不同机制的结合，往往有妙用，这就需要设计师根据每个产品的不同场景来特殊制定了。