在上一期的专栏中,我们讨论了生成式 AI 在产品界面设计中遇到的问题,以及为什么还无法运用到日常的设计工作中。
总的来说,主要体现在两个方面:
01.缺乏可依赖的设计标准
界面设计不仅仅是视觉上的创意,它更需要强有力的逻辑支持。我们可以明确地定义一只猫或一辆汽车的外观,但对于购物车界面或下单支付流程,缺乏具体而明确的定义标准。
在缺少这些明确规则的情况下,生成的 UI 可能只是各种组件的简单堆砌,缺乏逻辑性和良好的用户体验。相比人类设计师的成果,生成式 AI 产出的界面往往不够稳定,难以达到企业级的需求标准。
02.缺乏对业务逻辑的理解
我们日常的设计工作都是围绕着具体的业务开展的。而如今现有的设计模型都只是通用模型,无法理解具体某个业务的特性和复杂度。这就导致 AI 的生成结果难以满足设计要求,无法直接应用到具体业务生产环节中去。
这两个问题是当前生成式 AI 在界面 UI 设计方面发展的最大挑战。然而,我们也注意到,生成式 AI 在一些特定的业务场景中已经取得了显著的进展。比如,Salesforce 的生成式画布就是一个很好的例子,展示了生成式 AI 在企业环境中应用的潜力。
本期的文章,我们将从 Salesforce 的生成式画布开始,与大家来一起看看当生成式 AI 与业务进行融合后,会给我们的设计带来哪些变化,给用户又带来哪些帮助。
Generative Canvas(生成式画布)是 Salesforce 今年 10 月发布的一个新功能。它能够在 CRM 系统中基于用户的提示词,结合系统内实时业务数据来动态生成 Dashboard 的界面 UI。
它为用户提供了一种全新的工作方式,更灵活也更有效。只需要输入一个简单的指令,系统便会自动整合相关的数据,生成相应的画布界面。这极大地减少了用户在数据汇总、整理和设计界面时的时间和精力。
举个例子,一位售前支持人员准备与客户进行例行的月度沟通会议。在过去他需要手动从不同的系统中提取销售数据、沟通记录、会议纪要,再整理好会议要讨论的议题,形成一个文档或 PPT。
对于一个没有设计相关经验的人员来说,这需要花费大量的时间和精力。而借助生成式画布,他只需要输入一个「生成与 X 公司的月度沟通会议的准备材料」,系统便会自动聚合相关数据,生成一个整洁、直观且实用的画布界面。
如果有需要,用户还可以进一步输入指令,让系统动态添加信息模块,比如某个地区的销售趋势或客户反馈数据。同时,生成式画布会基于信息重新进行界面的排版生成。
在过去,这种报表界面需要由平台来提供,或是由企业的管理员来进行手动配置。使用体验上很难照顾到所有人的不同需求。
而生成式画布为用户提供了一种全新的工作方式,更灵活也更有效。只需要输入一个简单的指令,系统便会自动整合相关的数据,生成相应的画布界面。这极大地减少了用户在数据汇总、整理和设计界面时的时间和精力。
我们多次提到过生成式 AI 当前存在的问题,那么 Salesforce 是如何解决的呢?其实核心就在于以下三个点:
01. 数据的互通
Salesforce 通过其数据平台将结构化和非结构化数据(如邮件、即时通讯等)实现了全面的融合与互通,使得画布中的基础“物料”可以更轻松地进行组合和展示。
内容的聚合生成离不开数据,而数据的互通则是很多 B 端产品在提升易用性方面的核心挑战。在前两年的飞书发布会上,谢欣曾明确提出内外部平台数据互通的重要性,并将其视为产品的关键点之一。
然而,所有从事 B 端业务的同学都知道,实现这一目标并不容易。谢欣提到的这一难题,到目前为止,依然是许多企业面临的未解难题。
02. 设计系统的融合
正如我们之前提到的,界面生成离不开一套可靠的设计标准。Salesforce 一直非常重视在这方面的投入,其 Lightning Design System 在业界也受到了大家的广泛认可。
生成式画布的所有界面 UI 都受到 Lightning Design System 的“管控”。这也就意味着无论需求如何,生成式画布都能确保界面设计的质量一致性。在大多数常见的业务场景中,生成式画布能够提供与人类设计师to同等水准的设计解决方案,保持用户体验的基础水准。
03. 产品的视角
很多时候大家会将设计 AI 看作产品开发过程中的一个辅助角色或环节,但这种看法往往限制了设计 AI 所能获得的“资源”和重视程度。而 Salesforce 的做法则完全不同,他们将设计 AI 作为产品自身能力的一部分来看待,使其直接参与到产品为用户提供服务的过程中。
设计的 AI,它从来都不只是一个设计层面的工作,而是产品能力的一部分。将设计 AI 融入到产品能力建设中,它就不再只是一个中间环节或辅助角色,而是产品能力的一个重要组成部分。这使得设计 AI 的定位和价值都会发生很大的变化,那么它的定位也将截然不同,才能够真正的最大程度的发挥出它的作用。
沿着 Salesforce 的思路,我们可以试着将自己作为用户,带入到我们自己的工作场景中,例如设计评审。
在做设计中台的那段时间里。我们一直想要找一些设计师与上下游的共同场景,以此来推动设计协同产品在集团内的普及。而设计评审就是一个非常有代表性的场景。
在设计评审中,不仅有设计师,还有产品经理、开发人员以及业务方的参与。人一多,就容易乱。比如下面这些具体的问题。
01. 评审会议前:准备工作耗时耗力
在评审会议前,设计师通常需要整理大量的材料,包括设计稿、PRD、研究报告以及业务数据等。
这些材料大概率分散在不同的平台中,收集和整理的过程需要花费大量时间和精力。这个繁琐的准备过程不仅增加了设计师的负担,也可能导致信息遗漏,从而影响评审的材料质量和完整性。
02. 评审会议中:背景信息缺乏,效率低下
在评审过程中,设计师需要为参会者提供一些背景信息来“热场”,确保所有人都能理解设计方案的前因后果。
这通常需要大量的时间进行背景输入,但即便如此,信息传达也常常会不够全面。这种背景信息不足的情况导致会议效率低下,参与者无法在有限的时间内对方案提出高质量的反馈,讨论也容易陷入冗长和无效。
03. 评审会议后:纪要和任务跟进不系统
会议结束后,设计师需要整理会议纪要并明确各项待办任务的负责人。
这个过程耗时且容易遗漏关键信息,缺乏系统化的工具支持使得后续任务的跟进效率低下,责任模糊,影响项目整体的执行进度和质量。
在分析完设计评审这个场景中存在的问题后,我们不妨设想一下,如果我们可以使用类似于 Salesforce 生成式画布的能力,会有什么不一样呢?
假设我们需要准备一次关于“购物车改版项目”的评审会议,只需输入提示词,例如“准备购物车改版项目的会议评审材料”,系统便会自动从各个渠道中收集并聚合相关的“简报”材料。
这些材料可能包括:PRD 文档、最新的设计稿、核心数据的分析报告、历史版本的数据跟踪、用户研究报告等。通过生成式 AI 的自动化整合,这些信息最终会汇总在一个结构化页面中,使得设计师无需手动整理,显著降低工作负担。
如果有需要,设计师还可以在现有内容的基础上,手动添加一些特定信息,以确保最终的“简报”完全贴合项目需求。完成材料准备后,设计师可以直接将这份“简报”分享给参会人员,确保他们在会议前对项目背景有一个充分的了解。
参会人员在收到“简报”后,前提前了解项目的背景、设计目标以及需要达成结论的问题。大家也可以在简报中留下自己的备注和问题,这样在会议的过程中,大家能够更有针对性地进行讨论,减少信息不对称带来的沟通低效。
当评审会议结束后,设计师根据会议的讨论来生产会议纪要和具体的 action 并抄送给相关人员。便于大家在后续的工作中能够明确自己的任务,确保项目能够高效、无误的推进下去。
在一个项目的推进过程中,我们的最终目的是交付一个满足业务需求的设计方案,并尽快推进上线。分析数据、记录纪要、分配任务,这些从来都不是我们的最终目标,而是为了实现这个目标的过程。
然而,这些“过程”却往往占据了我们设计师大量的时间和精力,尤其是在不断组织、生成各种文档和 PPT 的时候。但如果生成式 AI 能够真正地集成到产品中时,我们就再无需为这些“过程”花费过多的时间了。
它可以帮助我们高效地聚合信息、并为之自动生成适合的界面,使得我们能从这些繁琐的工作中解放出来,去专注于解决具体的业务。
沿着这个思路,我们可以再切换到大家更熟悉的 B 端业务场景。在公司最后那段时间里我曾负责了 4 块 B 端业务的设计团队,在我看来,这类型的业务普遍会存在以下几类问题。
01.设计需求量大,设计质量粗糙
B 端产品通常会涉及很多业务场景,而且每个场景的需求量都非常大,设计师需要同时处理并发处理大量的设计需求。
这使得设计师们往往疲于应付需求,解决复杂的业务逻辑。根本没有多余的时间和精力去深度打磨产品的体验和细节。
02.同质化需求多,设计工作枯燥
B 端业务的很多设计需求在外观和形式上高度相似,只是业务逻辑节有所不同。导致大家有大量的机械化重复劳动。
这种高度重复性的设计工作往往缺乏挑战性,缺乏专业上的深入研究的空间,逐渐地消耗掉大家的创造性和设计热情。
03.产品体验不佳,难以获得用户好评
B 端产品的用户类型多样化,不同用户在使用习惯和场景需求上经常存在着显著差异。
由于用户群体的多样性,统一的产品设计很难满足所有用户的需求,导致产品体验评分难以提升。设计团队常常不得不在不同用户需求之间权衡取舍,最终可能导致部分用户的体验不佳,降低了产品整体的满意度。
这些问题的存在,让很多 B 端的设计师对于工作充满了无奈。业务逼得紧,设计师没激情,这种状况让大家都很难受。因此,在设计中台我们也想找一些业务来一起做一些尝试,看看能否借助一些工具来帮助大家一起来减负,提升效率的同时也解放设计师的创造力。正好,零售通的设计团队和业务方一起找到了我们,想看看我们能否能够帮助他们一起来做一些尝试。
一年多前的文章里曾经和大家提到过,我们想尝试在零售通的业务中用语义化的需求描述来生产设计稿。
通过机器对需求的”格式化“,结合业务的设计系统来生产界面的设计方案。然后由设计师和产品经理来对生成的设计结果进行验收和调整,最终直接向研发交付界面代码,继续下一步的工作。
这背后的逻辑和现在生成式 AI 的思路很像,都是借助设定好的业务规则和标准化的设计来组合界面 UI。但在那个阶段,我们没有大模型也没有足够的业务规则标准,即使设计系统做得再好这件事情也只能是构想,很难得以实现。最多只能生成一个半成品,最终还是需要大量人力的介入。
如果当时我们有生成式 AI 的能力会怎样?也许这个尝试在业务中真的能成。只可惜时过境迁,技术发展了,但很多的业务也早已关停了。
早在两年前,Salesforce 推出 Einstein GPT 时,就已经尝试基于它们的设计系统来自动创建各类表单的能力。今天的生成式画布,则是结合数据的聚合将生成式 AI 的能力进一步地放大。而在未来,生成式 AI 必定会在 Salesforce 的产品线中有更多的应用场景,来推动产品真正的向自动化和智能化方向的发展。
通过今天以上聊到的这些案例,我们可以看到生成式 AI 其实是具有非常大的潜力和价值的。它不仅能够提高业务迭代的效率,还可以将我们的专业技能进行产品化,让设计师在企业经营中的作用和价值能够得到真正的发挥。
当然,这一切想要成立还是需要具备一定的前提条件的。在目前阶段,我会将它归结为以下三个方面。
01. 产品层面的集成
生成式 AI 要想能够发挥出它自身真正的价值,我们不能把它看做是设计环节的一个工具,而是平台产品能力的一个重要组成部分。从产品的视角来看待生成式 AI 的能力,才能让它更好地融入到平台的能力中,给产品带来质的变化。
设计其实不仅仅是界面视觉的呈现,它更重要的是承载产品的业务逻辑和行业规则。生成式 AI 需要与它们一起进入到产品中,打通数据和信息,才可能能生成符合业务需求的界面设计,从而在设计中起到实质性的作用。
02. 专家经验的输入
我们经常说生成式 AI 的结果不够理想,其实很大程度上是因为它无法准确理解业务和还原业务需求。
每个业务都有自己独特的行业特性和业务特性,模型无法凭空“悟出”这些复杂的背景信息,需要通过人为地总结和输入专家经验,才能让 AI 更好地理解业务场景。
这些专家经验包括我们对自己所处行业的理解、对业务逻辑的梳理以及对用户行为的分析,只有将这些信息输入到 AI 模型中,才能让生成式 AI 的设计结果更贴合真实的业务需求。
03. 设计系统的支撑
一套完备的设计系统,是生成式 AI 在生成过程中的基础。设计系统首先需要合理、自洽,才能确保生成的结果满足基础的设计要求。
同时,作为设计师我们还需要结合业务和行业的专家经验来进一步抽象和封装(也就是我们的 Pattern 和模板),这其实同时也是设计领域的专家经验。
通过这些设计系统的支持,生成式 AI 可以调用标准化的组件和模式,确保生成结果符合设计规范和业务需求,从而在设计工作中体现出专业性和一致性。
这三个方面是生成式 AI 在界面设计中成功落地的关键因素。只有在产品集成、专家经验和设计系统这三方面都有充分的支持,生成式 AI 才能在界面设计中发挥出它的潜力,成为业务生产环节中不可获取的核心能力。
上一期文章发布后,有同学问我,如果未来真的如文章中所描述的那样,产品的设计、研发都开始走向“去中心化”,那作为设计师我们还能做什么?我们很多人的职业生涯才刚刚开始,面对未来的几十年,总感觉有些不安。
其实这又回到了我们之前讨论过的一个经典话题:AI 能取代设计师吗?
我的看法其实还是和以前一样,能,也不能。
能,是因为很多基础性的工作,比如设计一个表单、一个列表、一个 dashboard 这样的常规设计任务,确实 AI 完全可以胜任。
不能,是因为在商业公司内,设计的核心是为商业服务的。在那些高度复杂、需要业务深度理解的场景中,AI 很难在短期内完全替代人类设计师。很多细节的思考、用户需求的分析,以及对于市场趋势的“嗅觉”,这些方面 AI 暂时还无法超越人类。而与此同时,AI 的能力的演进在很长时间内仍然需要人类的经验喂养和指引。
但有一点我们是可以确认的,那就是在未来 AI 的发展可能会“逼迫”我们将工作的重心从“低端”向“高端”进行迁移。这些“高端”的领域,就是我们设计师在接下来很长一段时间里需要去转型和发展的方向。
这是一个非常值得深入探讨的话题,我们也需要花很长的时间来关注和讨论。找个机会,我会专门写一期文章,和大家聊聊我当下对这个问题的一些观点和想法。
🫰
原文:https://mp.weixin.qq.com/s/RRJloWo1kohVWvlTv5Py2w
既然来了,说些什么?