讲讲AI在B端设计上的应用方法

Homepage recommendation
上海/设计爱好者/1年前/8984浏览
讲讲AI在B端设计上的应用方法Homepage recommendation
最近大广赛作为评委去北京,和不少大学教授还有大厂的朋友们交流,其中交流最多的部分就是 AI 的应用场景和影响。其中,AI 对传统设计、插画类行业的影响是非常深刻的,高校几乎都要展开自救做出对应调整,这个以后有空再聊。
而我们今天讨论的,就是 AI 在 B 端设计方向的应用方法,以及我们应该如何应对。
B 端设计领域的 AI 应用
大多数同学目前对 AI 应用的认识只有文生图、对话、驾驶等领域,但 AI 应用的场景远远不止它们。
和头部的明星 AI 产品、模型相比,细分市场的 AI 应用就非常没有存在感了。比如使用 AI 进行财务的审核、饮料配方的调节、工程安全的模拟等等,它可以帮助企业节约大量的人力完成工作。
概括起来,就是一些可以通过计算机完成的(也不止)重复性劳动或标准化流程,都可以引入 AI 的技术进行降本增效。
那在 UI 设计领域中,这些重复性和标准化的工作内容有嘛?
有,但是并不会像外行或者新手想象的那么多。AI 难以覆盖的场景我们过去的分享探讨过,等等也会做进一步的说明,而这里我们先要探讨的,就是能用 AI 实现的 B 端设计场景,具体有哪些。
我们都知道市面上现在有很多开源的 B 端前端框架,各个大厂前赴后继地对它们进行更新和完善,里面包含了非常丰富的组件库。
讲讲AI在B端设计上的应用方法
Collect
这些组件库不不止是 UI 的组件,也包含了前端的对应代码,前端工程师可以快速调用这些代码组件而不用自己去重新写一遍样式和交互。
原则上,使用现成的组件开发就可以快速完成整套项目的前端内容,这可以给前端工程师节省大量时间。所以即使项目中有完整的设计稿,前端在开发过程中也会偷懒直接略过,直接套用框架内的组件实现。
这和设计师直接套用素材完成运营图设计一样,明明有现成的素材在那里,为什么要浪费一大堆时间自己重新画一遍还是用 3D 建模渲染?同理,要是组件足够丰富,满足项目的需要,设计师也可以直接复用官方的组件素材,不用自己设计。
组件化思维的运用,就是项目工作标准化和重复性的根源,不仅应用在设计领域,对于前、后端开发来说同理。
基于这种思路,催生出了一种新的 SaaS 模式 —— 低代码 Low-Code 服务。
即通过少量的代码,或者干脆不用代码,仅通过可视的工具和组件实现软件的开发,并完成相应的配置和部署的工具。
这概念咋一看不就是建站工具?比如有赞、微店之类的,用户可以在里面直接创建并配置店铺,然后以网页、H5 或小程序的形式发布。
但这只是最初级的应用,传统的建站工具属于帮你预制好了主要的参数和功能,用户只能在这个范围内做少量的自定义编辑和设置。但进阶的 Low-Code,会赋予用户更大的编辑范围和自由度,让用户通过可视化的界面创建自己想要的产品和功能。
讲讲AI在B端设计上的应用方法
Collect
这类产品已经衍生出一个规模不小的市场,因为有大量的中小企业不想投入太多的精力和成本进数字化平台的搭建上,
并希望能快速创建不同的管理工具来匹配企业日新月异的发展需要
这里要划重点,对于一部分企业来说,经营模式和业务流程是持续迭代的,如果使用传统的开发模式那么很难跟上这种迭代。
以连锁餐饮品牌举例,前期只在一个城市经营,和后期扩张到全省或全国,采购流程和供应链管理必然会持续进行调整,提交一个采购工单所需填写的字段就会发生变化,同理展示的表格、详情页也要跟着调整。
这类变化往往并没有修改界面的视觉、交互、组件,仅仅是增加和减少字段数据,而用传统的收集需求再输出进行开发的模式效率非常低,所以它们就成为 Low-Code 的最佳应用场景。业务方自己配置、修改直接上线,省掉产品经理、设计师、程序员中间耗差时……
并且对于很多企业来说,只需要应用一些非常基础的功能服务和页面类型。比如我经常提到的 B 端管理系统的四个核心页面类型:
讲讲AI在B端设计上的应用方法
Collect
Low-Code 就是把常规需求标准化,并运用组件化的框架,让用户通过简单的填写和编辑就能生成出想要的页面和功能。
既然需求不复杂,功能、组件、页面、代码都可以标准化,那不用 AI 降本增效还有王法嘛?
所以,使用 AI 生成 B 端页面(不是设计稿)的工具已经在大厂内部开始应用了,开发专属大模型,再把做好的组件喂给模型,用户只要在相应的表单内填入需求,就可以快速生成出落地的页面。
并且各家大厂内部的 B 端组件库,可远远不止对外分享的这些开源框架里包含的数量,还有很多特殊的业务组件,可以让模型得到更好的训练和产出,比普通 Low-Code 模式更简单高效,大幅度提升企业内部B端产品的落地和运用效率。
从已经了解到的信息中,有一部分业务部门已经开始进入实践环节了。且随着技术的迭代,这种工具必然会越来越强大,功能越来越丰富。
所以,了解完这个趋势,设计师和前端工程师迎来大结局了?要被AI技术清洗了?现在该捧起《从0到1学习炒粉》学习了嘛?
这就是下面要讨论的内容。
B 端 AI 和设计的关联
前面做了不少铺垫,就是为了强调,适用于 Low-Code 和 AI 生成的 B 端产品,是有前提条件的,包含下面这些要素:
  • 完整成熟的前后端组件库
  • 需求使用基础做法就能实现
  • 需要经常变动调整的业务需求
  • 对设计和交互本身要求不高
