上周的一个下午,我与某设计协同产品的团队在一家咖啡馆讨论着 Ai 设计。在我们座位的后方,同样坐着几位年轻人,大家激动地聊着 AI 给如今的互联网带来的冲击,以及若隐若现的各种机会。
GPT 不断地进化,关联的产品层出不穷。设计,作为 AI 领域里不可忽视的一个分支同样也备受关注。AI 设计到底行不行?设计师的工作会有哪些影响和变化?这些都是设计领域最近被讨论得最多的话题。
这两个多月,我将研究的重心全面转向了 AI 设计以及在未来它与设计师的关系上。结合着最近与一些领域内相关公司的交流,还是有一些自己的观点和想法,在这里一起与大家分享一下。
注:本文所聊的 AI 设计特指 AI 在界面设计中的应用,插画、CG 等图像类设计不在本篇讨论范畴。
AI 给对设计的加持的确让人很兴奋,但事实上在目前它们只是论证了可能性,而并非可行性(或者说是确定性),但从可能到可行,真正进入商用环节其实还有一段路需要走。
所以这里我想先抛出一些自己的观点和判断,大家可以先姑且带着这些信息继续往下读。
这半年来,设计领域出现了不少基于 AI 的新产品和工具。输入一段文本描述或是拍一张手绘线框稿,点击发送。一张界面设计稿,甚至连代码就帮你完成了。
看上去确实非常的让人激动,但仔细分析一下你就会发现它们并不是突然一步迈到了你的面前。这里我们可以通过几个案例来分析一下现有 AI 界面设计的思路。
Galileo AI 是近期被很多人提起的一个 AI 设计工具,通过一段简要的描述就可以生成对应的 UI 界面。Galileo 会基于用户的描述和系统内置的“库”给出界面设计方案。
An onboarding screen for a dog walking app
相较于 Galileo AI,Uizard 则稍稍进了一步,可以基于文案描述来生成一组页面。
比如下方这个宠物素食应用,还是输入一段描述,不同的是系统生成的是一套设计方案,比如商品列表、详情、购物支付等。
我们将两个 demo 的输入信息进行一下分析,会发现两个关键信息:
01. 界面类型
两个案例中分别提及了关键词 Onboarding page 和 Delivery app ,它让 AI 明白用户需要的是哪些类型的界面。
02. 产品类型
两个案例中分别提及了关键词 dog walking app 和 vegan pet food ,它能让 AI 进一步了解用户需要的是哪一类型的产品,甚至此类产品常用的文案信息以及界面风格。
我们以Galileo 的遛狗应用为例,系统能够通过对「界面类型」和「产品类型」两个关键词属性的分析,挑选出与之匹配的模板、物料进行拼接,快速地生产用户所需要的界面。
这类 AI 设计工具原理最核心的在于对“案例库”的引入,这就相当于给 AI 提供了一系列的行业属性和通用设计规则。
互联网产品设计发展至今,界面设计已经足够的类型化和模式化。我们可以从大量的案例库和“飞机稿”中提取设计规则,也正是得益于 GPT 的强大处理能力,让 AI 界面设计具备了可能性。
这也是为什么我们输入一段文字就能获得一个看上去还不错的界面设计。
最近刚发布的 GPT 4,增加了对图片输入的支持,甚至更进一步直接将线框稿转化成了 HTML 代码。
Demo 虽然很简单,但它向大家证明了 AI 可以帮助用户完成从 Wireframe 到Code 的完整能力。
相较于前面两款「文转图」的产品,GPT 4 不仅仅有案例库,它还增加与之匹配的代码模块。
读过前面设计系统系列文章的同学们应该已经发现,这其实就是得益于一套完备的设计系统的支持。
无论是 Material Design、BootStrap 还是 AntDesign,都可以轻松地胜任这项工作。
这也是为什么我在前面提到设计系统会因为 AI 设计变得更加底层,但价值也将更为显性化的原因。
小结一下:
现有的 AI 界面设计工具,核心在于需求输入 → 需求分析 → 规则匹配 → 结果输出四个步骤。
输入、分析、输出已经成为 AI 的基建能力,而规则的优劣将影响一款 AI 设计工具服务能力和质量。
有了这个基础认知,AI 写简历、AI PPT 等 AI 工具的逻辑就很好理解了。大家只是行业不同,案例库和规则不同而已。
我们前面说过,以目前的产品能力来看还只是论证了 AI 界面设计的可能性,离真正进入商用还有一定的距离。而这其中的核心就在于案例库和设计规则是否能够支持在业务中的设计工作。
如今我们所拥有的案例库,大量来源于各类产品截图和飞机稿。它们既没有业务和需求的背景输入,也没有数据验证的佐证,更别谈从中抽象出具体的设计规则。
将它作为前期的探索和启发是可以的,但如果直接参与到业务需求的设计中,我相信没有哪个需求方会同意。
除了上面提到的这些专注于设计领域的工具产品,其实还有很多其他领域的公司也在尝试 AI 设计。
相较而言它们的目标需求会更加的明确,就是要解决某个具体领域或业务中的设计问题。
通过 AI 来进行界面设计,其实可以更早地追溯到 2014 年左右,由著名的电子杂志应用 Flipboard 推出的排版布局引擎 Duplo。
由于移动端高速发展所带来的排版挑战,Flipboard 基于原有的 Page 布局引擎升级出了 Duplo。
相较于 Pages 所能提供的 20 种布局,Duplo 借助 AI 算法将布局的可能性直接提升至恐怖的 6,000 种。
同时 Duplo 也会通过设计师的专家经验输入和数据验证来进一步优化,组合成更大的布局模块供客户端渲染使用。
得益于 Duplo 的强大能力,无论在什么尺寸的设备上,什么类型的内容,我们都可以获得为之惊叹的阅读体验。
线框稿转界面代码,GPT 4 并不是第一个。Airbnb 的设计团队在 5 年前就有做过尝试。通过扫描线框稿,AI 就可以帮助设计师完成工程原型的转换。
相较于 GPT 4,Airbnb 的这个方案的可行性是极高的。Airbnb 有着非常完善的设计系统,每个模块从设计到代码都有一一对应。
从线框稿的识别到对应设计规则的匹配再到代码的生成完全可以直接进入业务生产流程。
就在 GPT 4 发布前的几天,Salesforce 也发布了自己的 GPT 产品 – Einstein。
可能是因为它的行业特性,也有可能是几家大公司的声量太大,Salesforce 的这次发布并没有引起大家太多的关注。
严格意义上来说 Einstein GPT 并不是一款设计工具,但就我目前的观察而言,它却是当前将 AI 设计与商业结合得最好的产品。
Einstein 的设计功能是“埋”在产品中的,你可以唤起 AI 助手,通过输入一段文字描述来创建一个页面。比如下方的这个表单页面。
与 Airbnb 一样,Salesforce 也有着一套非常完备的设计系统 – Lightning Design。
用户可以很轻松的创建一个基于业务特性的应用界面,而且它不是设计稿,而是一个已开发完成且可以与用户进行交互的产品功能。
相较于前面的这些产品,Einstein 则更进一步地将设计融入到了工作流程中。
这张通过 AI 设计生产的表单界面可以直接发布上线,回收的数据也可以直接进入业务数据库中。
这也是 Einstein GPT 最让人激动的地方,将 AI 的能力真正融入到了产品。无论是设计还是文本处理,目的都是直接参与到业务生产中,帮助用户高效的完成工作。
说到这里就不得不提一下钉钉和飞书这两款产品。在我看来这两家公司都具备完善的业务级设计系统,也都存在大量的界面设计需求。
而且钉钉原本就已有酷应用和宜搭两块产品能力,非常适合于将自己的 GPT 能力与 AI 界面设计进行结合。
所以在国内的市场中,我还挺期待这两家产品在这方面的动作。想看看它们在后续的产品研发中在 AI 方向会做些什么,Salesforce 的 Einstein GPT 就是一个非常好的方向。
如何定义 AI 页面设计的成功?核心的评判标准还是质量和效率。
即在某个特定领域或业务中,完成的质量达到设计师的通用标准,完成的效率远超设计师。同时它还需要具备清晰的商业价值,有客户愿意为之买单。
想要达成这个目标,我认为必须满足以下四个前提条件:
01. 企业级或领域级 AI
现有 AI 的学习都是基于通用模型和数据来完成,所以它能提供的解决方案也只是可能性。
想要真正为业务提供确定性的方案,就必须结合行业知识和业务特性及数据来持续的学习进化,最终才能真正训练出一批懂业务、有专业的 AI 设计师。
02. 设计标准及专家输入
明确的设计标准和规则是 AI 工具能够参与到业务生产中最为重要的基础。
而在这个过程中,领域级设计系统和业务级设计系统的价值将进一步地放大,大家再也不用担心如何衡量设计系统的价值了。
03. 明确的市场需求
无论是 Flipboard 还是 Salesforce,它们在尝试解决的都是需求体量与生产成本(效率)之间的矛盾。
只有市场需求的明确存在,AI 设计工具才有创造价值的可能性。
04. 生产流程的融入
设计只是整个业务生产流程中的一环,仅仅只是设计环节的改变无法将 AI 的价值最大化。
像 Salesforce 一样将 AI 设计能力融入到业务生产流程中才有可能真正体现其价值,真正地做到降本提效。
如果基于这些前提来看,现有的大多数 AI 界面设计工具离成功还有着不小的距离。反而是这些在具体业务中尝试 AI 设计的公司已经开始让 AI 产生价值。
所以,在我看来 AI 设计工具的发展不应该走通用工具的路线,而是需要紧贴某个领域或者具体的业务来继续发展。
海外的 AI 设计工具发展得热火朝天,而在国内是似乎没什么太大动静?
其实这段时间有幸陆续与几家做设计类产品的公司有过一些交流,大家都还是比较客观冷静的在寻找 AI 设计的真正价值点。
相信用不了多久就会有一些产品出现,这里就不剧透了,大家期待一下吧。
回到 AI 界面设计这个话题,其实阿里早些年也做过一些尝试,有偏营销端也有偏 B 端,总的来说还是成功的。
也正是这些尝试让我坚信设计系统的长线价值,在后面的几年时间里持续投资源建设设计系统的中台能力。
接下来我将结合几个案例来与大家分享一下我这些年我对设计系统、AI 界面设计可行性的一些思考。
鹿班可以说是阿里在智能 AI 设计上真正意义上的第一次尝试。和 Flipboard 一样,它最初是从排版的设计开始的。
Banner 虽然很“小”,但它同样有着自己的体系和逻辑,都是对界面布局及内容组合的设计探索,然后借助机器来进行大批量的生产。
在解决了生产力的问题后,我们需要借助一系列的工作来进一步提升 Banner 生成的质量,让它能够达到一个合格的水准。
这个时候淘宝积累的大量数据就可以作为「行业规则」输入到系统中,同时在辅以设计师的专家经验,鹿班可以做达到一个初级设计师的设计要求。
当到达这个阶段时,鹿班就已经不再只是一个设计工具了,还已经具备了产品商业化的基础。在完成投放链路、千人千面、分桶测试等能力后,鹿班已经完全融入到了业务流程中,成为淘宝业务中一个明确的业务能力。
从专业视角来看,Banner 设计其实还是一个相对简单的领域。从市场需求上来说,它又是一个非常值得尝试的方向,淘宝营销页面的智能设计也就是在同样的背景中诞生的。
我们可以把鲸幂理解为阿里在 AI 界面设计上的一次升级,从 banner 的智能设计升级到了营销页面的智能设计。
2017 年开始,集团的双十一规模越来越大,随着而来的就是每次数以千计的营销页面。仅 3.8、6.18、11.11 这类 S 级活动,靠人力来支撑已经变得越来越不可控,这还不算上日常的各类 A+、A 级营销活动。
解决方案起源于一个模块级的 D2C(Design to Code) 方案 – ImgCook。通过对视觉稿中的元素识别,将其转化成可用的业务代码。
有了模块级的解决能力,用 AI 来解决数以千计的页面设计甚至代码生成就具备了可能性。设计师和工程师不再为调整每张页面而疲于奔命,而是将工作的中心放在制定模块、布局的规则上。
同时 AI 会基于数据和业务规则进行深度学习,根据场景、行为偏好来组合设计元素和布局框架,最终生产千人千面的营销页面方案。
通过这几年在各类大促中的不断演练,智能 UI 已经能够覆盖 90% 以上的各类会场页面设计和代码自动生成工作,同时也将能力覆盖到了更多的其他业务场景中。
其实无论是鹿班还是鲸幂,之所以能够进行大批量的界面生成工作,其核心还是在于有一套明确的设计系统作为支撑。虽然每年各类营销大促的风格都在不断变化,但其核心框架和模式并没有变。
除了上面偏营销场景的案例,两年前我们也在 toB 端做过一些尝试。虽然最终并没有能走下去,但其思路上更接近我们今天所看到的各类 AI 界面设计场景,也非常值得和大家来分享一下。
零售通本质是一个服务城市社区的零售业务,包括订货、物流、销售、营销等一系列的服务。因此存在大量的同质化且有业务特色的业务工作。需要大量重复的后台系统能力建设。
零售通有一套基于 Fusion Design 的设计系统,设计师基于业务定义了一系列的组件、模式和模板。但它依旧需要依靠设计师和工程师来开展工作,面对不断增加的业务需求效率的提升依旧有限。
早期在与玉伯的沟通中,我们就曾讨论到是否可以进一步将业务模块、流程进行封装,提供可控的配置能力来让产品、运营在语雀中写 PRD 的同时来自行生产页面,也就是通过自然语言来让机器进行设计。
零售通的这个契机正好给了我们一次尝试的机会,沿着这个思路我们做了一些方案尝试。比如业务方可以在 AI 设计工具中输入以下需求描述:
创建一个双十一商家活动报名。需要商家提交活动商品、行业资质、投放物料、对接人。报名审核完成后站内信反馈结果。
•商家活动报名对应一组业务流程,包含活动详情、活动报名、商品管理、审批管理等页面;
•活动商品、行业资质、投放物料、对接人封装成固定业务模块,包含对应的必要字段;
•站内信反馈包含审核反馈模板和站内信推送逻辑
有了这些确定的业务逻辑和规则,我们就可以借助业务设计系统完成界面设计的自动生成,同时通过对应的 Fusion 组件代码进行页面代码的自动生成。
我们大致评估了一下,这套系统基本能满足业务 70% 的日常需求。也就是说理想状态下绝大部分的系统设计和研发都不需要设计师和研发参与,业务方可以自行完成交付。而设计系统则保障了自行交付的页面能够保持同样的合格的基础体验。
这个 70% 的比例是否真的可以达到?我可以很负责任的告诉大家,是可以的。当然它的前提是需要简历在明确的需求标准和设计约束之上,同时也需要业务生产链路上各个相关角色能够达成一致。
如果你也想尝试一下,可以试试从下面的四个步骤来梳理一下自己手头的业务。如果这里的每个环节都能够清晰、明确的定义出来,那么在你的业务中这个可能性也同样成立。
01. 业务实例梳理
对现有已存的各类系统界面进行梳理,总结核心业务场景、链路、页面、模式以及组件。
02. 业务级设计系统建立
基于业务实例的梳理建立业务级的设计系统,完成设计系统的统一。
03. 业务组件 & 设计模式封装
结合业务特性进行业务组件、模式的封装,进一步完成工程化。
04. 业务链路梳理
对业务逻辑和基础字段进行梳理,确定业务链路并与业务方、工程团队达成一致。
零售通的整个方案已经初步具备了 AI 设计的可行性,虽然有着不小的技术挑战,但大家还是非常的激动想要立刻去立项。可惜不巧正好遇到了业务战略的重大调整,整个方案只能搁浅。这也算是在阿里最后这段时间的一个遗憾吧。
前面和大家聊了这么多的案例,最终的焦点还是回到了设计系统。在「设计有得聊」早期的文章里,曾经给大家介绍过设计系统的三个阶段,统一化 → 工程化 → 在线化。
其实这里还存在有第四阶段,也就是我们今天所聊的设计系统的 AI 化。只是在当时AI 化的条件还远没成熟,所以也就没给大家进一步过多的介绍。
不过谁也没想到这不到一年的时间,AI 技术突飞猛进,设计系统的第四阶段 AI 化突然就这么到来了。
注:关于设计系统的三个阶段可在文章「#02. 设计系统应该做成什么样子」中回顾。
如果你对设计系统有过一定的了解,你就会发现 AI 天然就是设计系统最佳的“消费者”。它具备很强的学习能力,能够快速的熟悉你所创建的设计系统甚至帮助进行迭代、进化;同时它也具备极强的“交付”能力,能够基于确定性的输入进行快速的需求交付。更重要的是它的效率极高。
目前为止,我认为有两个方向的 AI 与设计系统结合是具备明确的可行性和商业价值的。
01. 领域级设计系统 AI 界面设计
开篇提到的两个 AI 设计工具,我说它只是做到了对可能性的论证,但不具备真实商用的可行性。原因在于它输出的只是“飞机稿”,其实根本原因在于缺少领域级的知识输入,而这个知识输入就是领域级的设计系统。
之所以能够使用 Ant Design 、Fusion Design 等设计系统完成各类后台界面的设计和开发,是因为它们已经完成了对此类产品的功能、设计模式的抽象,并且保障了还不错的基础体验水位。而无论是遛狗应用还是外派派送还没有能形成类似的解决方案。
我们在做集团业务中台的业务时,非常重要的一项工作就是对电商体系进行功能和设计的抽象,比如搜索、购物车、下单、支付等。这项工作的本质就是在制定标准、定义体验的基础水位。
02. 业务级设计系统 AI 界面设计
这个部分其实不用过多的阐述,Salesforce 的 Einstein GPT 已经给我们展示他们的成果。这里我想和大家一起回顾一下 AWS 去年发布的业务级设计系统 CloudScape。
AWS 的这套设计系统做的非常完善,67 个组件、35 个 pattern 以及 27 中 Demo 足以覆盖其日常业务的绝大部分场景。同时它也具备极强的约束性和规则的确定性,非常适合 AI 的学习。
注:可在文章「#05 设计系统案例分析 CloudScape Design System」中进行回顾。
CloudScape 需要做的就是基于业务再进行一轮业务属性、字段、逻辑的“封装”,以及一定程度的自定空间开放。以它们的成熟度来看,让这套设计系统 AI 化应该很快就能实现。
说了这么多设计系统、AI 设计能力的可能性,我们也就不得不聊一聊在不久的将来,设计师会面临什么,市场需要怎样的设计师。
每一个角色的出现都是因为它能够提供更好的价值增量,每一个角色的消亡也是因为有更好的价值增量出现替代了它们。鹿班、鲸幂如此,AI 设计亦是如此。尤其是在这个降本提效的年代,成本就是最好的催化剂。
之前的文章里,我给大家介绍了架构型设计师和产品型设计师。在 2018 年那个阶段,这个想法虽然可行但时机兵不成熟。即使是在刚刚过去的2022 年,架构型设计师也只在极少数的公司存在。
AI 时代的快速到来会让很多基础、重复的界面设计工作失去价值,但我并不认为像很多媒体鼓吹的立刻、马上,而是大概率会在两年内发生。两年的时间足以让 AI 界面设计的技术完全的跑通,让更多真正具备商业价值的产品打磨到可大规模使用。
两年的时间在互联网的世界里也不长,很快就会过去了。无论大家是想让自己不掉队或是寻求更好的发展空间,我觉得都需要考虑一下自己未来的发展方向了。
原文:https://mp.weixin.qq.com/s/wh6qS6-VB8OYfzXto0HCpg
既然来了,说些什么?