UI 智能化的原理和未来

GUI 易用性背后的复杂度

在应用程序提供者和使用者之间的交流中，提供者以 GUI 为媒介，核心实现了两个目标：承载信息、提供交互。承载信息相对于使用者视角就是获取信息，提供交互相对于使用者视角就是进行交互，由此可见交互就是使用者和提供者间借助 GUI 完成的一场交流互动。在冯诺依曼把计算机架构抽象为：运算器、控制器、存储器、输入设备、输出设备，以这种统一的抽象为基础，他把程序当做数据来看待，与数据一起放在存储器中，这样计算机就可以调用存储器中的程序来完成计算机的控制。这种设计思想直接导致了硬件和软件的分离，让硬件和软件设计可以分开执行，从而诞生了程序员这个职业。系统程序员负责编写从存储器中读取、翻译、分析程序指令，然后根据指令向运算器和输入、输出发送控制命令，其实他们编写的就是我们所熟知的操作系统、内核模块、设备驱动等等。应用程序员则是在前者的基础上，开发各种各样的应用，例如 Linux 用文件来抽象 I/O 提供文件句柄对其进行操作，应用程序员就可以借助这些文件句柄开发一个文件压缩解压缩的应用。

我在学习这些 Linux 提供的阻塞式、非阻塞式 I/O 编程接口，并开发一些网络服务如 QQ 拼音词库平台用户上传词库以便在其它设备上下载他们，正是对 I/O 的抽象让我不必直接和内核、网卡驱动等复杂的系统底层打交道，这种抽象带来的简化催生了整个软件生态的繁荣。随着我对 MFC 和 Win32 API 等窗口应用程序的接触，慢慢发现自己掉入一个纷繁复杂的世界，光是窗口句柄和各种事件处理就足以让我头大，还要面对一些：不规则窗体、透明窗体等产品设计需求，为什么技术越发展使用起来却越复杂了？

打开 Github 看看最高 Star 的项目，和 web gui 相关的最高 Star 项目撇开框架外，最多的是各种完整示例网站或组件库。完整的示例网站可以通过替换素材的方式，快速实现某个场景的 GUI 开发工作。组件库可以帮助前端工程师根据产品需求快速搭建 GUI，而不需要面对那么多复杂的 DOM、BOM 等编程接口。表面上 GUI 给用户带来了极大的便利，却给程序员带来上述的压力，让他们想通过 Ctrl C 和 Ctrl V 来解决，为什么？

因为，GUI 易用性背后隐藏了诸多让我惊叹的复杂度。在腾讯工作期间很多桌面应用程序开发过程中，我都会和设计师密切配合，从接到需求那一刻起我就缠着设计师一起探讨甚至一起设计。之所以如此，除了性格外向比较 Open 外，还有一个重要的因素是我意识到了 GUI 易用性背后隐藏的复杂度。拿我在 D2 上分享的 Silverlight QQ 为例，分享一下我在开发这个应用时面对的复杂度。

如图 1-3 中所示的 Silverlight QQ 是我从写服务器到 GUI 全链路端到端独立完成的项目，撇开服务器开发和 Silverlight 这个富媒体技术不谈，单说这个 GUI 的开发过程。这个设计是我和一家著名的香港设计事务所协力完成的，从 Wireframe 到 Proposal 的细节都是我一点点和他们敲定的，因此，小到图中的 Avatar、立体化的 Icon，大到窗口、Platform 切换好友群组等 UI 和交互细节，对我一个人开发造成的压力可想而知。

然而，这些压力中最大的问题是还原度，以往 I/O 编程中可读、可写等简单的状态荡然无存，取而代之的是各种状态以动画的视觉形式呈现时的弹性系数、阻尼系数、关键帧等。我无法把设计事务所提供的视频直接放在 GUI 里实现各种视觉效果（Apple 官网上有 H5 视频和动效结合的典范可以参考，但局限性很大），然而在设计领域很多概念又无法和 GUI 编程概念对齐，就像鸡同鸭讲，谁来翻译？

关于 Silverlight QQ 具体的细节可以从 Github 上https://github.com/d2forum/4th找到，这里就不再赘述了。我对 GUI 易用性背后复杂度的理解是：如图 1-4 以往程序的设计和开发都是由程序员自己完成的，所以设计意图和实现手段是统一的，然而在 GUI 领域里设计和开发分别由产品加设计和程序员分别完成的。

图 1-4 GUI 编程对比传统编程的差异

你可能会说：虽然完成工作的角色多了，但多沟通就好了。是的，这样说是没错，就像我在做 Silverlight QQ 时那样，除了充分沟通外，还有很多设计工具可以帮助设计和开发在代码层面沟通，比如现在 AfterEffect 预览并导出特效代码。但是，如果深入探究一下，就会发现一个严重的问题：事实上程序员在做设计，并且可能和产品、视觉和交互设计产生冲突，这个结论是我深入到布局、动效、动画的细节后发现的。

拿布局来说，让产品和设计师针对不同的分辨率出不同的设计方案是理想的，面对数量庞大的各种分辨率和各种挖孔屏带来的 Safe Area，产品和设计师无法穷举所有情况，问题就交到程序员手里，如何用 Media Query、弹性布局等技术手段去解决，尤其是解决过程中的细节如何处理？比如文本的折行、截断等问题。如果我拿着所有问题，一个个去找产品和设计师去确认解决的规则和方案，那我的价值是什么？只是把需求翻译成代码么？那用 imgcook.com 的 D2C 就够了要我做什么？看看国内知名的蚂蚁金服前端大牛玉伯老师是怎么解决该问题的，他在阿里集团第一个提出体验工程这个概念，并大刀阔斧的改革，把自己的部门从前端变成“体验技术部”。

我认为玉伯老师的解法是很高明的，这不仅仅是一个部门名称的变化，其变化的精髓在于诠释了前端工程师工作的本质：向用户体验负责。但是，这里有个问题：前端怎么向用户体验负责？在非 GUI 程序开发中，程序的设计和开发都是由程序员完成的，因此，程序员可以对这些由自己设计和开发的程序负责。在 GUI 程序开发中“向用户体验负责”就要求面向用户体验的程序设计，而设计的前提就是对问题的分析、理解和定义，下一篇文章会分享一下我对面向用户体验程序设计的一些理解和感悟。