而这里面最关键的东西,就是标准化。必须要知道在今天的 AI 的应用发展中,要生成出符合实际工作需要的结果,绝对不是靠输入信息以后它自己 “蒙” 出来的。为了让结果尽可能准确,那么喂给模型的数据也就要越多且越有针对性。
理论上面向 B 端的 AI 工具,只要不断提供给他新的组件、页面,就能拓展它可以实现的范围。但不管你怎么训练它,都要满足标准化的前提。
而标准化,恰恰就是国内 B 端业务的命门……
我们都知道国内 SaaS 行业现在发展非常的混乱,虽然在不同的细分领域有自己的独角兽,比如财务领域的金蝶,OA 领域的钉钉,ERP 领域的用友等等。
但是这些公司就发展状况良好利润丰厚了?24年一季度的 SaaS 头部公司业绩非常萧条,比如网上找到的统计,和国外 SaaS 头部公司的估值和利润形成鲜明的对比:
讲讲AI在B端设计上的应用方法
Collect
为什么国内 SaaS 市场那么惨淡?说到底就是在国内 B 端领域很难实现真正的标准化,而不是国内 B 端市场规模太小。
比如钉钉、飞书这样的 OA 软件已经很成熟了,但它们的实际普及程度一点都不高,而中大型企业又有各种考量,现成的不用就热衷于开发一套自己的系统,简称定制化。这就倒逼 SaaS 工具为了满足更多的企业需求,拼命叠加功能,使得这些 SaaS 工具一个比一个臃肿。
而我们前面提到的 AI 生成,想要普及同样需要面对这种困境,因为模型不管怎么做,它都是基于特定标准化下的产物,它可以满足其中一部分需求,但难以满足其它需求。尤其是国内 B 端定制化需求中,混乱、抽象、联系复杂的问题非常突出。
换句话说,国内 B 端市场的大多数系统,是非标准化的,需要产品团队在面对这些非标准的需求下做出创新和适配,就必须要考虑很多抽象的因素,领导、背景、体验、交互、周期、难度等等。这个过程不可能由业务方自己完成,且最终导出的设计结果,往往会和常规方案有很大的差异。
按常规逻辑考虑的话,那有多少组件我们整理多少组件,早晚有一天不得穷尽设计师思考范围的边界?
且不说获得不同商业项目的业务组件有多困难,如果组件之间没有更底层的思路去规范它们的设计和交互,那么硬凑到一起的项目是非常割裂的,而 AI 在短时间内没办法做到真正理解交互的逻辑并根据使用场景做理性的推理。
所以基于一套团队产出的组件必然是有限的,它们或许可以满足自己项目,但不可能满足市面上所有项目的使用需求。
还有一个很关键的疑问,就是很多人会想,一个项目中的特殊组件往往只是少数,我们用 AI 工具生成多数页面,少数进行定制和独立开发不就行了?
这思路在逻辑上很合理,但实践起来的问题非常多。举个例子比如设计稿直接生成网页这种技术,从20年前我刚了解到网页设计那天说到现在了,这个实现逻辑理应不需要 AI 的参与都能做到,中间也问世了不少产品和工具,但没有一个做成了,反而网页前端工程师都成为一个独立热门职业了(以前是 UI 写)。
原因就是作为商业项目来说,团队需要 “可控性”,机器生成代码虽然容易,但是如果要修改里面的东西怎么办?实际情况就是前端对这些外部代码深恶痛绝,因为改起来太麻烦,而越大的项目改起来难度也越高。而且这个版本的一部分你改了,下个版本工具再生成的代码要不要兼容你前面写的东西?
所以现在即使有设计稿直接生成代码的工具前端也宁愿自己写,但当他们用到第三方框架的时候,能不动框架里面的东西就不动。想要理解这个感受,只要拿这些框架的组件素材用它们的组件、自动布局形式做完一个项目,你们就会产生 —— 还不如自己重做一遍的想法。
讲讲AI在B端设计上的应用方法
Collect
所以生成工具,要不然能一次性完整满足所有需求,要不然就会因为两三成的缺口形成致命的瓶颈。当然,还有远比这些复杂的进一步因素,我就不在这里展开。
标准化无法在定制化的面前获得优势,这是国内 B 端行业面临的直接困局,当然这里有坏的影响也有好的影响。
坏的影响,就是头部 SaaS 企业没办法得到快速的发展,推高整个 B 端软件业的收入水平和吸引力,AI 生成页面这些技术适用范围小,没办法真惠及全体,行业处于反复造轮子但根本没办法停下来。
好的影响,则是头部的 SaaS 企业发展不起来,市占率就低,它们就没办像 C 端市场一样形成非常显著的马太效应,形成事实的垄断。大家重复造轮子,那么提供的就业岗位才多,才能让我国的炒粉行业没有那么卷,竞争没有那么激烈(???)……
讲讲AI在B端设计上的应用方法
Collect
如果你关注过 B 端市场足够多年,你就会明白任何企图用一种标准、方法论直接平铺整个行业的做法,注定是徒劳的,而无序、野蛮、熵增才是不变的主旋律。
但 AI 的作用短时间内完全发挥不了吗?也不是。除了前面提到的一些简单的项目之外,还有一个非常大的可能,就是中小模型的开发会变得越来越容易,而基于项目自研的界面 AI 生成工具很有可能会普及起来。虽然它们不能随心所欲生成任何需求的样式,但可以完全根据业务方的实际需要进行定制,去服务小范围的群体。
这不代表项目里面就不需要设计师,符合这套项目的标准依旧需要设计师去制定,也需要设计师持续输出特殊的页面和组件。
所以,未来很长一段时间内 AI 和 B 端 UI 设计师之间会是互补的关系,而不是替代关系。这也会对岗位要求形成进一步的影响,所以下面是我对 B 端 UI 设计师所需技能的建议:
  1. 进一步提升交互能力,尤其是基于业务认知输出交互方案的抽象思维能力
  2. 进一步巩固项目设计规范的创建能力,深入了解规范的应用和落地流程
  3. 进一步提升全局性设计思维,能提炼核心价值观并在项目中进行应用
  4. 进一步了解编程开发逻辑,能更好的配合前后端完成项目的输出提高效率
