微信轻应用是时下的一个香饽饽。一方面是因为随着H5语言的定稿及其开发经验的沉淀，开发者以较低的成本即可打造出具有一定可用性的Web App。另一方面，微信作为一个超级社交App，天然具有巨大的流量入口价值与传播分享价值。因此，在微信平台宣布全面开放接口后，无数互联网创业团队、企业，甚至是个人，纷涌而入，杀成一片红海。
但是，实际使用时，微信轻应用的体验并不是那么的“爽”。诚然，这与H5语言的技术局限性有着很大的关系。但抛开这一点，走肾而不走心的设计也是造就“不爽”体验的重要原因。本人在体验过一些的微信轻应用后，尝试总结出了一些对微信轻应用交互设计的思考。
在亮出个人总结之前，我想先谈谈进行微信轻应用设计时的难点与机会。
微信轻应用设计的难点源于H5技术的局限性以及微信平台本身的局限性。
1. H5的局限性：
- 使用场景上，严重依赖于稳定的网络环境。由于几乎每个元素及每次操作都需要发送网络请求，因此，在弱网络的环境下，使用的痛苦指数是趋向于无穷的；
- 技术上，一方面，通过Canvas标签与CSS来进行图像、动效的渲染，效果马马虎虎，容易造成卡顿的即视感；另一方面，缓存技术仍不完善，如点击列表进入详情页再返回时，通常需要重新加载一次列表；
- 权限获取上，无法获取照相机、系统级别通知等设备或接口的权限，功能上大打折扣。
2. 微信的局限性：
- 使用场景上，与聊天场景存在着激烈的矛盾冲突，导致任务随时可能被打断。打断之后，再次进入的成本高如汪（需要从滔滔信息流中重新定位应用位置，并从头开始任务）；
- 平台设计规范上，应用首页（即公众号对话窗口）的样式只能使用聊天气泡+底部菜单栏；以微信浏览器打开应用时，必须使用微信预设的顶部导航栏。这些或占据了一定量的屏幕空间，或一定程度上限制了设计发挥；
- 权限获取上，除极少数微信家的亲儿子外，其他应用均无法获取顶部导航栏右侧按钮的自定义权，这就更加限制了设计师的发挥。
但很多时候，限制即是机会。“聊天气泡+底部操作栏”的设计规范，反而为应用的信息框架与导航设计提供了更多的思路。一方面，IM工具的输入/反馈机制，为用户与应用的交互方式和信息的呈现方式带来了新的可能；另一方面，底部菜单栏可以是对Native App中Tab Bar选项的隐喻，恰当使用可以降低用户学习成本。
废话了一大箩筐，下面马上向个人总结页面跳转。
根据进入场景，定义页面架构
用户的认知模式是长这样子的：会倾向于把公众号的对话窗口视为微信轻应用的首页。底部菜单栏中，每一个标签即是一个功能模块的入口（相当于Native App中的Tab Bar）。点击标签后进入的第一个页面即是该功能模块的顶层页面，从该页面返回则必然是回到对话窗口。
这带来的启示之一是，在设计页面架构时，可以考虑将对话窗口中的底部菜单栏视为Native App中Tab栏的隐喻，将功能模块平摊到这些操作栏中，并削弱模块之间的关联性。如微信轻应用“Yolo优洛会”中，每个底部操作栏标签均对应一个功能模块，且功能模块之间彼此独立，点击进入后可获得独立、完整的沉浸式体验，让用户专注于任务本身，并降低了学习成本。
启示之二是，对话窗口与功能模块的顶层页面之间必须建立唯一的上下层级关系。一个反例就是，“行动流”微信轻应用中，点击对话窗口底部操作栏中的“圈子”，进入新页面后，再点击左上的“圈子”按钮，试图返回，却发现跳转至了一个全新的页面。该页面顶部是Icon和Slogan，下面是“我”、“圈子”、“梦想”这三个功能的快捷入口，正是设计师眼中的“首页”。然而，该页面的到达路径并不符合预期，容易把用户灌醉。
使用唯一的、微信预设的“返回”导航样式
微信已经强制为所有应用套上了顶部导航栏枷锁，其中就已经包含了“返回”按钮。然而，仍然还有不少应用坚持添加上自己亲手设计的“返回”按钮。
双重“返回”样式增加了认知障碍、挤占了屏幕空间。就算是出于“左上返回按钮位于拇指热区外我们来让它更容易被点到吧”的出发点来考虑，其存在意义也仍然十分牵强。相反，将其移除后，腾出来的空间可以激发更丰富的设计思路(比如，用来放置全局导航)。
灵活使用多种导航样式
即使是在高配置、强网络的条件下，页面跳转在微信轻应用中仍然是非常痛苦的体验。而灵活高效的导航是减少页面跳转的一大杀器。
微信轻应用上，常见的导航样式如下：
1. 对话窗导航
2. 一级导航
3.全局导航
4.场景式导航
在微信轻应用的语境下，局限于一种导航样式是很难达到“灵活高效”的目标的。搭配使用多种导航样式效果才能好。
舍弃重动效，做足微交互
H5的技术限制，使得一些在Native App上司空见惯的动效套用在微信轻应用上时显得笨拙无比。当然开发水平是影响动效是否流畅的一个决定性因素。但过重的动效需要占用大量的用户资源，同时也加大了开发的成本与难度，违背了“快速开发”的初衷。因此，在进行微信轻应用的设计时，要尽可能地避免“使用动效解决问题”的思路。
但这并不意味着要舍弃一切动效。事实上，比起Native App，微信轻应用对“微交互动效”更加依赖。主要表现在以下几个方面：
1. Loading态
微信轻应用需要源源不断地发送网络请求，也就留给了用户大量用于等待的焦虑时间。而Loading态的微交互的使命正是化解这股焦虑。
2. 缺省态
Lodaing态的对应加载方式是全局加载，这种方式比较适用于数据请求量不大的页面加载场景。而数据量较大的页面则普遍使用异步加载的加载方式。异步加载即各项元素按照一定的优先级顺序来进行加载，因此在加载过程中会出现各种空元素。这时候就需要缺省态的微交互上场了。
3. 操作反馈
由于H5的效能问题，在“用户进行操作”与“系统执行操作”之间往往会存在一小段延迟。在这段延迟期间，若没有任何反馈，用户很容易会误以为自己操作失败而做出什么不好的事来。操作反馈的微交互可以间接加快应用的响应速度，阻止用户犯错误。
4. 输入
正在输入的文本框必须要在视线焦点范围内。这点听起来似乎是天经地义。但很不幸的是，这个世界上存在着太多的无情无义的微信轻应用了。
仅让重要的信息可视，并减少其加载量
“如何让用户觉得运行速度很快”是进行微信轻应用设计面临的一个核心问题，而页面加载的速度正是衡量“运行得快不快”的一个重要尺度。
用户是如何感知、判断页面加载的速度的？这主要取决于第一个可视元素出现所用时间和“感觉这个页面已经完整了”时所用时间。将这些用户视角的体验需求转化为指导设计的方法论则是，减少页面中可感知到的信息的数据加载量。这些可感知到的信息必然是重要的、高展示价值的。至于其他次级信息，可选择性地将其隐藏，并降低其加载优先级。这样，即使次级信息仍在加载中，但由于其已被隐藏，用户感知不到，因此仍会认为当前页面的加载速度是nice的。
隐藏信息的方式总结有以下几种：
1. 将一段长信息不完整展示
2. 将信息分组，通过控件隔断不同组的视图空间
3. 设置一次性加载的数据量的阈值，加载更多时需要额外操作
提高列表筛选效率
由于技术限制，现阶段大部分微信轻应用从详情页面返回至列表页面时，并不能定位到最后停留的列表位置上。
突破该技术瓶颈固然是最有效的解决方法。但据观察，目前只有微信钱包中自带的“京东”轻应用解决了该问题。因此可以基本断定该解决思路暂时无法实现。
面对如此艰苦的设计背景环境，另一个解决思路是提高列表筛选效率，降低用户从详情页返回列表页的概率。比如，往列表中注入更多的辅助用户决择的信息字段；又或者是将详情页中的关键入口前置，缩短用户到达路径。
在微信钱包中自带的“大众点评”轻应用中，店铺列表页处囊过了该店铺的团购入口，一来团购信息可以辅助用户进行店铺筛选，二来缩短了购买团购的路径，极大地提高了列表的筛选效率。
考虑逆向路径，避免无效的“返回”
设计师或许掌握了成吨的让跳转页面无感化的技巧，但一切真相都逃不过“返回”按钮的审判之眼。按照微信的逻辑，每一次点击“返回”的结果，必然是回到上一次加载的页面。这使得一些在正向操作时感觉高效简洁的设计方案在逆向操作时让人疼到无比。
比如微信钱包中自带的“美丽说”轻应用中，使用Segmented Control控件承载化妆品分类。切换类别时，体验近乎无感。然而，当点击“返回”按钮时，并不是回到微信钱包首页，而是回到上一个化妆品类别的列表视图，严重不符合用户预期（明明就是同一个页面，怎么点了返回没反应的）。
正因为如此，在技术上无法解决该问题的前提下，并不十分建议使用那些容易引发“不需要进行跳转”的错觉的导航样式，比如Tab式导航。不仅在正向路径中违背了“肯定不需要跳转啊”的用户预期，也在逆向路径中也显得臃肿低效。
最后之YY：提供返回最后停留页面的入口？
用户正在使用微信轻应用，手机突然震动了一下。这时候用户是会选择将当前任务进行到底，还是会离开应用查看微信信息呢？这取决于用户使用应用的目标强度以及获取新信息的迫切程度。但无论如何，用户一旦离开了应用，如果想要再次回到最后停留的页面，就必需从头开始。
无论是对用户还是开发商而言，这种交互逻辑都不是什么好东西。那么，能否在浅层级的页面中提供返回最后停留页面的入口呢？比如，在轻应用的页面中提供“稍后阅读”按钮，点击之后，公众号可以将该页面的链接以信息流的形式推送给用户。这样，用户只需要重新进入公众号对话窗口，直接点击信息中的链接即可以重返最后停留的页面了。
当然，这只是个人YY，是否具有可实现性仍需要技术同学的审批。
由于个人知识体系实在浅薄，关于微信轻应用设计的思考暂时就只有这么多了。在此真心希望H5的开发技术快高长大，让微信轻应用与原生应用之间的体验差距越来越小。
