其实想整理这篇文章已经很久了，作为一名设计师，首先我就是一名用户。但在日常生活使用app时总发现一些或体验上表达的不太好的地方，时间久了，就有了强迫症。

这里整理下app加载的常见使用场景，以日常app为事例，谈谈我的理解和想法，复盘总结一下。

本文从以下几点阐述，如有不足欢迎讨论指正呀～

1.别让用户思考、别让用户等待

2.加载的两种模式

3.加载时间场景设定

4.常见的加载方式

5.举几个栗子

“别让用户思考、别让用户等待”

开始前，先来段小故事。

前段时间刷知乎，刷到一个关于用户反馈及产品优化后的调研数据，感觉挺有意思。但具体的问题忘记了，刚刚

又去找了很久，没找到，真后悔当时为什么没有收藏。

场景大致是这样的：撰写人可能是位产品、也可能是位开发。做的是手机系统软件吧。在某一个版本上线后，收到了一堆的用户投诉反馈：大概是说在操作手机某个功能时手机反应慢或死机。而他们后期迭代给出的优化方案，就是在用户操作该功能时增加一个加载组件。

后期产品专对此功能做了调研，用户基本反映解决了该问题，并觉得手机系统比之前快了很多。

这段文字其实反映了心理学上的两个问题：

心理预设：

即用户潜意识里的行为或概念预设，是本能的某种反应，不需要思考。就像我们潜意识里就知道一个软件的打开时间，跳转方式。当一个功能使用时与其它功能有很大的差异时，心理预设崩塌，从而产生对该功能的怀疑。

本能对未知的恐惧：

曾经有过调研，用户浏览手机基本以秒来计算的。更何况是没有需求信息的操作功能呢。当操作后间歇很长没有任何反馈，用户不知道怎么了，会想到这是怎么了？我的手机卡壳了？返回重试呢？等等一系列不太好的设想。

所以

互联网时代，一切都是快速的，但互联网产品多多少少会受到实际网络、对接服务器等的约束，【等】肯定是会存在的。在生活中所有的等待都是带有焦虑色彩的。如何让等待变的不焦虑、舒服或者让用户忽略他在等这件事情呢？是需要思考的问题也是提升一个app情感化设计的突破口之一。

加载是什么？

加载是在产品操作过程中对信息的调取、对接服务器、拉取数据库时出现短暂的“过渡时间”，这个时间需要利用加载反馈用户当前操作状态以及及时告知用户操作结果。

加载的两种模式

模态加载

会阻断用户的其他操作，在加载时，用户只能等待加载完成才能继续操作，或者返回或者关闭正在加载的界面。例如：付款，注册，信息校验等。多以Toast弹窗的形式出现。通常用在关键的场景下使用，避免用户反复操作。

非模态加载

及时加载，不会影响用户对产品的使用，用户也可以一边看内容，一边等待加载的完成。例如：上拉刷新、下拉加载等，加载设计方式及表现手法较灵活。

加载时间场景设定

常见的加载的设计方式

举几个栗子

豆瓣  版本6.15.0   6.15.1       

场景：首次发布日记的加载状态

豆瓣日记是一个支持图文编写的日记功能，UGC定位，web2.0时代特色网站之一。撰写功能处于他的最最最最基本的功能。

Test:

1、我写了大概原文1/3长度的游记型日记，数了一下大概10多张图片，1000左右的文字，正常4G网络。点击发布后，如上图

2、点击之后页面就停止在这里了，页面功能区全部禁掉，即只有加载toast

3、然而完成发布你需要：保持手机常亮、不可切换app（回到桌面都不行）、然后等着…

4、我录了屏，时长6分多钟（不切换app、不回桌面、不熄屏）后来因为忙其他手上的事熄屏发布中断。

5、发布失败

6、重复以上

从以上的整理中豆瓣日记在首次日记发布做的就很不友好，我大概整理以下几点：

1、用户知道在加载上传但不知道多久，不确定的等待时间会引起用户焦虑情绪。