我把面向用户体验的程序设计分为三个层次。第一层是从传统程序设计中继承的精确性、可用性和性能部分，这是完成高质量交付的基础。第二层是从协同产品和设计师工作的角度定义的，这部分主要是利用智能 UI 的能力对程序进行调控进而影响用户行为，借助正向的用户行为影响来提升用户体验。第三层是从技术的独立交付价值角度定义的，小到用技术手段适配不同分辨率、深色模式下各种视觉指引的辨识度优化等，大到 3D、AR/VR 等技术带来的全新交互体验。下面就分别介绍一下面向用户体验程序设计的三个层次。

面向用户体验程序设计的三个层次

我把面向用户体验的程序设计分为三个层次。第一层是从传统程序设计中继承的精确性、可用性和性能部分，这是完成高质量交付的基础。第二层是从协同产品和设计师工作的角度定义的，这部分主要是利用智能 UI 的能力对程序进行调控进而影响用户行为，借助正向的用户行为影响来提升用户体验。第三层是从技术的独立交付价值角度定义的，小到用技术手段适配不同分辨率、深色模式下各种视觉指引的辨识度优化等，大到 3D、AR/VR 等技术带来的全新交互体验。下面就分别介绍一下面向用户体验程序设计的三个层次。

▐  面向用户体验的高质量交付

在日常工作中我观察到这样一个事实：GUI 开发在软件工程视角下不完整，其缺失的部分是交付后调优过程。我在开发服务器的时候，除了将服务器部署到线上环境，还会对服务器功能精确性、可用性和性能优劣进行假设，根据这些假设精心设计一些日志打点和上报。有了对线上服务的观测、测量能力，我就可以针对观测到的事实和自己的假设进行比较，从中找到功能、可用性和性能的问题，并针对这些问题发 Patch 热更新或调整代码重新发布进行冷更新，然后重复上述过程，直到观测事实符合自己假设的预期，调优完成。

调优的过程和监控告警是有本质不同的，监控告警应该在调优完成后，用于防范那些我们难以假设或预期的线上异常。然而调优过程则是我们对功能精确性、可用性和性能是否合格的预期，以及这些预期在线上表现是否符合的检查和调整过程。而我观察到，今天的 GUI 开发中团队缺乏调优过程，开发、联调、提测、发布后就直接进入了监控告警状态。因此，我认为在谈面向用户体验的高质量交付设计前，先要保证面向软件工程的高质量交付。

面向用户体验的高质量交付设计是 GUI 程序设计的超集而非子集，我们要在保证面向软件工程的高质量交付基础上，定义一些并不包含在传统软件工程交付质量中的特殊部分。这些特殊部分到底特殊在哪里？通常谈到 GUI 程序设计，很容易在脑海里浮现出：MVC、MVVM、界面、事件、视觉树、逻辑树、业务逻辑等等，我想从客体的角度尝试诠释一下 GUI 程序设计在面向用户体验的视角下有什么不同？

以往谈到 GUI 程序设计，大部分是在谈论如何跟系统、容器、框架、工具和语言打交道，很少有谈跟用户打交道的部分。我猜想可能大家都认为这部分是产品和设计师的工作吧，但我不这样认为。GUI 程序构建了产品价值和用户价值连接的桥梁，不明白如何跟用户打交道，就无法把产品价值精确、可用和高性能的输送到用户那里产生用户价值。因此，在 GUI 程序设计时需要考虑的特殊部分就是：产品价值、用户价值和价值输送这三个因素。我们用字母 P、U、T 分别代表这三个因素，GUI 程序设计时面临的问题就是：，其含义是用户价值等于以价值输送情况为系数的产品价值。

以来考察我们的交付质量，可以知道 T 大于等于 1 时 P 乘以系数 T 后带来的用户价值 U 才是符合产品和设计师预期的，因此，面向用户体验的高质量交付设计的目标就是：假设 P 正确的前提下 。对于的部分放在后面两层讨论，这里着重讨论如何设计才能让。

关于 T 其实是 GUI 交付的部分 G，加上服务 S 和数据 D 这两个 G 承载的内容部分，就意味着 G 和 S 及 D 之间是相乘的关系，因为内容是有 G 进行呈现的。G 在呈现 S 及 D 的时候，需要从视觉（Version）和交互（Interactive）两个方面设计 ，视觉 V 的部分主要是布局、样式等决定 S 和 D 如何呈现，交互 I 的部分主要是交互点和交互路径共同构成对 S 和 D 的使用，V 有个特殊的部分指视觉指引为目的的装饰性元素和功能性元素，例如 icon、角标、挂件等。

因为，而，最后，所以最终 T 这项就是后面我们主要对这部分考察或的具体要求，这里先看的部分。假设 P 没有问题，其实隐含着也就是产品设计的产出物（GUI 开发的产品设计输入）PRD、Wireframe、设计稿、交互稿是没有问题的，那么 V 和 I 的具体要求就需要符合的约束，在以往的工作中我们称为设计走查部分，这部分属于产品设计要求而标准就是精确性。

除此之外，还有一块是工程质量部分，这部分是没有约束却和实际效果密切相关的部分，用于检查 GUI 程序部署到用户端并运行起来时的效果。部署就是把程序本身和程序相关的静态资源存储在用户端，主要是看存储空间和传输、存储速度。运行则是渲染、响应、执行、反馈的过程，主要看 CPU、内存、GPU、显存、I/O 等基础性能指标，还会看容器如浏览器引擎、脚本引擎、渲染引擎性能指标。为了让精确性的标准是比较直接清晰的，只要用去对照保证设计还原的精确性，而工程质量部分则稍微麻烦一些，要从基础性能和容器性能两部分看，甚至在引入 Hybrid、Reactnative、Weex 等技术后更复杂。我在 Chromium 官方博客上看到，由于浏览器内核和 V8 脚本引擎性能并不能保证用户使用时的性能，因此，Google 的工程师和开源社区探讨构建 RWP（Real World Performance），也就是真实世界的性能。由此可见，我们能够把 V 和 I 的具体约束用和 R 来表示，R 代表 RWP 可以如图 1-5 这样用真实手机进行录屏分析。

