前面通过两篇文章《人工智能的发展和定义》和《面向用户的人工智能系统底层设计》介绍了人工智能的基础和对未来人工智能系统底层设计的思考。对于设计师来说，我们更关注的是面向用户的设计，这篇文章更多讲述的是上层应用的交互设计。在人工智能时代下，交互设计会发生颠覆性的变化，主要为信息架构的改变以及有更多新型组件的出现。

信息架构

要说信息架构(Information Architecture)，首先要提及图书馆，因为图书馆应该是最早能体现出信息架构的设计。当不同领域的书籍多到人类无法第一时间找到相关信息时，为了提高查找效率，人类开始给书籍添加索引，分门别类，到后面按区域摆放不同内容的书籍，即使是毫无经验的人在图书馆引导和图书管理员的帮助下也能迅速找到相关资料。

信息架构最早由美国建筑师Richard Saul Wurman在1976年提出。面对当代社会信息的不断增长和爆炸，Richard认为信息需要一个架构，一个系统来合理设计，创造了一个全新的术语——信息架构。

GUI和HTML的出现，信息架构得以广泛应用，同时也衍生出一个新的术语——页面(Page)。在GUI时代，信息架构主要由页面和流程决定。由于信息的展现必须由页面承载，而页面承载的信息应该是有限的，所以设计者需要将信息合理放入页面里。

假设总信息和页面内容的信息是固定的，那么流程也是固定的；反之亦然，假设页面信息是固定的，在固定的流程上增加一个可以扩展信息的聚合页面，那么总信息是可以无限的。当页面和流程设计被固定时，信息架构也是固定的。

在海量信息面前，固定的信息架构有助于人类记忆使用路径，降低寻找信息成本。当海量信息不断指数增长，功能变得越来越多，产品需要更多的页面来承载。更多页面会导致产品架构的层级和流程变得更复杂，也使得用户的使用成本不断增加，这并不是一件好事。

每个人的思考模式不是固定的，为了解决大部分用户需求而设计的信息架构可以帮助到用户，同时也限制了用户的思考。为了解决这个问题，信息架构需要一个优秀的导航设计来引导用户使用和随处浏览，如下图 ：

为了方便用户随心所欲地挖掘更多信息，搜索是一条捷径。搜索可以让用户便捷挖掘和随时切换需要寻找的内容。

由于手机小屏幕的限制，为了展现更多内容，导航的功能和展现被削减，主要依赖标签式、抽屉式、列表式等导航模式以及每个子页面的返回按钮。如果产品架构层级过深，会导致返回步骤过长，如果用户要从一条路径跳到另外一条路径，步骤极其繁琐。

在页面里，不提供随时跳到另外一个页面的功能是完全可以理解的，因为这个功能在展现上就很难设计，而且可能会使稳定的信息架构变紊乱。但是，这个功能可以降低用户的操作成本以及更符合人的思维模式。

为了实现这个功能，让用户自行搜索信息框架或许是一个不错的选择。相对于成本很高的文字输入，人工智能下的语音输入是目前最佳的解决方案，语音助手的本质也是利用语音进行搜索。语音助手与信息架构的结合并不是一个全新的模式。iOS的Siri可以打开手机应用以及部分苹果官方产品的功能，例如在Siri模式下说出“打开秒表”可以直接打开时钟APP下的秒表页面；说出“打开显示与亮度”可以直接定位到显示与亮页面。可惜的是，目前其他厂商产品的信息架构并没有和语音助手进行深度整合，例如在Siri模式下说出“打开微信朋友圈”不能打开微信朋友圈，主要原因是目前语音助手如Siri，Google Now等没有提供相关API给第三方应用，语音助手主要以特定关键词触发功能或者发起网页搜索，功能非常局限。

对于iOS 10，Siri API仅支持六类应用程序：打车，通讯，照片搜索（在特定应用中寻找照片和视频），支付（如“用SquareCash’给约翰转账100美元”），网络电话，锻炼，体验后发现功能也非常简单。