2、没有进度反馈，也没有相应的文字提示，告知用户大致上传时间。

3、发布后全页功能禁掉，用户不可操作、不可熄屏、不可切换app、不可回桌面，完全禁掉了用户的所有操作（简直致命点）

该怎么优化呢？

1、或将模态加载改成非模态加载，或增加保存功能，随时编辑随时可上传服务器。

2、将toast加载改为进度条加载，并在结束给出发布成功/失败提示。

3、转为后台上传不影响用户接下来的操作。降级优化，控制当前状态页面熄屏，并告知大概上传时长。

我相信做了以上这些，加载时长及用户体验会好很多。期待豆瓣的下次迭代，我再试试。

马蜂窝 版本：9.3.14    

场景：首次发布游记的加载状态

蚂蜂窝游记

支持图文编写的游记编写功能

Test：

1、编辑游记总共14张图片，2251个文字，点击发表出现右图

2、点击之后页面就停止，页面功能区禁掉，页面呈现加载toast和上传进度条，一个表达状态，一个传达进度

3、整个发布过程大概1分钟，手机没有熄屏

4、上传成功——填写基础信息后——发表成功

就整个流程都很顺畅，反馈及时，等待加载的过程完全没有未知情况出现，就显得很人性化。

知乎 版本：6.1.0

场景：首次发布文章的加载状态

知乎文章编写

支持图文编写功能

Test

1、选择图片后直接上传服务器，页面出现上图左一，边加边上传。

2、页面加载间断1-2秒后（可能网络问题）可继续操作，即时保存草稿箱，即使你中途退出浏览器，回过头在草稿箱也能找到。

3、点击草稿出现文章列表，该文展示列表第一条

4、点击发布，出现toast加载加载过程1-2秒完成发布。

这个就很像邮箱，即时保存。好处是撰写的文章不会因为网络、退出、更新、卸载等情况出现的丢失。不太好的

地方：每次插入图片后页面都会有短暂的禁用，1、2张还好，过多张上传就会有些不舒服，加载时间比较长。但

相对于归于最后一步对接服务器所用的时间，这种分散性上传要好许多，而且丢失的风险小很多。

站酷 版本：3.9.1

场景：首次发布文章的加载状态

站酷作品编写

支持图文编写功能，编写功能与微信很像。

Test

1、打开作品编辑页面，选择上传的图片，界面下方出现图片预览。

2、编辑文字内容，不支持图文穿插

3、点击返回，跳出保存草稿提示，选择是（下次自动带出内容）选择否放弃编辑并退出。点击下一步到发布页面，选择编辑相关操作。

4、点击发布，跳出编辑页面，app顶部增加加载进度条且app其他功能可操作（除发布功能）

这个举例可能跟上面的不太像，但是它最后一步的加载处理的比较好。

首先站酷作为设计师交流网站，设计师作品一般内存较大。每次只可以发布一次作品，发布失败保存草稿，下次打开自动带出。发布过程不影响用户app内其他操作（发布除外）。在不关闭app、有网络的情况下，可切换app、可熄屏不影响作品上传，再打开app 时已上传成功。

很显然站酷发布方式看起来和微信一样，但又不一样，适合站酷的产品定位及符合用户习惯。

综上所诉：

有人说只是一个加载的问题，有这么大的文章吗？加载是服务器与用户对接的桥梁，是一个app不可或缺的控件当然它与产品功能相辅相成。有没有用，用过后就知道。

但怎么用加载，用哪里都是有讲究的。就像明明袜子是穿脚上的，有人把它套在手上就很是奇怪；比如一个人生气了偏偏不说而让人猜，而猜的那个人就很抓狂；比如和朋友约会，约定的时间到了都还没来，联系不上，没有任何反馈，等待的那个人一定很焦虑等等诸如此类。

合理的利用用户习惯、及时反馈。别让用户思考、给出明确指令/反馈，app用起来才会流畅顺心。也许一定程度上减少了摔手机的概率。

The End