对 I 的部分可以模拟用户的操作，然后录屏对结果进行分析。如果操作是由产品设计的 Wireframe 所定义，应该包含操作的触发点和响应 frame，分析的对象正是这些响应 frame 的渲染效果和性能。还有一类特殊的 I 是应用程序状态变化产生的 UI 变化，包括应用程序根据宿主环境的输入产生的变化，比如：系统时钟的定时服务、位置传感器的 LBS 输入等。这一类特殊的 I 还包括服务端控制的应用程序变化，比如：登陆状态变化、聊天功能的好友数据同步变化等。总结一下，RWP 总体分为首屏性能和 N 屏性能，N 屏性能又分为用户操作、宿主环境输入、服务端控制三种情况，这四种情况就是我们需要去模拟的部分，通过模拟并录屏针对这四种情况在高端机、中端机、低端机上实际出现的 frame 进行分析评估。为了更贴近用户的视角，这里的评估又可以针对可视和可交互两个部分独立评估。

对于可视部分的评估之前文章在渲染视角里详细说过，这里就不再赘述了，只需要根据之前文章的介绍提取对应的指标评估即可。对于可交互部分，必须了解 DOM 树构建、DOM 节点事件监听、BOM 接口、JavaScript 事件处理程序的就绪状态，用就绪过程和耗时来评估可交互性能。有了可视和可交互两个部分的详细数据，就可以得出工程质量部分的 RWP 也就是变量 R 的分数。有了图片相似性检查等手段，就可以得出也就是设计走查的分数。最终，可以把这两个系数带入到中得到，因此可写作。

假设给用户的价值 U 和产品设计 P 是正确的，括号内的部分也就是 G 必须是大于 1 的，则需要以 V 和 I 作为地图，去找到所有的影响，根据前述内容对设计走查和工程质量部分进行 RWP 计算即可，但这里还有 S 和 D 两个部分应该如何计算和评估？

如果说视觉 V 和交互 I 是一个应用的骨架，那么服务 S 和数据 D 就是血液和肌肉，不论是工具型还是内容型，S 和 D 共同支撑了应用的实际效用。其实，S 和 D 背后都是元数据，为什么这么说？因为，S 是在服务端处理元数据，为什么这么说？因为，S 是在服务端处理而 D 不过是在客户端处理。比如登陆 S，将登陆凭证送至服务端进行鉴权，事实上就是在服务端对登陆凭证和存储凭证之间进行比对，一致则返回鉴权成功不一致则返回失败。再比如淘宝货架 D，将服务端返回的商品列表数据从 JSON 结构中提取出来、格式化并赋值在 DOM 元素对应属性值上。一旦赋值到 DOM 元素对应属性值上，就借助 V 呈现给用户，用户会因为 V 的视觉引导/刺激而产生 I 交互行为，应用程序继续根据 I 产生的在客户端以 D 或在服务端以 S 的形式进行处理再一次借助 V 呈现给用户响应，从而完成一次完整的呈现和交互过程，应用会在 V-I、I-V、V-I ……等这样的循环中无限持续下去直到用户退出关闭应用。由此，我们不难发现的重要性，不仅是在应用程序启动（相对的用户冷启动）时需要带来充分的价值 U 让用户有动力进入 I，同时，还要继续提升的有效性不断提升 U 进而让用户进入价值循环。的重要性具体在哪里？应该如何测量和评估？

图 1-6 G 的复杂性带来用户理解的成本

为了搞清楚的重要性以及测量评估方法，我们必须从应用本身说起。如图 1-6 所示，假设应用的 G 只有登陆，用户接收到的信息较简单，只有：用户名 + inputbox、密码 + inputbox、注册 + button、登陆 + button，然而，如果用户进入手淘的小黑盒新品频道，G 的信息变得异常复杂。

二十世纪七十年代，未来学家托夫勒用“信息过载”呼吁我们：信息的高速生产和传播会增加人们对噪声处理的成本。今天的应用在不断堆砌的过程中，让用户迷失在噪声里。本质上信息在今天呈现出和容器相分离的特性，我们所谓的“数字化”就是把存在于公交站牌、产品手册、商品吊牌等容器上的信息提取出来以数字化的方式承载。数字化之后，和容器分离的信息就可以被 UI 更丰富的展示，从而借助网页或 APP 在互联网上大规模传播。撇开传播不谈，就 UI 展示这些数字化信息的部分，我们能够清晰的考察在信息层面对用户的价值是什么？价值几何？

在考察的信息对用户的价值是什么前，我想介绍一下香农在信息论方面的一些观察和思考。香农原始的观点是期望通过对信息以熵为单位度量，进而在通讯工程传输信息的过程能够依据熵来考察编码效率和最大传输速率，从而能够用数学的方法找到一个衡量信道容量并逼近极限的传输方式。在我们对信息进行二进制编码的时候，假设对每个汉字都进行独立的编码，编码空间将有。但是，由于我们知道汉语常用字只有三千多个，国家标准 GB2312-80《信息交换用汉字编码字符集*基本集》就是根据使用频率制订的。一级字库为常用字，3755 个，二级字库为不常用字，3008 个，一、二级字库共有汉字 6763 个。一级字库的字，使用频率合计达 99.7%。即在现代汉语材料中的每一万个汉字中，这些字就会出现 9970 次以上，其余的所有汉字也不足 30 次。而最常用的 1000 个汉字，使用频率在 90% 以上。因此，如果在汉字编码的时候只对常用汉字进行单独编码，我们就可以把编码空间从缩小到或从而根据汉字出现的概率提升我们的编码效率。对于汉字外的信息编码时，可以根据编码空间的 cost 是得到，当系统是最优编码系统时，我们有所以，对于这个系统而言平均编码一个符号消耗的 bit 数为我们称其为概率分布 p 的熵。这里熵代表对符合概率分布 p 的符号系统进行无损编码时，平均编码一个符号需要的最小 bit 数。

