对话即服务:LUI如何重塑数字世界的运行法则(二)
LUI系列的上一篇介绍了什么是LUI、LUI的本质特征和优势。本篇我会介绍LUI与GUI(图形交互)的关系,以及未来什么样的APP会留存。
如果你看了我有关LUI主题系列的第一篇文章,我相信你的认知一定得到了一定程度的清晰甚至是升级。你应该已经认识到,未来人机交互的范式是属于LUI的,因为它是最灵活最直接的。GUI可能是确认,可能是一些多选项下的选择、确认。
未来GUI和LUI的关系会是怎样?
LUI增加了灵活性,但是降低了直觉性。具体来说,LUI在给人直觉引导方面,仍然有不如GUI的地方,比如初级用户面对一张白纸会很迷茫,不知道自己可以做什么。LUI的学习曲线过于陡峭,什么都依赖于用户的主动发现,这不是好的on-boarding的过程。GUI给了更多的限制,但也让选项和路径明显,大家上手会更轻松。
GUI是LUI的内容
试想一下这样一个场景:你对豆包说:帮我推荐一下附近1公里内的火锅店。豆包识别了你的意图、调用了地址API查到了你当前的地址以及天气情况、再调用点评的API(理想情况~)按照评分和菜色读取了商家列表,再读取的你的偏好数据(比如你来自重庆等等),帮你推荐了5家火锅店并以卡片的形式展示在聊天框内(GUI),你可以点击卡片查看商家的详情信息、评论等。这就是一种典型的未来LUI与GUI的存在关系。
当你使用豆包或者ChatGPT 的时候,你跟它聊天(即 LUI ),它可以根据你对它说的要求生成你需要的图表、代码乃至软件,然后,你可以在这个新鲜出炉的软件界面上(即GUI上)点点戳戳。 也就是说,在这个场景里,在你跟AI 的对话中(LUI),GUI 被作为对话内容的一部分,生成出来,给到你。
也就是说,软件会成为 LUI 的内容。
搜索引擎本身就是一个超大型的软件,如果搜索引擎成为LUI的内容会怎样: 如果搜索引擎成为 LUI 的内容会怎么样?当你跟 AI 说“我想找XXX”,它不是返回一个有搜索结果的网页,而是生成一个搜索引擎——专门为你的搜索请求新鲜生成、特别定制的搜索引擎! 它有特定的GUI,专门为你这次查找任务所定制。 它有特别定制的搜索算法,同样为你这次查找任务定制。 它有特定的后台任务、工作流、Pipeline,以及对应所有这些的后台代码…… 它其实就是一个 Agent。
未来什么样的APP会留存?
说了这么多颠覆性的观点,难道现在的这些APP在将来都要退出历史舞台啦?未来哪些APP会幸存下来? 现在的软件其实基本都是按照角色和场景拆分出来的:什么样的角色、什么样的场景下用什么样的软件。现在看起来,如果一个软件服务的是单角色、单场景,大模型很容易把它击穿掉,这个软件很容易变成通用型的能力。如果是多角色、多业务流在组织内的协作软件,它会相对更复杂一些(如B端软件)。
另外,用户侧的产品冲击很大,因为用户的切换成本非常低,有变化,用户很快就变了。但是,客户的切换成本是很高的,所以越靠近客户侧的产品,它其实越能承载AI带来的这些变化。因为它在客户内的协同网络越复杂,反而变成加强它价值厚度的一种可能。数据肯定是一个很重要的点。另外,客户侧的产品,影响决策的要素多。特别是多角色、跨部门的时候,往往要共同去做决定,这对组织来讲是有成本的。用户的话,好不好用、谁便宜,自己就定了,不需要开会商量,是一个消费品的逻辑。所以客户侧的产品是可以相对容易守得住,可以承载变化的。
本人有话说:本人恰巧B端(SaaS)、C端产品都做过,对两者的产品方法论都有一定的理解。SaaS产品的一个重要指标是续费率,我认为单纯从软件本身的使用角度来看,客户续费的原因主要是:用得挺顺的了,从上到下的员工都用惯了,跟业务流程也磨合地很好了,有用的数据也积累了一堆了,真要切换需要很高昂的成本(各个部门各个角色的重适应)以及数据的废弃;而C端产品的护城河,更多的是内容(或者说服务,比如dy提供的是一种娱乐服务,tb提供的是买卖服务,外卖提供的是一种餐饮服务等等),如果有一天,xhs的创作者集体搬迁到dy,或者tb商家全部入驻到jd,那APP本身也就剩下了个空壳子。
本篇介绍LUI与GUI(图形交互)的关系,以及未来什么样的APP会留存,下一篇我会介绍LUI如何进行落地。
本文由 @「爱」原生 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务
- 目前还没评论,等你发挥!