我們今天討論的，就是 AI 在 B 端設計方向的應用方法，以及我們應該如何應對。
大多數(shù)同學目前對 AI 應用的認識只有文生圖、對話、駕駛等領域，但 AI 應用的場景遠遠不止它們。
和頭部的明星 AI 產品、模型相比，細分市場的 AI 應用就非常沒有存在感了。比如使用 AI 進行財務的審核、飲料配方的調節(jié)、工程安全的模擬等等，它可以幫助企業(yè)節(jié)約大量的人力完成工作。
概括起來，就是一些可以通過計算機完成的（也不止）重復性勞動或標準化流程，都可以引入 AI 的技術進行降本增效。
那在 UI 設計領域中，這些重復性和標準化的工作內容有嘛？
有，但是并不會像外行或者新手想象的那么多。AI 難以覆蓋的場景我們過去的分享探討過，等等也會做進一步的說明，而這里我們先要探討的，就是能用 AI 實現(xiàn)的 B 端設計場景，具體有哪些。
我們都知道市面上現(xiàn)在有很多開源的 B 端前端框架，各個大廠前赴后繼地對它們進行更新和完善，里面包含了非常豐富的組件庫。
這些組件庫不不止是 UI 的組件，也包含了前端的對應代碼，前端工程師可以快速調用這些代碼組件而不用自己去重新寫一遍樣式和交互。
原則上，使用現(xiàn)成的組件開發(fā)就可以快速完成整套項目的前端內容，這可以給前端工程師節(jié)省大量時間。所以即使項目中有完整的設計稿，前端在開發(fā)過程中也會偷懶直接略過，直接套用框架內的組件實現(xiàn)。
這和設計師直接套用素材完成運營圖設計一樣，明明有現(xiàn)成的素材在那里，為什么要浪費一大堆時間自己重新畫一遍還是用 3D 建模渲染？同理，要是組件足夠豐富，滿足項目的需要，設計師也可以直接復用官方的組件素材，不用自己設計。
組件化思維的運用，就是項目工作標準化和重復性的根源，不僅應用在設計領域，對于前、后端開發(fā)來說同理。
基于這種思路，催生出了一種新的 SaaS 模式 —— 低代碼 Low-Code 服務。
即通過少量的代碼，或者干脆不用代碼，僅通過可視的工具和組件實現(xiàn)軟件的開發(fā)，并完成相應的配置和部署的工具。
這概念咋一看不就是建站工具？比如有贊、微店之類的，用戶可以在里面直接創(chuàng)建并配置店鋪，然后以網頁、H5 或小程序的形式發(fā)布。
但這只是最初級的應用，傳統(tǒng)的建站工具屬于幫你預制好了主要的參數(shù)和功能，用戶只能在這個范圍內做少量的自定義編輯和設置。但進階的 Low-Code，會賦予用戶更大的編輯范圍和自由度，讓用戶通過可視化的界面創(chuàng)建自己想要的產品和功能。
這類產品已經衍生出一個規(guī)模不小的市場，因為有大量的中小企業(yè)不想投入太多的精力和成本進數(shù)字化平臺的搭建上，
并希望能快速創(chuàng)建不同的管理工具來匹配企業(yè)日新月異的發(fā)展需要
。
這里要劃重點，對于一部分企業(yè)來說，經營模式和業(yè)務流程是持續(xù)迭代的，如果使用傳統(tǒng)的開發(fā)模式那么很難跟上這種迭代。
以連鎖餐飲品牌舉例，前期只在一個城市經營，和后期擴張到全省或全國，采購流程和供應鏈管理必然會持續(xù)進行調整，提交一個采購工單所需填寫的字段就會發(fā)生變化，同理展示的表格、詳情頁也要跟著調整。
這類變化往往并沒有修改界面的視覺、交互、組件，僅僅是增加和減少字段數(shù)據(jù)，而用傳統(tǒng)的收集需求再輸出進行開發(fā)的模式效率非常低，所以它們就成為 Low-Code 的最佳應用場景。業(yè)務方自己配置、修改直接上線，省掉產品經理、設計師、程序員中間耗差時……
并且對于很多企業(yè)來說，只需要應用一些非常基礎的功能服務和頁面類型。比如我經常提到的 B 端管理系統(tǒng)的四個核心頁面類型：
Low-Code 就是把常規(guī)需求標準化，并運用組件化的框架，讓用戶通過簡單的填寫和編輯就能生成出想要的頁面和功能。
既然需求不復雜，功能、組件、頁面、代碼都可以標準化，那不用 AI 降本增效還有王法嘛？
所以，使用 AI 生成 B 端頁面（不是設計稿）的工具已經在大廠內部開始應用了，開發(fā)專屬大模型，再把做好的組件喂給模型，用戶只要在相應的表單內填入需求，就可以快速生成出落地的頁面。
并且各家大廠內部的 B 端組件庫，可遠遠不止對外分享的這些開源框架里包含的數(shù)量，還有很多特殊的業(yè)務組件，可以讓模型得到更好的訓練和產出，比普通 Low-Code 模式更簡單高效，大幅度提升企業(yè)內部B端產品的落地和運用效率。
從已經了解到的信息中，有一部分業(yè)務部門已經開始進入實踐環(huán)節(jié)了。且隨著技術的迭代，這種工具必然會越來越強大，功能越來越豐富。
所以，了解完這個趨勢，設計師和前端工程師迎來大結局了？要被AI技術清洗了？現(xiàn)在該捧起《從0到1學習炒粉》學習了嘛？
前面做了不少鋪墊，就是為了強調，適用于 Low-Code 和 AI 生成的 B 端產品，是有前提條件的，包含下面這些要素：
而這里面最關鍵的東西，就是標準化。必須要知道在今天的 AI 的應用發(fā)展中，要生成出符合實際工作需要的結果，絕對不是靠輸入信息以后它自己 “蒙” 出來的。為了讓結果盡可能準確，那么喂給模型的數(shù)據(jù)也就要越多且越有針對性。
理論上面向 B 端的 AI 工具，只要不斷提供給他新的組件、頁面，就能拓展它可以實現(xiàn)的范圍。但不管你怎么訓練它，都要滿足標準化的前提。
而標準化，恰恰就是國內 B 端業(yè)務的命門……
我們都知道國內 SaaS 行業(yè)現(xiàn)在發(fā)展非常的混亂，雖然在不同的細分領域有自己的獨角獸，比如財務領域的金蝶，OA 領域的釘釘，ERP 領域的用友等等。
但是這些公司就發(fā)展狀況良好利潤豐厚了？24年一季度的 SaaS 頭部公司業(yè)績非常蕭條，比如網上找到的統(tǒng)計，和國外 SaaS 頭部公司的估值和利潤形成鮮明的對比：
為什么國內 SaaS 市場那么慘淡？說到底就是在國內 B 端領域很難實現(xiàn)真正的標準化，而不是國內 B 端市場規(guī)模太小。
比如釘釘、飛書這樣的 OA 軟件已經很成熟了，但它們的實際普及程度一點都不高，而中大型企業(yè)又有各種考量，現(xiàn)成的不用就熱衷于開發(fā)一套自己的系統(tǒng)，簡稱定制化。這就倒逼 SaaS 工具為了滿足更多的企業(yè)需求，拼命疊加功能，使得這些 SaaS 工具一個比一個臃腫。
而我們前面提到的 AI 生成，想要普及同樣需要面對這種困境，因為模型不管怎么做，它都是基于特定標準化下的產物，它可以滿足其中一部分需求，但難以滿足其它需求。尤其是國內 B 端定制化需求中，混亂、抽象、聯(lián)系復雜的問題非常突出。
換句話說，國內 B 端市場的大多數(shù)系統(tǒng)，是非標準化的，需要產品團隊在面對這些非標準的需求下做出創(chuàng)新和適配，就必須要考慮很多抽象的因素，領導、背景、體驗、交互、周期、難度等等。這個過程不可能由業(yè)務方自己完成，且最終導出的設計結果，往往會和常規(guī)方案有很大的差異。
按常規(guī)邏輯考慮的話，那有多少組件我們整理多少組件，早晚有一天不得窮盡設計師思考范圍的邊界？
且不說獲得不同商業(yè)項目的業(yè)務組件有多困難，如果組件之間沒有更底層的思路去規(guī)范它們的設計和交互，那么硬湊到一起的項目是非常割裂的，而 AI 在短時間內沒辦法做到真正理解交互的邏輯并根據(jù)使用場景做理性的推理。
所以基于一套團隊產出的組件必然是有限的，它們或許可以滿足自己項目，但不可能滿足市面上所有項目的使用需求。
還有一個很關鍵的疑問，就是很多人會想，一個項目中的特殊組件往往只是少數(shù)，我們用 AI 工具生成多數(shù)頁面，少數(shù)進行定制和獨立開發(fā)不就行了？
這思路在邏輯上很合理，但實踐起來的問題非常多。舉個例子比如設計稿直接生成網頁這種技術，從20年前我剛了解到網頁設計那天說到現(xiàn)在了，這個實現(xiàn)邏輯理應不需要 AI 的參與都能做到，中間也問世了不少產品和工具，但沒有一個做成了，反而網頁前端工程師都成為一個獨立熱門職業(yè)了（以前是 UI 寫）。
原因就是作為商業(yè)項目來說，團隊需要 “可控性”，機器生成代碼雖然容易，但是如果要修改里面的東西怎么辦？實際情況就是前端對這些外部代碼深惡痛絕，因為改起來太麻煩，而越大的項目改起來難度也越高。而且這個版本的一部分你改了，下個版本工具再生成的代碼要不要兼容你前面寫的東西？
所以現(xiàn)在即使有設計稿直接生成代碼的工具前端也寧愿自己寫，但當他們用到第三方框架的時候，能不動框架里面的東西就不動。想要理解這個感受，只要拿這些框架的組件素材用它們的組件、自動布局形式做完一個項目，你們就會產生 —— 還不如自己重做一遍的想法。
所以生成工具，要不然能一次性完整滿足所有需求，要不然就會因為兩三成的缺口形成致命的瓶頸。當然，還有遠比這些復雜的進一步因素，我就不在這里展開。
標準化無法在定制化的面前獲得優(yōu)勢，這是國內 B 端行業(yè)面臨的直接困局，當然這里有壞的影響也有好的影響。
壞的影響，就是頭部 SaaS 企業(yè)沒辦法得到快速的發(fā)展，推高整個 B 端軟件業(yè)的收入水平和吸引力，AI 生成頁面這些技術適用范圍小，沒辦法真惠及全體，行業(yè)處于反復造輪子但根本沒辦法停下來。
好的影響，則是頭部的 SaaS 企業(yè)發(fā)展不起來，市占率就低，它們就沒辦像 C 端市場一樣形成非常顯著的馬太效應，形成事實的壟斷。大家重復造輪子，那么提供的就業(yè)崗位才多，才能讓我國的炒粉行業(yè)沒有那么卷，競爭沒有那么激烈（？？？）……
如果你關注過 B 端市場足夠多年，你就會明白任何企圖用一種標準、方法論直接平鋪整個行業(yè)的做法，注定是徒勞的，而無序、野蠻、熵增才是不變的主旋律。
但 AI 的作用短時間內完全發(fā)揮不了嗎？也不是。除了前面提到的一些簡單的項目之外，還有一個非常大的可能，就是中小模型的開發(fā)會變得越來越容易，而基于項目自研的界面 AI 生成工具很有可能會普及起來。雖然它們不能隨心所欲生成任何需求的樣式，但可以完全根據(jù)業(yè)務方的實際需要進行定制，去服務小范圍的群體。
這不代表項目里面就不需要設計師，符合這套項目的標準依舊需要設計師去制定，也需要設計師持續(xù)輸出特殊的頁面和組件。
所以，未來很長一段時間內 AI 和 B 端 UI 設計師之間會是互補的關系，而不是替代關系。這也會對崗位要求形成進一步的影響，所以下面是我對 B 端 UI 設計師所需技能的建議：
-
進一步提升交互能力，尤其是基于業(yè)務認知輸出交互方案的抽象思維能力
-
進一步鞏固項目設計規(guī)范的創(chuàng)建能力，深入了解規(guī)范的應用和落地流程
-
進一步提升全局性設計思維，能提煉核心價值觀并在項目中進行應用
-
進一步了解編程開發(fā)邏輯，能更好的配合前后端完成項目的輸出提高效率
這些能力的掌握是 B 端 UI 設計師應對未來市場變化的核心競爭力，也是 AI 在短時間內絕對無法替代的東西。
不管是作為已經入行的，還是準備入行的 B 端設計新人，都不用對 AI 技術在 B 端的影響太過擔心，自怨自艾，因為
如果 B 端項目的設計都那么簡單的話，那么從前端框架普及的那一天起，B 端 UI 設計師就可以集體下崗，而不用等到 AI 應用的那天
。
換個表述方式，祝大家不會菜到那么輕易就被 AI 給取代了……
作者：酸梅干超人
鏈接：https://www.zcool.com.cn/article/ZMTYzNzg4MA==.html
來源：站酷
著作權歸作者所有。商業(yè)轉載請聯(lián)系作者獲得授權，非商業(yè)轉載請注明出處。