从编码的角度去看考虑当 x 出现的概率越大则编码得到的 bit 数越小，可以这样理解：一个符号频繁出现则它带给我们的信息量比较小，所以，用较少的 bit 数就可以编码。除了上述汉字的例子外，我们思考两句话：明天太阳会从东边升起、明天会下雨，由于明天会下雨背后隐藏着各种可能性所以信息量更大，而“太阳明天会从东边升起”通俗点说就是一句废话所以信息量相对较小。因此，从信息量的角度香农提出：信息是对不确定性的消除。对不确定性消除的越多，获得的信息量就越大，因为“明天太阳会从东边升起”符合常识所以消除的不确定性几乎为 0 所以相较于第二句“明天会下雨”提供的信息量较小。如果把信息视为消除不确定性过程中引入的变化，那么信息的量就与随机事件的概率密切相关。设函数表示观测到随机事件发生所带来的的信息量，按照上面的思路推导有下面四个性质：

1. 概率越大的随机事件提供的信息里越小，概率越小的随机事件提供的信息量越大，即则
2. 概率为 1 的随机事件所提供的信息量为 0 因为没有消除任何不确定性，即则
3. 概率为 0 的随机事件所提供的信息量为，即则
4. 当两个独立的随机事件同时出现的时候，他们所提供的信息量为这两个时间各自信息量的和，即

根据上述性质可以得到函数是一个对数函数，即满足上述四个性质。

回到我们研究的 UI 问题里，如果以用户手机屏幕的一屏为单位，我们可以找到很多的被 V 直接静态显示或因为 I 的响应而动态显示，如果把这些看做一个随机系统，如果每个的信息量为则该系统所有的信息量的统计平均就是该系统的总体信息量，根据可知：

香农提出如果要对一个随机系统的信息总量（即信息熵）进行度量，那么用于度量的函数表达必须满足三个性质：

1. 连续性：当随机系统的概率分布发生微小变化时，随机系统的总体信息量不发生显著变化，变化前后是连续的。

2. 等概率单调增：当随机系统是在集合上等概率分布时，随着集合元素的个数增加，信息熵度量函数应该具有单调增的性质。

3. 可加性：随机系统的信息熵应该具有可加的性质，分两次对随机系统信息量观察和一次彻底观察得到的信息量相同。

由于上述性质的约束，对随机系统的这种定义不仅是合理的且是唯一的，有兴趣的读者可以查看原著的推导过程，这里就不赘述了。其实上述定义可以用一种更朴素的方法和联系起来。假设用户来到淘宝，进入聚划算频道，进入百亿补贴子频道，使用百亿补贴的浏览功能找到心仪的商品完成购买，回到公式中在用户通过上和的指引一步步明确，必须明确和的信息量非常小而是关键，营销信息、品类信息、商品的信息在层层消除用户的不确定性，从进入淘宝买东西到进入聚划算频道用实惠的价格买到好东西，最后到百亿补贴子频道看看限时抢购拼一下运气和手气抢个好东西。这就解释了为什么所见即所得会取得非常显著的优化效果，因为把某个百亿补贴的好东西放在入口，这个只能抢的好东西因为抢购时效不确定性更强，对于用户来说信息量就更大。但是，从信息编码的原理上看，由于如图 1-7 所示入口只能放 2 个商品，用户的选项变少则命中用户需求的概率又被极大降低，这就要求从用户加购、收藏、浏览等维度进行补偿。

图 1-7 所见即所得在聚划算和百亿补贴的应用情况

首先从编码的角度考察聚划算频道的构成，并针对首屏信息计算有效编码长度即的部分。根据图 1-8 所示，在聚划算频道首屏梳理出：工具栏、运营活动、子频道入口、频道心智运营区块、类目导航、Feeds 流、互动玩法入口这 7 个部分。

图 1-8 聚划算首屏信息架构梳理

假设用户打开了 100 次聚划算频道，在没有智能 UI 的优化前提下，上述 7 个部分里很多信息都是重复出现的，例如：聚划算、直播、搜索、猜你想买、百亿补贴、大牌补贴、15天价保、点此咨询、精选、健康、宅家、户外、会吃、筛选，对于重复使用 100 次聚划算频道的用户，这些不变的信息有效编码长度就很小，这也是为何这些信息会被前端直接 Hardcode 到代码里。因此，在 UI 开发中可以把 Hardcode 、配置下发等变化不频繁的信息遍历出来作为静态数据，借此区分服务端返回的动态数据。

静态数据的编码长度很短，由于在总的信息中占比很少这里暂时搁下看看动态数据部分。动态数据部分基本都围绕商品展开，除了互动玩法入口的“350星星”这个信息外。商品的信息主要由：主图、标题、卖点、权益、价格五个部分组成，这五个部分由图片、文本、数字三个数据类型（淘宝首页还会有业务/活动 icon 标），再加上商品的总量，这部分信息编码空间会非常大。尤其是业务在平台视角就会控制招同款商品的规模，来保障供给的多样性。此外，虽然商品和其信息出现的概率根据热销产品正态分布的态势，但因为商品价格不同，相同或相似的商品仍然需要占用独立的编码空间。所以，在理想状态下针对上述情况我们对的优化是希望编码空间更大的。从信息量的角度也比较容易理解和推导，如果两个商品相同、信息相同，那么重复出现的商品对消费者的信息量就会降低，如果价格、权益等信息不同，甚至是埋点描述不同，则带给消费者的信息量就会有明显的差异。如图 1-9 所示，同样是商品主图，由于左侧商品主图里包含：语言支持、游戏人数、游戏类型，对比右侧商品主图带给消费者的信息量就会更大。

图 1-9 商品主图信息量对比

对于图 1-9 右侧商品主图用户点击详情才能看到类似语言支持、游戏人数、游戏类型等信息，甚至有一些商家只放几张游戏截图，没有任何说明。从表象上看似乎这样会增加用户点击率（需要到详情获取有效信息），但实际上这种点击大概率是无效的，无效的操作多了势必会降低用户体验，而这背后就是的信息量出现问题，不足以支撑消费者正确决策是否要点击，从而造成无效的点击。