这些能力的掌握是 B 端 UI 设计师应对未来市场变化的核心竞争力,也是 AI 在短时间内绝对无法替代的东西。
不管是作为已经入行的,还是准备入行的 B 端设计新人,都不用对 AI 技术在 B 端的影响太过担心,自怨自艾,因为
如果 B 端项目的设计都那么简单的话,那么从前端框架普及的那一天起,B 端 UI 设计师就可以集体下岗,而不用等到 AI 应用的那天
换个表述方式,祝大家不会菜到那么轻易就被 AI 给取代了……
结尾
最近在做 AI 整个产业的相关笔记,尽可能的对它们进行扫盲,做完以后要是有时间,就写一个分享的专题,让大家一起涨涨见识……
103
Report
|
112
Share
相关推荐
小程序尺寸,一篇搞定
Recommanded by editor
文章
设计不設計
设计不設計
设计不設計
设计不設計
作品收藏夹
评论
in to comment
Add emoji
喜欢TA的作品吗?喜欢就快来夸夸TA吧!
推荐素材
You may like
IP形象——十二牛马
Homepage recommendation
相关收藏夹
设计不設計
设计不設計
设计不設計
设计不設計
作品收藏夹
文章
文章
文章
文章
作品收藏夹
AIGC
AIGC
AIGC
AIGC
作品收藏夹
AIGC
106
学习教程
学习教程
学习教程
学习教程
作品收藏夹
UI
UI
UI
UI
作品收藏夹
文章
文章
文章
文章
作品收藏夹
大家都在看
Log in