语音助手提供搜索第三方应用信息架构将极大提高用户的效率，例如在看网易新闻时唤醒Siri说“打开微信朋友圈”可以立即打开微信朋友圈，比传统操作快捷很多。仅需要对系统和应用层面进行小成本的修改即可实现该功能，改动如下：

1. 功能/页面增加新的标识/属性即可被系统语音助手搜索，本质上也是一种Deep Link。为了降低用户的记忆成本，该功能/页面应该是重要的，常用的，唯一的，例如可以通过Siri语音输入“打开微信薛志荣”、“打开微信朋友圈”直接到达相关页面，而新闻、购物等详情页、聚合页不应该添加该标识/属性。
2. 被语音助手调起的页面可以考虑将返回按钮改为回首页。由于固定的信息架构使每个页面都确定上一级页面是什么，流程符合用户心理预期的话需要做到“从哪里回那里去”，但语音调起的功能/页面，对于用户来说上一级页面是哪里无关紧要，可以直接将返回上一页改为返回首页，也方便用户继续使用该应用。
3. 被语音助手调起的页面有办法直接回到上一个应用/页面。例如在iOS中调起另外一个应用时，点击屏幕左上角可以回到原应用；同理，当用户在与微信好友薛志荣聊天时，使用语音助手切换到朋友圈时，点击左上角回到薛志荣的聊天页面。这样可以尽量避免打断用户的流程。

Deep Link，简单点说就是你在手机上点击一个链接之后，可以直接链接到app内部的某个页面，而不是app正常打开时显示的首页。

以上3点以图表示如下：

人工智能的成熟使语音助手得以快速发展，语音助手与产品信息架构的整合将使每一个功能都可以被迅速访问，产品入口不再是首页，语音助手给沉重的产品信息架构赋予了活力和流动性。该模式能更好地满足用户随心所欲的需求，也更好地提高了用户的使用效率。

流的设计

移动端产品主要分为内容(资讯、视频、音乐等等)、工具(闹钟、笔记、地图等等)、社交(聊天)和游戏四个方向。通过不同方向的结合可以孵化出不同的产品，人工智能会为这些产品带来怎样的变化？

1. 人工智能使推荐系统的准确度大幅度提高，用户发现内容的成本降低，产品不再需要复杂的架构来承载不同内容。
2. 人工智能可以承担更多复杂操作，工具的操作成本降低，使用流程也会随之减少，一款产品只承担一个工具不再行得通，除非有靠山，例如操作系统。往年iOS和Android的更新都会添加一些新的工具功能，加上Siri或者Google now语音指令，以及负一屏的信息聚合页面，可以使工具产品操作起来更方便。
3. 对话式的聊天已经是最扁平的结构，游戏因复杂而有趣，所以人工智能不能也不应该使它们简单化，但由它驱动的VR和AR会为社交和游戏产品带来新的玩法和机遇，不过不在本次讨论中。

人工智能的驱动使内容和工具型产品的信息架构变得更加扁平，加上在不同场景触发不同功能，有可能实现“每个功能/页面都可能成为用户第一时间触达的功能/页面”，这意味着每个页面都有可能成为首页，都是信息架构的顶部，这需要产品的信息架构有很强的兼容性和扩展性。

拥有高兼容性和扩展性的模式莫过于FEED和IM，这两种结构有以下特点：

1. 它们具有流的性质，结构扁平，内容可以无限延伸；
2. 它们都用样式相同的空容器，例如FEED的列表或者卡片，IM的气泡；
3. 空容器可以承载各式各样的媒体，包括文字、图片、音频和视频。

FEED和IM的区别是：是否主动给予信息反馈。FEED通过采集用户数据，将用户感兴趣的信息主动推荐给用户，在人工智能时代下它更适合用在内容型产品上。IM通过对话交流的形式给出问题或指令，对方根据相关内容给予反馈；在人工智能时代下它更适合用在简化流程以及工具型产品上。

