NLUI只是UI之一，光靠它并不是最佳实践 【2023H2】

1、何谓NLUI (Natural-language user interface)

前一段时间由于ChatGPT的热潮，曾经让很多产品经理和其他岗位的人觉得类似ChatBot或其他类似方式的NLUI会是UI的未来必经路径。

但经过1-2个季度的各种尝试，不少真正去做产品demo的人已经充分意识到了NLUI并没有之前一些人吹嘘的那么美好。在最近我仍然看到了一些“知其然，不知其所以然”的人，所以还是考虑写一篇文章来解释这其中的逻辑。

本文虽然对于“一切皆NLUI”是批判的，但并不是说NLUI本身没有适用场景。

2、NLUI的优缺点

在LLM的加持下，NLUI有一些之前UI所缺乏的优势：

• 用户在几乎不用看文档的情况下就可以进行使用和交互，NLUI同时向用户提供功能的快捷入口、功能解释等功能。用户不需要熟悉该软件所包含的所有细节功能，不需要知道这些功能所在的位置。

• LLM加持的NLUI可以根据用户场景自动填充功能参数的默认值，减少用户精确指定参数的工作量。

• 其实这个能力也可以迁移到传统UI上，根据已经填充的参数和用户额外简略描述的context来不断更新尚未指定的参数。

• 自然语言是所有人都掌握的一个交互方式，用户学习的门槛相对于未经过仔细设计的UI来说较低，这同时也可以让产品开发回避高成本的容易上手的UI开发成本。

但NLUI也有一些重要的缺点：

• 【用户输入信息成本高】用户输入信息的意愿始终是较低的（无论是打字还是语音），在与人对话中也是经常只说一些关键性的信息，当对方不懂的时候才会考虑进一步展开。而打字相对于语音来说，用户的使用成本更高，输入100个字对于用户来说都是一个不可无视的成本。

• 【难以探索】NLUI并不能向用户完整的展示自身系统所能提供的所有功能，并不太适合用户探索系统功能的场景，除非NLUI本身的联想关联能力极强。

• 这时NLUI就好像面对用户的一个人，用户没有耐心听TA做大量的自我介绍，用户也懒得输入很多问题不断的问TA。这导致一般用户从NLUI这个渠道能够获得的信息其实少于一个很传统式的复杂菜单系统。

• 【不擅长精确指定】用户输入信息几乎总是偏少，也容易产生歧义，让用户准确的输入Key-value对其实成本也较高，一些复杂结构例如树、伪代码等就更难通过自然语言来进行准确描述。

3、何时使用NLUI

UI选择的标准很简单：用户应该选择他使用成本最低的UI。只不过这个使用成本跟系统特性、功能特性、用户的熟悉度等都有关。

结合前一节提到的优缺点，决策需要考虑的维度有：

【D1】用户是否不熟悉系统

• 新用户不熟悉系统，此时更需要一个NLUI来降低用户的上手门槛。

• 已经很熟悉系统的用户，如果它直接操作传统UI的速度明显快过他打字精确指定需求，那么就仍然应该使用传统UI。

【D2】系统中是否有极大量的功能，且缺乏好的、容易理解的分层组织方式

• 如果系统中只有少数功能，例如5个，那么就做5个按键、或者一个功能页面上就放5个参数设定框就行了。传统UI很合适，反而用NLUI的话会偶尔出现用户输入歧义导致理解错误、用户总数据量更大等问题。

• 如果系统中有很多功能，难以寻找或者记忆。那么用NLUI做一个功能页面路由是很不错的，但也需要配合个性化的常用功能入口置顶功能。每个功能页面是要传统UI还是还要在NLUI中是一个需要独立考虑的问题，决策思路跟本节内容一样。

【D3】系统中是否有大量可选配置的参数

• 如果一个功能有大量参数可以配置，那么使用NLUI让用户大致输入他的场景上下文，就可以根据此来生成一套默认的参数配置，降低用户的逐一指定的录入成本、理解成本、思考成本。

所以一般来说，大部分系统的最好状态应该是混合UI的状态，传统UI和NLUI都支持。而用户对这两者的使用频率根据他的具体需求和个人习惯有关。

后记

本文并不是一个复杂的概念，本来也没有想撰文特地讨论。但最近又看到了一些同仁对此感觉迷茫，所以虽然比较晚了，但还是写了本文。同时也是给新开的微信公众号增加活跃度。

交流与合作

如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。

希望留言可以到知乎对应文章下留言。

本文于2023.9.12首发于微信公众号与知乎。