类似这样的例子还有很多，虽然无法一一例举但可以通过公式知道总体的信息量是多少，然后根据每一屏透出的信息量去做考察，再根据用户分群进一步借助智能 UI 个性化考察：增加或减少信息量对不同偏好的用户 UI 交互行为产生的影响是什么？最终，我们可以把公式中的 D 和 S 也就是用公式替换，从而考察在 P 正确的情况下，符合 U 的价值期望部分（用有效点击可以度量输入信息对用户的有效性），通过固定 V 和 I 就可以通过实验，用智能 UI 调控信息的透出找到 D^ 和 U 之间的关系是未来进行 UI 调控的基础。

虽然通过 UI 和交互以及服务和数据的优化，的情况下能够做出的高质量交付，但如何逼近 1 甚至部分超出做到 1.1、1.2、1.3……等，则需要我们面向用户体验进行持续优化并持续交付让，不断的优化、细化和个性化。下面就介绍一下如何进行 UI 的调控，从而做到不断的优化、细化和个性化。

▐  面向用户体验的 UI 调控

在前述内容的思考中经常面对一个疑问：内容/商品的透出是服务端算法决定的，UI 的调控能起到多大作用？这个问题就像产品是由 PD 定义的，前端交付的高质量对用户体验有多大影响？诚然，如果商品推荐没有透出某个商品，对商品信息表达的优化就无法生效。但是，另一方面当商品推荐透出某个商品的时候，如何展示商品信息？展示哪些字段？用什么样式展示？商品推荐是不关心的，这块儿基本是产品和设计确定的。而技术如果能把视角从产品和设计方案的实现转向交付物对用户行为的影响，技术就能从用户的视角下，独立推导并设计和持续交付，以提升用户体验的方案。诚然，回到最初的疑问上，内容/商品的推荐是第一层漏斗，如果这层漏斗有问题，也就是前文中的有问题，这时在 V 和 I 上进行 UI 调控的效果一定会有折损。由于本书不讨论推荐算法，姑且假设和 P 一样是最优的，在实际方案中针对性的设计实验中固定和 P 的方法，比如使用相同的和 V 测试不同 I 的表现，或使用相同的和 I 测试不同 V 的表现。

有了上述方法，你可能会问：具体应该怎么操作呢？我认为应该用分析、调控、反馈构成的循环来操作，通过分析提出问题和假设，通过调控进行实验，通过实验结果反馈检查分析提出的问题和假设，并根据事实和假设之间的偏差做出新的假设并进入新一轮循环。下面，我就依次分享一下对分析、调控、反馈可能存在的方案和未来的发展方向。

对于分析来说，现在的分析是基于产品经验和产品经理个人对用户需求理解的基础上衍生出来的，因为在基础指标和指标应用之间存在一条无法逾越的鸿沟。举例来说，在基础指标里的点击率、浏览深度、停留时长……等，并不能说明问题出在哪里。点击率低不好，这就是一句废话，真正有用的问题是：为什么点击率不好？点击率不好的问题出在哪里？这就变成了一个复杂的问题，尽管我们有反事实、归因分析等方法，但事实上我们都清楚这个问题没有那么简单。

面对未知和不确定性很大的情况，我们可以从最大熵原理中获得一些启发。举个例子，如果我把一枚骰子抛到空中，骰子落地的时候停留在每一面的概率应该相等，因此得到 1~6 任意数字的概率为对么？由于我们对骰子的情况一无所知，只知道骰子是正常的、抛投的方式是正常的，在这些“约束条件”下每一点的出现是等概率事件。可以把“约束条件”描述为：满足这种情况就是最大熵原理，即满足已知约束条件不做任何假设则每个事件都应该是等概率的：

如果你根据最大熵原理去考察因为图 1-8 聚划算首屏信息架构梳理中，假设我们想对布局进行调控，每个部分被用户点击的概率是，但此时 PD 告诉你，根据她的经验运营活动和Feeds 点击的概率是，因为 PD 输入的信息你得到了新的约束条件，这时用户的点击概率就会发生变化：

约束条件：

满足最大熵原理的概率：

还记得我们在上一节信息量的部分讲过的公式么？

我们再换个视角用最大熵原理看这个随机系统的信息量问题。假设我们有一枚质地均匀的硬币，抛一次，正面和背面朝上的概率根据最大熵原理均为那么他总共的信息熵就是如果以 2 为底计算的话就是 1 bit 信息熵：

既然香农给出了信息上的定义，那么根据公式计算能否得到 0.5 这个概率是系统的熵最大呢？换言之等概率让系统的熵最大是不是真的？为了证明这个结论，我们假设抛硬币出现正面的概率是那么出现背面的概率就是，这里其实包含了约束条件，因为隐含了两者总和为 1 这个事实。

接下来要找到一个让最大也就是熵最大，也就是求这个函数的极值的解：

我们也可以把这个问题推广到之前提到的问题：7 个部分的点击事件每个发生的概率为根据最大熵原理概率的总和为 1 则为：

其中约束条件为。

为了求出满足最大熵的事件概率可以构造拉格朗日（Lagrangian）函数，把需要满足的约束条件加到后，，然后求这个函数的极限也就是求导其等于零：

求解得到的具有未知参数（来自约束项），利用约束条进一步求解：

最终推导出含有个事件的系统熵最大时，事件的概率必然满足等概率。符合最大熵原理的情况下，一个硬币抛向空中正反面朝上的概率为，一个骰子每一个点数出现的概率为，聚划算首页 7 个部分点击事件的概率相等为。我们再把 PD 根据她的经验认为 这个新的约束条件带入：

约束条件：

由于系统包含了各个约束条件，所以添加两项。对概率求偏导等于 0 ，求出满足的和固定求：

根据上式可知：

代入寻找使最大的：

求：

最后可以解出聚划算首页 7 个部分被点击的概率：

我们可以简单的验证一下：