既然固定内容的概念被打破，页面可以无限延伸，为了保证结构稳定和方便管理，内容和功能需要被模块化。iOS和Android在几年前已采用了首页左滑进入系统FEED的设计，不同产品用卡片的形式承载。小米MIUI9的信息助手突破了产品间的壁垒，在负一屏中将不同应用中的同类别信息整理聚合，比如收藏、支出、快递、行程、日程等，想查找使用这些信息时，无需进入不同应用查找，在信息助手中就能快捷查看和使用。

以上三种信息流都采用了模块化设计，模块化设计可以借鉴原子设计的概念。原子设计由原子、分子、生物体、模板和页面共同协作以创造出更有效的用户界面系统的一种设计方法，关于更多原子设计请看下文的推荐阅读。

上文提到，语音助手可以触达每个产品的常用甚至所有功能有助于提高用户的使用效率；全局性的人工智能助手有助于整合信息自我学习提供更多帮助，所以未来我们后续的产品需要在人工智能助手的基础上进行设计。人工智能助手包括了可以被随时唤醒的语音助手，例如Siri，它可以语音对话和提供信息的展示；以及包括了操作系统层面的FEED，例如MIUI9的信息助手，它可以主动展示相关内容和入口。

在设计产品请关注以下几点：

1.为了方便用户使用语音唤醒功能，产品功能应该是可以瞬间被理解的，以及唤醒词是方便记忆和开口的，例如可以映射到常用或者真实生活中的词语；切勿使用使用户难以开口的唤醒词；同时考虑唤醒词的兼容性问题，例如不同方言有着不同叫法。

举例：“打开微信朋友圈”完全没有问题，但“打开微信我”就非常有问题，首先意思完全看不懂，其次用户不会第一时间想到。钱包在粤语里叫做“银包”，意思相同的词语应该可以相互映射。

2.聚合不同功能的页面设计是为了方便管理和发现入口，但本身对用户来说没有太大意义。后续请减少让用户费神思考和记忆的聚合页面，这样可以避免被语音助手或系统FEED唤醒时，展示的全是功能入口。#除非这页面便于用户理解以及里面的功能非常重要#

举例：微信第三个Tab承载着不同功能，用户可能知道“朋友圈”，“摇一摇”，但可能想不到这个聚合页面叫“发现”，因为“发现”这动词太抽象，用户难以第一时间想到。用户想到“钱包”这词更多联想到的是真实世界里装钱的那个钱包，但微信的钱包功能包括了各种服务金融功能，不符合用户第一时间下的心理预期。

3.不同设计对象请考虑模块化设计，尽可能采用不同入口和页面管理设计对象，方便用户唤醒设计对象。

例子：设计对象有可能是一个功能；也有可能是通讯录中的一个名字，他们属性和功能相同，但用户的记忆对象不同。

4.常用功能允许被系统FEED集成，方便用户第一时间使用。系统FEED也会相应提供入口打开相关产品。

5.考虑避免常用功能与其他功能的耦合，降低系统FEED的结构复杂性和操作成本。

例子：在微信朋友圈可以进入朋友的详细资料并进行聊天，朋友圈和聊天两个常用功能可以不断循环，耦合紧密会导致信息架构的复杂。从产品和用户角度设计完全没有问题，但不符合FEED的轻量结构。第四点在FEED内提供产品入口是为了在完全分隔功能的情况下做的体验补偿。

6.具有操作性的功能例如设置闹钟、查看天气、购买机票等需要考虑页面的信息展示和操作流程，也需要考虑语音输入的操作流程，两者的操作步骤在用户认知上需要统一。若做不到，请提供相应场景下的合理流程。

解释：眼睛接收信息时可以随处浏览，它具有xyz和时间四个维度；耳朵接收信息时只有时间这个维度，这会导致同时接收或者筛选的信息量具有很大差异。同理，这也是为什么语音识别发生错误时，用语音修正的成本远比用键盘修正文字错误大。