撇开这些公式和推导不谈，让我们闭上眼睛回忆一下刚才看到的内容，你是否能从脑海中浮现一幅画面：一个不确定、未知的复杂点击率问题慢慢收敛到一个确定的边界 “1” 之内，PD 经验的帮助或我们通过日志打点用户行为数据统计结果等约束条件的提出，在这个 “1” 中出现了 “2” 一部分仍然是未知的等概率分布，另一部分是 PD 的经验或数据中归纳的经验带来的判断“”，接着你用线上实际数据去验证这个判断是否正确，最后你的脑海逐渐清晰呈现出智能 UI 上的调控、UI 的变化其实是你不断添加的约束条件，你让位置的等概率分布的部分变得越来越小，你对于用户如何使用你开发的 UI 越来越了解，用户点击的实际数据情况愈加符合你经验的判断。

综上所述，再回到公式中，通常情况我们都是根据 PD 的判断和定义在进行实现，而 PD 的判断是抽象和不可见的经验、理解等产品思路构成，如果能够通过最大熵原理和智能 UI 的调控实验能力将其具象化，前端技术就能逐步参与到真正的产品定义中（最起码是调控），基于数据、事实去产生自己独立的判断：什么样的能够给带来用户价值。这一点非常重要，因为这能够融入我们的视角来丰富的内涵。

▐  面向用户体验的创新设计

图 1-12 CoreML 肢体和动作识别（摘录自苹果开发者网站 developer.apple.com）

上述三个例子无一例外都使用到智能化对交互进行创新，这些超出用户期待的创新设计改变了什么？毋庸置疑，这些创新设计改变了人和设备交互的方式，它们逐渐打破了传统“控件”操作软件的局限性，把用户带入一个全新的数字化世界，甚至把用户也人格化和数字化重生在这个无限的世界中。当然，这些创新的设计也对技术研发带来了全新的挑战，传统 GUI 开发所具备的技能将不再适用，操作界面从 2D 向 3D 拓展，操作方式从控件向智能化演变，以往沉淀的经验、训练的技能都会受到严峻挑战，这就是第二曲线和全新技术变革到来的信号。下面，分享一下我对未来变革的预测和理解。

随着先进制程让芯片的 PPA 逼近物理极限，智能化的 AI 加速计算能力大大降低了通用处理器的压力，从而使前述的智能化应用成为可能。但是，这些应用还偏向于局部微创新，人类和数字世界之间还存在着巨大的鸿沟，这些创新更像是无人机飞过去看了一眼却因为续航不足而匆匆返航，那么跨越鸿沟的桥梁在哪里？我认为，只有把数字世界到现实世界和现实世界到数字世界双向、彻底的打通，才能迎来真正的技术变革。

我认为要把数字世界和现实世界相融合，同时现实世界可以直接迈入数字世界，并且以游戏手柄震动般带来物理反馈，或者通过脑机接口用数字信号让大脑以为接收到无力反馈，这场技术变革才能改变用户体验。这里最大的改变就是让数字世界从“虚拟”成为现实，因为虚拟带来的最大体验折损就是真实感。真实感能够让用户沉浸其中，而不会因为不真实而被打断和跳脱当前场景。同时，真实感能够让用户不必学习和训练，现实世界里怎么做还怎么做，交互体验就会变得更加自然、直接和简单。

光有真实感肯定是不够的，因为突破现实世界的局限性是人们看电影、玩游戏的重要动力，比如一个用户在数字世界里能够像黑客帝国里的尼奥（Neo，真名为托马斯·安德森 Thomas A. Anderson）从地面一下跳到楼顶，起跳后飞行的过程要让现实世界的用户保持悬空，落到楼顶还要有建筑物施加在用户脚上的反作用力，完全真实的反馈人体肯定是无法承受的，反馈太弱又会破坏真实感。这里面还有很多的技术问题需要研究和突破，就像 Adobe 用 Flash 给 Web 带来富媒体应用，前文中 Silverlight 技术刚出来我用 3D 场景、任务和交互做的 SilverlightQQ 一样，新技术会带来很多问题，但技术变革也留下了巨大的创造全新用户体验的空间。如图 1-13 所示，我认为至少应该关注机器智能、机器知觉、区块链、数据传输、边缘计算、用户交互、扩展显示和 IoT 这八个领域的技术，在这些技术完善、成熟前尽早的学习和理解他们对用户体验带来的可能性，对领域学术研究进展通过国际顶级学术会议的论文和综述持续学习，才能更敏锐的发现技术变革带来的用户体验创新机遇。

图 1-13 未来影响用户体验的技术前瞻梳理

最后，还有一个部分没有讲到，UI 智能化如何降低用户操作的频率和成本？由于涉及的内容较多，这里单开一节详细介绍其中的细节。

2019 年 8 月 15 日我独自造访美国山景城 Google 总部，除了演示 imgcook.com 产品介绍我们在 Design To Code 的工作，还促成了 Tensorflow 团队和我们的战略合作。除了优美的环境和热情的谷歌工程师，我还感受到了谷歌的强大技术产品能力。回酒店的路上我用 Lyft 叫了个车，一路上司机用 Google 助理全程语音完成了：阅读信息、回复信息、预定餐厅、给家里留言等事项，让我猛然意识到行业标准化以及英语语音识别、理解的强大是国内使用助手类产品无法比拟的。Google 助理（英語：Google Assistant)是 Google 开发的個人助理 APP，于2016年5月在Google I/O发布。与Google即时不同，Google助理可以参与双向对话，协助用户完成很多事务。

这次经历让我对智能 UI 有了一些全新的理解和认识，不仅仅是 UI 样式和信息表达的智能化，要穿透 UI 和信息去感知和理解用户的意图，用智能化手段协助用户实现其意图从而做到真正的 AI User Interface。把用户和数字世界以及通过数字世界和物理世界穿越时空的连接，实际上用户操作的对象会从应用程序变成现实世界的服务。最近今日头条的人文清华发布对清华经济学家白重恩的访谈，其中谈到美国服务业的发达。用户通过应用程序操作现实世界的服务，不仅需要互联网提供穿越时空的连接能力，服务本身的可操作性也是重要的问题和障碍。基于服务业自身的特点，服务本身是复杂多样的，而且服务本身的标准化和规范化程度也进一步限制了可操作性。服务业与工业、农业不同，它所提供的产品就是服务，这种服务具有无形性、非储存性、同时性和主动性。服务业的这“四性”特征，决定了服务业必须把标准化作为前提和基础。因为标准是对服务各环节和全过程一系列特征作出的明确和具体的定量的技术规定。如果没有有效的服务标准，服务行为就无法数字化，服务行为无法数字化就难以用互联网技术为其构建声明式的操作界面，没有声明式的操作界面就会造成技术研发和对接成本高难以规模化，难以规模化就无法为用户提供充分的选择来帮助用户实现其意图。