1、2、4和6这四点更多考虑的是用户在使用语音或打开APP操作APP时可能会产生不同的心理预期，所以需要保证设计对象在这两种操作上的一致性。2、3和5这三点是从模块化的角度来考虑，有助于减少功能的耦合，降低信息架构的复杂程度。

新型API和组件

为了保证人工智能底层数据的一致性和完整性，第二章提及的数据仓库需要为第三方应用提供身份信息、健康数据、兴趣爱好、工作信息、财产数据、信用度、消费信息、社交圈子、活动范围9项API服务。获得用户授权后，第三方应用可以得到用户特征并向数据仓库保存用户数据。人工智能也会提供更多功能给第三方应用，例如摄像模块、语音模块、身份验证模块、支付模块等组件，提高用户体验的同时也降低了产品的开发成本。

API

上篇文章提及的数据仓库和用户特征如下：

1. 身份信息：名字、性别、年龄、家乡、身份证（身份证包含前4项）、账号、现居住地址和家庭信息
2. 健康数据：基础身体情况、医疗记录和运动数据
3. 兴趣爱好：饮食、娱乐、运动等方面
4. 工作信息：公司、职位、薪酬和同事通讯录
5. 财产数据：薪酬、存款、股票、汽车、不动产和贵重物品
6. 信用度：由信用机构提供的征信记录
7. 消费信息：消费记录（含商品类型、购买时间、购买价格和收货地址）、消费水平和浏览记录
8. 社交圈子：通讯录（含好友、同事、同学和亲戚）和社交动态（含线下和线上）
9. 活动范围：出行记录、主要活动范围和旅游

以上用户特征以API形式接入，第三方应用获得用户授权后才可访问和存储相关数据，相关细节请看第二篇文章。

组件

AR是人工智能中机器视觉的重要体现，具有机器视觉能力的摄像模块可以将电子世界和现实世界结合得更紧密，第三方应用接入摄像模块可以有更多玩法。

在文章编写期间，开发者已利用苹果的ARKit实现了好多有趣玩法。同时，Google也推出了相应的ARCore，但只能用在android7.0和8.0上，普及率很低。

语音识别是人工智能中自然语言的重要体现，第三方应用接入系统语音模块可以优化自己的产品结构，提高用户的操作效率。

身份验证模块类似于现在的Oauth协议，方便用户注册和登录第三方应用。身份信息API提供的公开信息减少了用户注册时的信息填写成本，也有利于第三方应用获取更完整正确的信息。

应用注册需要个人身份信息已在国内实现，只不过是由国家规定，第三方应用注册时要求绑定手机号码，而手机号码已与个人身份信息挂钩。

由于银行想法和技术的滞后，给予国内第三方公司如阿里支付宝、腾讯财付通等创造移动支付的机会；苹果、Google在iOS和Android系统层面推出了自己的移动支付方式。但是多种支付手段都不利于个人账单管理，在使用流程上微信、支付宝等扫二维码的手段都不如系统层级使用NFC的Apple Pay方便。要统一支付流程，必须由国家机构推出新的政策来执行，统一的支付模块有助于用户移动支付和个人账单管理。

在编写文章期间，央行已宣布，从2018年6月30日起，类似支付宝、财付通等第三方支付公司受理的，涉及银行账户的网络支付业务，都必须通过“网联支付平台”处理。同时，国家已关注人工智能服务社会信用体系的建设工作，腾讯也开始建设自家信用体系，在不久的将来相信个人征信也会被国家机构统一。

其他资料阅读

• MIUI 9新体验之信息助手
• 原子设计：https://zhuanlan.zhihu.com/atomicdesign

以上就是第三章的内容，下一章本次更新的最后一篇文章《人工智能与设计的关系》，敬请期待。

相关阅读

人工智能与设计（1）：人工智能的发展和定义

人工智能与设计（2）：面向用户的人工智能系统底层设计

作者：薛志荣（微信公众号：薛志荣），百度交互设计师，二年级生

本文由 @薛志荣 原创发布于人人都是产品经理。未经许可，禁止转载。