如果深入考察这个问题，你会发现因为没有标准而引发的问题不仅仅在服务业，内容的标准化产生了 RSS 订阅能力，应用程序调用的标准化产生了唤端能力，iOS 还在应用程序的互操作性上制定标准，用 Siri 完成对应用背后提供的服务进行操作，比如阅读微信消息、打开健康码等。所以，实现 UI 智能化的前提是有脱离用户的服务操作能力和程序操作能力等，而这些能力就需要有标准来支持以提供规范的开放性降低研发和接入成本，从而实现规模化以实现用户意图。

对服务各环节和全过程一系列特征作出的明确和具体的定量的技术规定，就需要在技术规定之上进行规范的调用，从而替代用户做很多额外和繁琐的工作。拿打电话为例，其实本质上是两台机器之间用数字信号在技术规定之上互相接收和发送数据，用户打电话的过程因为标准化加持而被机器自动代理完成了。把这个例子换成 Google 助理帮助用户订座位会发生什么？其实过程本质上是一样的，用户告诉 Google 助理想要订个餐厅的位置，Google 助理会根据用户常订的餐厅询问是否订同一家，用户拒绝的话 Google 助理会询问用户想要订什么风格的餐厅，用户说要法式餐厅，Google 助理就会根据标准接入的订座位服务对餐厅进行查询，选定几个法式餐厅推荐给用户，用户决定离家最近或评价最高的餐厅，Google 助理就会根据服务的标准要求用户提供：时间、用餐人数等信息尝试调用服务来锁定座位，一旦锁定成功则通知用户，这个发送信息、请求锁定和锁定的过程都是由应用程序和餐厅管理系统之间交互完成，不仅不需要用户参与而且仅需要数百毫秒就可以完成，节约用户的时间也提升了餐厅的效率。

虽然订餐厅服务从海量用户和餐饮行业宏观上看意义和价值很大，但从用户个体微观视角下价值和意义有限，毕竟不是高频操作，那么有哪些高频操作可以用这种方式优化呢？举个例子，最近在疫情之下我住的浙江省杭州市拱墅区被管控了，因为影响上班和出行，我每天都会打开今日头条 APP，点击抗疫的 Tab，焦急的查找和杭州以及拱墅区相关的疫情信息和动态。我就在想，如果有个类似 Google 助理的 AI 帮助我打开头条查阅疫情信息，并且在疫情动态发生变化时把最新消息以语音的方式通知我，我就不必花费时间和精力在这件事儿上每天可以节约很多时间。类似的情况还有很多，人们生活在社会中总是因为环境或自身主动或被动的变化，而打破或产生习惯性的交互行为，而这些习惯性的交互行为大多是用户的高频操作，而高频操作的优化对用户个体微观视角下价值和意义更大。

针对习惯性的交互行为优化用户高频操作，大体上应用程序有两个技术路线，一种是自动化另一种是智能化。自动化可以追溯到 Windows 上的批处理、Fireworks 和 Photoshop 提供的自动化以及 Excel 和 游戏中的宏命令，由用户借助应用程序开放的能力编排触发条件、流程和输入输出。移动端上类似的自动化能力前文已就 Apple 的快捷指令做了详细介绍，通过操作系统和应用程序开放的能力，在疫情之下把展示绿码变成一键操作，在抖音和 B 站进行视频一键下载等，尤其是借助 Safari 浏览器对应用程序分享、在浏览器中打开等能力巧妙实现一些繁琐却高频的用户操作。另一种是智能化技术路线，对比服务端计算端上计算有隐私保护的巨大优势，用户习惯的高频操作本就需要高频的监控和识别用户行为，所以在端上计算也就是端智能技术的帮助下突破隐私问题，才能更好的监控、识别和理解用户行为从而了解用户的习惯。比如我每天坐地铁上下班，iOS 借助 iPhone 的传感器对我的位置进行监控，辅之以时间、打开应用的使用路径，智能叠放就能够准确在我下班进入地铁站时首屏显示一个大大的支付宝出行按钮，只要点击一下就可以打开二维码扫码进站。类似的应用场景还有很多，只要能通过各种实时数据进行训练把其中的模式抽象为“场景”，再根据用户在特定场景下的行为，就能够精确判断用户的习惯性高频操作并简化之。

你可能会想到一个问题：即便是基于端智能简化用户的习惯性高频操作，其本质上和自动化没有太大区别呀？是的，端智能只是智能生成并推荐了自动化操作而已，虽然有智能的成分，还是那句话：蜡烛怎么改进也无法变成灯泡。之所以蜡烛不能变成灯泡，因为前者依赖化学能后者依赖电能，他们的技术基础是完全不同的。基于端智能简化用户习惯性高频操作的技术基础是什么？还是自动化和依赖于应用程序有限开放的功能，遇到一些“自我”的 APP 迫使用户必须打开应用使用其功能，自动化就显得束手无策了。我认为未来应该把 Google 助手的技术路线作为基础，思考如何才能用一个数字化和智能化的助手替代用户做一些繁琐的事情，从而让用户使用终端的时候更加高效。

记得 2014 年 4 月刚接手溜溜网电子商务有限公司任 CEO 的时候有 5 个秘书，我并没有贸然把他们精简，而是悉心观察了一段时间，去了解他们每个人的工作内容。由于当时在做跨境电商，有一个秘书专门负责烟酒等经营许可，一个秘书负责和清关、退税等相关事务，一个秘书负责政府关系包括争取补贴和扶持等，一个秘书负责日常行政事务、日程安排和司机的管理，一个秘书负责管理线下网购机的铺点商务合作及合同法务。一个不到三百人的公司，却因为当时公司的经营模式和业务性质有太多琐事需要处理，如果不能把问题进行过滤和自主消化，我将成为公司发展的瓶颈。虽然后来通过对管理层汰换和放权解决了很多问题并精简到一个秘书，但之前的琐事并没有消失，而是由我的下属承担了。所以，在一个结构性复杂的系统中，复杂度不会消失只会转移，在腾讯做架构的时候就对此有深刻理解。因此，在面对结构性复杂的系统问题时，要想办法把复杂度转移到合理可控的区域。对于用户使用移动终端来说，一样是结构性复杂的。从移动操作系统到移动应用，由于商业和市场考量只能围绕通用性做妥协，而不会针对个体做深度的个性化，这样体验虽然能极致化但成本太高。比如在拱墅区爆发疫情的期间，我每天都要打开今日头条、点击抗疫 tab、滑动到杭州疫情并点击，然后查找杭州疫情的动态，每天早晚各一次并期待着有好消息让我解除居家吃方便面的苦日子。在这个动态变化的世界中围绕动态变化的我们，习惯性的高频操作也是不断变化的，如果助手 APP 能够像秘书一样理解世界、理解我、理解我面对的问题，就能够在我面对这种结构性复杂的局面时提供真正有效的协助。

助手 APP 的效用和其理解的能力成正比，理解和端智能的能力成正比，端智能的能力和模型算法的能力及其训练使用的用户数据量成正比，可用的用户数据量和对用户隐私保护的能力成正比，模型算法能力和端上算力成正比，所以最终影响助手 APP 效用的关键是隐私保护和端上算力。有了隐私和算力的保障，应该怎样去构建一个助手 APP 去协助用户？我认为应该从人的需求出发，众所周知的马斯洛模型可以提供良好的指导。马斯洛的需求层次结构是心理学中的激励理论，他认为人的需求可以建模成五级模型，通常用金字塔形式表述，自底向上把需求分别为：生理、安全、社交需要、尊重和自我实现。下面我们进行一下类比，看看在互联网和数字世界中的人类需求对助手 APP 的要求是什么？互联网和数字世界在生理、安全给人类带来的最大价值是信息，今天获取信息已经像吃饭、睡觉一样成为生理需求的一部分，而安全则是在信息获取中的特殊和紧急部分，就像疫情之下的我需要疫情动态信息来保证出行安全。相对于生理和安全的简单需求、我把社交需要、尊重和自我实现归类为复杂需求，划分的依据是生理和安全的需求更加直接和易于识别、获取、理解、分析和供给。因此，做好生理和安全的简单需求是做好助手 APP 并提供有效协助的第一步。

有了生理和安全的有效协助，我们的助手 APP 就会获取协助对象的信任，这一点非常重要。有了信任的基础，助手 APP 在必要时提醒用户给家人打个电话联络一下感情，才不会让其觉得突兀，反而会让用户愈发觉得助手 APP 是有温度和感情的，而不是个冷冰冰的 Robot。从熟人社交（如家人）开始分界，随着愈发向陌生人社交、尊重和自我实现迈进，用户本地和个人的信息愈发显得不足，助手 APP 需要更多外部的信息输入和对外部常识、知识的理解，才能够有效协助用户解决这些高层次复杂需求。不管怎么说，有了信任的基础，用户就会像给词典应用或输入法添加词库一样自然的接受给助手 APP 添加外部信息和尝试、知识。（这些外部数据的透明和安全依然非常重要）

当然，解决用户高层次复杂需求时，外部输入只是一部分，另一部分是助手 APP 会逐渐人格化。在 Google 助理的例子中，其在订餐厅座位中实际成为了用户的代理，订座实际是用户和餐厅之间签订的契约，Google 助理代表用户承诺在某个时间去餐厅就餐，而餐厅为用户留下其选定的座位。回到我们的助手 APP，代替用户去回短信、处理邮件、阅读新闻并形成摘要简报、在纪念日订鲜花、安排日程订机票、约出租车等等，助手 APP 依据价格、耗时等维度设计解决方案，让用户进行选择和确认，并将执行结果及时反馈。随着时间推移，端智能学习用户的偏好从而更懂用户，需要选择和确认的频率和内容逐渐减少，让用户觉得助手 APP 就像一个能干的私人秘书。

一旦我们能够设计开发出像能干的私人秘书一般的助手 APP，用户的终端设备也会因为交互的改变而发生巨大的变化。为什么交互会改变？因为用户不必再和冷冰冰的机器和 UI 打交道了。用户会和自己的“私人秘书”助手 APP 进行交互，而助手 APP 又是人格化的，所以用户可以用更加自然的语言甚至眼神来跟助手 APP 交流。此外，由于助手 APP 本质上是应用程序，所以其跟数字世界打交道的方式会更加直接和高效，不存在把二进制数据用协议解析成文本、图片、音频、视频等等，直接用二进制进行交互。由于直接和高效的交互，用户终端设备的计算消耗会下降，除了不需要对数据进行解析处理外，省去了渲染 UI 、监听用户输入、处理用户输入、响应输出等过程，这对于用户终端设备的小型化和可穿戴是极大的利好。

综上所述，UI 智能化会朝着没有 UI 的方向演进，应用会向着服务化和二进制输入输出演进，移动操作系统会进化为只有一个 APP ——用户的私人智能体，其它 APP 被服务化并和该智能体进行二进制交互，而用户则会回归自然、社会和生活。未来，大家可能只佩戴眼镜或耳机就可以完成今天手机上的大部分功能。

团队介绍

我们是大淘宝技术前台技术团队。大淘宝技术，一支致力于成为全球最懂商业的技术创新团队，旗下包含淘宝技术、天猫技术等团队和业务，是一支是具有商业和技术双重基因的螺旋体。

我们在 「杭州阿里巴巴西溪园区」 办公，
我们的定位是「用诗人的浪漫和科学家的严谨打造的极致消费者体验」，
我们的使命是前端智能让业务创新更高效，从而实现让天下没有难做的生意。