B 端底層設(shè)計(jì)師生存存在的困境有不少，團(tuán)隊(duì)不專(zhuān)業(yè)，需求不清晰，流程不規(guī)范之類(lèi)的問(wèn)題大家沒(méi)少吐槽。而我們今天分享的，是一個(gè)大家更關(guān)心的問(wèn)題，即：團(tuán)隊(duì)使用第三方 B 端組件庫(kù)，還要設(shè)計(jì)師有什么用？

今天的分享不是只從邏輯層面來(lái)解答，還要進(jìn)入到實(shí)際操作的角度來(lái)分享，應(yīng)該做什么。

一、組件庫(kù)的應(yīng)用認(rèn)識(shí)

要面對(duì)這個(gè)問(wèn)題，就要了解為什么團(tuán)隊(duì)要使用第三方組件庫(kù)，以及使用組件庫(kù)的優(yōu)缺點(diǎn)。

B 端討論的第三方組件庫(kù)通常是指別人開(kāi)發(fā)的前端框架，通過(guò)提前開(kāi)發(fā)好各類(lèi)前端組件和樣式的代碼，讓其它程序員直接調(diào)用，可以快速制作可視、精美、可交互的前端頁(yè)面。簡(jiǎn)單來(lái)說(shuō)就是做了套素材，方便其他人直接調(diào)用（CSV 大法好）。

目前最主流的 B 端組件庫(kù)有下面這些：

它們都是由大廠團(tuán)隊(duì)開(kāi)發(fā)，且都是開(kāi)源免費(fèi)的項(xiàng)目。因?yàn)閲?guó)內(nèi)沒(méi)有開(kāi)源的風(fēng)氣，只有大廠有這個(gè)人力資源和成本來(lái)制作。而它們之所以愿意做，當(dāng)然不是用愛(ài)發(fā)電做慈善，而是為了通過(guò)免費(fèi)的工具來(lái)捆綁不同的團(tuán)隊(duì)和開(kāi)發(fā)者，擴(kuò)大行業(yè)影響力。

既然大廠都做好了，小團(tuán)隊(duì)奉行拿來(lái)主義也是天經(jīng)地義的。因?yàn)橐惶醉?xiàng)目中的前端樣式和基礎(chǔ)組件元素實(shí)在太多了，一個(gè)個(gè)手打可能幾周過(guò)去了，一個(gè)完整的頁(yè)面還是功能都還沒(méi)做出來(lái)。

而國(guó)內(nèi) B 端項(xiàng)目的基本價(jià)值觀是 —— 先讓業(yè)務(wù)跑通了，后面再優(yōu)化細(xì)節(jié)和體驗(yàn)。效率優(yōu)先，就不會(huì)給充足的時(shí)間讓前端自己去重寫(xiě)、搭建基礎(chǔ)框架。

但選用組件庫(kù)并不真的只是找了一套免費(fèi)的素材那么簡(jiǎn)單，還需要對(duì)該組件庫(kù)使用的語(yǔ)言、語(yǔ)法、架構(gòu)、邏輯有足夠的理解，才能正確使用它。

換個(gè)角度，只要選擇了一套組件庫(kù)，那么項(xiàng)目的開(kāi)發(fā)方式就被這套組件庫(kù)捆綁，程序員需要順著這套組件庫(kù)的規(guī)則做開(kāi)發(fā)，才能實(shí)現(xiàn)項(xiàng)目的交付。

這個(gè)過(guò)程并不輕松，因?yàn)槎鄶?shù)成熟組件庫(kù)隨著跟新和迭代越來(lái)越龐大（臃腫），規(guī)則越來(lái)越復(fù)雜，一方面需要花很多時(shí)間學(xué)習(xí)，另一方面面向不同的項(xiàng)目都需要花費(fèi)額外的時(shí)間做適應(yīng)。而且調(diào)用組件看著簡(jiǎn)單，但是想要改它們，難度往往比重做一個(gè)新的還麻煩。

雖然用了別人寫(xiě)的代碼，但最終用下來(lái)有沒(méi)有節(jié)省大量時(shí)間是存疑的。所以很多項(xiàng)目的前端工程師還是疲于奔命的狀態(tài)，并不會(huì)因?yàn)橛昧说谌綆?kù)就有閑暇和設(shè)計(jì)師打磨細(xì)節(jié)和體驗(yàn)。

這里就要講到界面樣式的問(wèn)題了，組件庫(kù)自帶了組件的樣式，可以直接拼湊出不同的頁(yè)面，這個(gè)過(guò)程理論上是可以略過(guò)設(shè)計(jì)環(huán)節(jié)的，程序員直接根據(jù)產(chǎn)品需求或者原型開(kāi)發(fā)就行了。

但素材總歸是素材，參考就只是參考，想要覆蓋所有現(xiàn)實(shí)情況是不可能。不同頁(yè)面會(huì)包含的組件不一樣，復(fù)雜組件需要做調(diào)整才能滿(mǎn)足項(xiàng)目需要，或者想要的組件這里面干脆就沒(méi)有得另外找或獨(dú)立開(kāi)發(fā)。

就像網(wǎng)上找一套再全的圖標(biāo)設(shè)計(jì)素材，也很難覆蓋整套項(xiàng)目所需的所有圖標(biāo)，往往還要額外修改或者繪制。

為了應(yīng)對(duì)這種問(wèn)題，這些開(kāi)源組件庫(kù)的官方除了源代碼外，還會(huì)提供相應(yīng)的設(shè)計(jì)素材，讓設(shè)計(jì)師可以自己調(diào)用這些設(shè)計(jì)資源做出新的組合或修改新的樣式，再讓程序員進(jìn)行開(kāi)發(fā)。

理想很豐滿(mǎn)，但實(shí)踐起來(lái)也就聊勝于無(wú)，甚至可以用 "雞肋" 來(lái)形容。最深層次的矛盾，就是設(shè)計(jì)資源里的"組件"和源代碼中的"組件"是割裂的。

即組件的開(kāi)發(fā)和設(shè)計(jì)是不同步的，雖然這些框架都是大廠發(fā)布的，但說(shuō)到底它們不是直接產(chǎn)生經(jīng)濟(jì)效益的產(chǎn)品，對(duì)它的維護(hù)力度不會(huì)太高。而設(shè)計(jì)資源的維護(hù)尤其復(fù)雜，比如結(jié)合軟件的組件、變體功能做一個(gè)完整的組件，就包含了海量的設(shè)計(jì)圖層設(shè)置：

而設(shè)計(jì)軟件之間又不能直接互通（導(dǎo)入可以忽略），假設(shè)提供了 Figma 的版本，那即時(shí)、Sketch、Mastergo、Pixso、Axure 等版本，每做一個(gè)就多一倍的工作量……這就是為什么主流框架提供的設(shè)計(jì)資源總是不全的原因。

除了要制作的版本多以外，需要更新和迭代的頻率也很高。如果有看過(guò)這些開(kāi)源組件庫(kù)的更新日志，你們就會(huì)發(fā)現(xiàn)它們一直再"偷偷摸摸"地更新和迭代。

這些更新代碼部分肯定已經(jīng)先做好了，但不代表設(shè)計(jì)資源也會(huì)同步更新（包括規(guī)范說(shuō)明），因?yàn)檫@些工作量太大了，所以設(shè)計(jì)資源的最后更新時(shí)間往往遠(yuǎn)遠(yuǎn)落后于線(xiàn)上版本，設(shè)計(jì)和代碼間存在大量差異。

以 Arco 為例，目前 24 年 9 月底更新到 2.64，而 Figma 的設(shè)計(jì)資源版本是 23 年 7 月的 2.5.1。

Ant 目前則更新到 v5.2，而官方設(shè)計(jì)組件庫(kù)還停留在 21 年的 v4.0 的版本，對(duì)設(shè)計(jì)資源的維護(hù)基本放棄治療靠第三方來(lái)補(bǔ)充了……

因?yàn)閮烧卟煌?，所以即使開(kāi)發(fā)就根據(jù)設(shè)計(jì)的組件調(diào)用相同的代碼，也可能會(huì)得到不同的結(jié)果。即使程序員一開(kāi)始想跟著設(shè)計(jì)稿做，也會(huì)因?yàn)閮烧邇?nèi)容不相同而慢慢失去耐心。

到最后就更容易演變成，設(shè)計(jì)做設(shè)計(jì)的，開(kāi)發(fā)做開(kāi)發(fā)的，于是設(shè)計(jì)就成為一個(gè)被孤立得環(huán)節(jié)，開(kāi)發(fā)不根據(jù)設(shè)計(jì)稿完成工作，那么設(shè)計(jì)存在的價(jià)值是什么？自?shī)首詷?lè)嘛？

這種結(jié)果由各方面客觀因素導(dǎo)致，但不代表它是合理的、高效的，只是把問(wèn)題和矛盾進(jìn)行轉(zhuǎn)移，這個(gè)問(wèn)題不是不能解決，我們會(huì)在下面解釋。

但進(jìn)入細(xì)節(jié)前我們要先確定核心理念，那就是在使用了第三方組件庫(kù)的項(xiàng)目中，整個(gè)項(xiàng)目的前端工作流、開(kāi)發(fā)方式都要順應(yīng)這套組件庫(kù)的特性，不能只是前端程序員順應(yīng)了，而設(shè)計(jì)師是游離在體制外的干擾因素……

設(shè)計(jì)工作要融入到使用組件庫(kù)的流程中去，才能和程序員形成高效、默契的配合，總結(jié)成一句話(huà)即：

面向組件庫(kù)做設(shè)計(jì)！

很多人可能認(rèn)為完全用框架的內(nèi)容做設(shè)計(jì)毫無(wú)難度和價(jià)值，且這種方式?jīng)]辦法得到積累和進(jìn)步。這問(wèn)題不是只有設(shè)計(jì)才有，對(duì)前端工程師來(lái)說(shuō)也一樣，大家殊途同歸。但問(wèn)題是，有些前端和設(shè)計(jì)，即使給了成熟的組件庫(kù)，他們也做不好啊……

真實(shí)的項(xiàng)目工作是"解決問(wèn)題"，完成工作的需求讓項(xiàng)目能按要求交付，和根據(jù)個(gè)人的喜好以及最符合自己利益的方式去完成是截然不同的。

二、如何面向組件庫(kù)做設(shè)計(jì)

面向組件庫(kù)做設(shè)計(jì)和傳統(tǒng)的設(shè)計(jì)模式會(huì)有很大的出路，因?yàn)殚_(kāi)發(fā)不會(huì)完全根據(jù)設(shè)計(jì)稿來(lái)做，所以要啟用不同的協(xié)作方式，包含以下四個(gè)要素：

1. 建立協(xié)作共識(shí)
2. 熟悉框架內(nèi)容
3. 構(gòu)建項(xiàng)目規(guī)范
4. 確定交付模式

1. 建立協(xié)作共識(shí)

面向組件庫(kù)做設(shè)計(jì)不是設(shè)計(jì)師自己一個(gè)人的事，是需要和前端深度配合、協(xié)作才能實(shí)現(xiàn)的結(jié)果，所以前期建立共識(shí)是最重要的一環(huán)，要讓前端有這個(gè)配合的意愿。

最好在項(xiàng)目前期能和前端工程師單獨(dú)溝通，確定后續(xù)配合的方式，以及需要他們完成哪些額外的工作，包括但不限于下面這些：

1. 確定組件庫(kù)差異
2. 建立項(xiàng)目專(zhuān)屬規(guī)范
3. 確定新組件開(kāi)發(fā)流程
4. 確定界面實(shí)現(xiàn)流程

在這件事上很多設(shè)計(jì)師喜歡說(shuō)前端、開(kāi)發(fā)領(lǐng)導(dǎo)不重視設(shè)計(jì)，壓根不理你，溝通沒(méi)有用之類(lèi)得話(huà)。除了少數(shù)極端的情況，多數(shù)前端在項(xiàng)目前期是有意愿把項(xiàng)目做好的，只是很多項(xiàng)目中設(shè)計(jì)師的工作成為了前文提過(guò)的游離在體系之外的干擾……

所以想要實(shí)現(xiàn)這個(gè)目標(biāo)，就要提前表明后續(xù)要結(jié)合框架的特性做設(shè)計(jì)，為了提供給前端更可行和易于開(kāi)發(fā)的方案，節(jié)省雙方的時(shí)間，提高最終的交付質(zhì)量。

真正的職場(chǎng)協(xié)作是共贏的模式，而不是符合理論上的流程就只管自己做的爽，不管下游死活。只有雙方確定一個(gè)共贏的認(rèn)識(shí)，才會(huì)往這個(gè)方向推進(jìn)，而不是先預(yù)設(shè)對(duì)方有義務(wù)一定要盡心配合你的工作……

2. 熟悉框架內(nèi)容

第二步熟悉框架，這個(gè)熟悉不單指看完官方的規(guī)范和資源庫(kù)內(nèi)容，還要去了解代碼實(shí)現(xiàn)出來(lái)的真實(shí)組件樣式和交互是什么樣的，有哪些東西是官方說(shuō)明沒(méi)寫(xiě)或者不一樣的。

因?yàn)椴煌?xiàng)目用的組件庫(kù)不同，版本也不一樣，沒(méi)有人可以幫你整理出相關(guān)的結(jié)論，只能靠你自己去調(diào)研和分析。

而組件庫(kù)內(nèi)容很多，肯定不可能全部檢查到，所以挑一些核心的組件進(jìn)行檢查即可。比如柵格、側(cè)邊欄、表格、表單、選擇器、彈窗等，其它次要組件即使有差異問(wèn)題也不大。

檢查的方式需要程序員配合，得讓他們做一些簡(jiǎn)單的頁(yè)面，把指定的組件在頁(yè)面里羅列出來(lái)（花不了幾分鐘）。如果前端程序員對(duì)這套框架足夠熟悉，也可以讓他們直接指出哪些組件和規(guī)范中的內(nèi)容是有出入的，并展示給你看。

除了組件外，還有樣式部分也需要關(guān)注，包括色彩、字體、圖標(biāo)等，最好都讓前端程序員給你解釋下實(shí)際應(yīng)用的邏輯，以及存在的問(wèn)題。

這個(gè)階段的任務(wù)就是了解框架的真實(shí)樣式和規(guī)則，是需要前端工程師配合的，幫助設(shè)計(jì)師建立對(duì)這套組件真實(shí)應(yīng)用結(jié)果的認(rèn)識(shí)。

了解越深入，那么后續(xù)工作的開(kāi)展就會(huì)越順利。

3. 構(gòu)建項(xiàng)目規(guī)范

這里要再老生常談一點(diǎn)，那就是組件庫(kù)里展示的設(shè)計(jì)規(guī)范是 —— 這套組件庫(kù)內(nèi)包含的設(shè)計(jì)要素使用說(shuō)明，具體想要怎么用設(shè)計(jì)者自己決定。

比如這些組件庫(kù)都提供了相關(guān)的色卡，但這幾百個(gè)顏色不可能每個(gè)都會(huì)在項(xiàng)目里使用，或者按鈕也提供了幾十種樣式，不會(huì)你的項(xiàng)目"正好"全都能用上吧？

所以就算跟著組件庫(kù)設(shè)計(jì)，也要從中篩選出符合項(xiàng)目需要的元素內(nèi)容做項(xiàng)目設(shè)計(jì)。而這些篩選出來(lái)的東西，自然就是項(xiàng)目的設(shè)計(jì)規(guī)范，是一個(gè)范圍被縮小且更明確的設(shè)計(jì)標(biāo)準(zhǔn)。

我們需要?jiǎng)?chuàng)建一個(gè)新的項(xiàng)目規(guī)范文檔，并把規(guī)范內(nèi)容和信息補(bǔ)充進(jìn)去。如果對(duì)項(xiàng)目規(guī)范內(nèi)容有什么的基本認(rèn)識(shí)不夠了解的可以看之前的分享：

規(guī)范的內(nèi)容主要會(huì)包含下面這些要素：

1. 柵格/響應(yīng)
2. 框架/版式
3. 色彩
4. 字體
5. 圖標(biāo)
6. 樣式
7. 控件/組件

首先柵格/響應(yīng)，就是框架要使用的柵格系統(tǒng)和響應(yīng)式模式。官方的說(shuō)明里只解釋了柵格的應(yīng)用邏輯，但并沒(méi)有制定具體的參數(shù)，如果項(xiàng)目確定要啟用柵格和響應(yīng)式，那么前期就要定出具體的參數(shù)。

框架/版式即頁(yè)面的排版方法，包括主要頁(yè)面的布局形式、間距參數(shù)的應(yīng)用等等。這些也要盡可能從官方提供的類(lèi)型中選擇，并確定下來(lái)。

色彩則是項(xiàng)目中用的主要顏色內(nèi)容，除了有品牌色的強(qiáng)制要求，否則建議項(xiàng)目?jī)?nèi)所有顏色的應(yīng)用從官方的色卡里選，并且色彩的命名和記錄不要使用 16 進(jìn)制代碼，而是使用組件庫(kù)中色彩的專(zhuān)屬命名。

字體同理，只有強(qiáng)制需要使用其它字體的英文、數(shù)字可以獨(dú)立定義，否則完全從組件庫(kù)規(guī)范里篩選出來(lái)即可。

圖標(biāo)部分，雖然部分框架會(huì)提供自己的圖標(biāo)庫(kù)，但往往項(xiàng)目中需要的圖標(biāo)無(wú)法全部滿(mǎn)足，所以可以評(píng)估是否要使用官方的圖標(biāo)作為基礎(chǔ)圖標(biāo)，復(fù)雜的功能、導(dǎo)航、裝飾圖標(biāo)另做。

樣式指應(yīng)用的圓角、投影、透明度等設(shè)計(jì)屬性，這些同樣根據(jù)官方的標(biāo)準(zhǔn)篩選制定就可以。

而控件/組件部分則是最復(fù)雜的部分，它們的整理是在項(xiàng)目推進(jìn)的過(guò)程中逐一添加的。簡(jiǎn)單的控件可以完全使用官方的樣式來(lái)完成，但是稍微復(fù)雜的組件就另當(dāng)別論了。

一方面創(chuàng)建這些組件要根據(jù)真實(shí)的樣式來(lái)實(shí)現(xiàn)，另一方產(chǎn)品功能的實(shí)現(xiàn)，往往都包含對(duì)原有組件的調(diào)整，設(shè)計(jì)師需要在真實(shí)樣式的基礎(chǔ)上做出符合開(kāi)發(fā)邏輯的改動(dòng)。

比如表格組件，對(duì)不同列有排序的要求，但使用的組件庫(kù)里的表格沒(méi)有這個(gè)功能，那就只能選擇把排序做成表單形式放到表格外部去。

所以，對(duì)應(yīng)組件在制作中就需要和前端溝通設(shè)計(jì)的可行性，不是只從組件庫(kù)里挑出來(lái)就可以。

而組件的不同狀態(tài)，可以選擇性的制作，對(duì)于樣式、內(nèi)容改動(dòng)很小的組件，只要置入默認(rèn)的模式即可，其余的遵照系統(tǒng)默認(rèn)的設(shè)置。而改動(dòng)大的那些，則要把所有狀態(tài)都制作出來(lái)，才能被正確的開(kāi)發(fā)。

對(duì)于自定義組件同理，當(dāng)官方組件實(shí)在滿(mǎn)足不了功能需求，需要設(shè)計(jì)一些新的組件時(shí)，也要把所有狀態(tài)都制作出來(lái)，且要和開(kāi)發(fā)溝通一遍開(kāi)發(fā)的可行性。

整套設(shè)計(jì)規(guī)范的定義不止是樣式的篩選，還有非常重要的命名方式以及 DesignToken 的應(yīng)用，如果不了解的可以看我之前的掃盲：

在獨(dú)立設(shè)計(jì)的項(xiàng)目規(guī)范內(nèi)我不推薦使用太復(fù)雜的 DesignToken，但在面向組件庫(kù)設(shè)計(jì)時(shí)這些東西就需要一個(gè)不落。因?yàn)殚_(kāi)發(fā)調(diào)用樣式和組件是需要使用 DesignToken 完成的，所有應(yīng)用了官方原來(lái)的樣式和控件、組件都要在命名中和原來(lái)保持一致。

而非組件庫(kù)內(nèi)的樣式、組件，則建議使用一套新的命名體系，和原來(lái)的命名隔離開(kāi)，更容易識(shí)別和維護(hù)。這也需要和前端工程師商量，讓他們來(lái)定義 Token 的命名規(guī)則最好，我們只要執(zhí)行這個(gè)標(biāo)準(zhǔn)即可。

盡可能讓程序員在前期對(duì)這些標(biāo)準(zhǔn)組件做一次定義，和規(guī)范中的組件樣式同步，而不要放在后續(xù)一個(gè)個(gè)改，才能保證更高的效率。

4. 確定交付模式

定義完規(guī)范，就要在正式的界面設(shè)計(jì)中進(jìn)行應(yīng)用。在面向規(guī)范進(jìn)行設(shè)計(jì)時(shí)，設(shè)計(jì)稿不是作為一個(gè)標(biāo)準(zhǔn)的、讓開(kāi)發(fā)還原的樣式，而是一個(gè)應(yīng)用了哪些樣式和組件的示意。

因?yàn)檫€包含一系列的組件篩選和挑選、變更，以及交互邏輯，設(shè)計(jì)師出圖的結(jié)果就是幫程序員指定了"具體的組件類(lèi)型和樣式"，遠(yuǎn)勝過(guò)產(chǎn)品給的粗糙原型圖，這可以節(jié)省掉程序員得根據(jù)產(chǎn)品原型的空缺腦補(bǔ)這些內(nèi)容的時(shí)間精力。

作為一個(gè)示意，程序員核心關(guān)注得是頁(yè)面的內(nèi)容，以及排列、交互的方式。我們?cè)谶@里使用規(guī)范里的樣式和組件庫(kù)，他們同樣也是在開(kāi)發(fā)過(guò)程中調(diào)用這些內(nèi)容和 Token。所以頁(yè)面交付最重要的東西除了文字信息就是對(duì)規(guī)范的復(fù)用，保證組件和樣式的命名都是準(zhǔn)確可用的。

在設(shè)計(jì)標(biāo)注中，也只要圍繞在自定義樣式和組件這些新增內(nèi)容做標(biāo)注即可，確保前端不會(huì)漏看和理解錯(cuò)誤。

如果最終實(shí)現(xiàn)的效果和開(kāi)發(fā)的差異很大，我們要檢查的是項(xiàng)目規(guī)范代碼內(nèi)的準(zhǔn)確性，而不是光扣一個(gè)頁(yè)面的樣式。

同時(shí)，以開(kāi)發(fā)結(jié)果為導(dǎo)向的設(shè)計(jì)，往往也不用過(guò)于細(xì)致，因?yàn)榻M件里有什么設(shè)計(jì)、細(xì)節(jié)都是規(guī)范階段定好的，不用把時(shí)間過(guò)多的花在單一頁(yè)面的樣式優(yōu)化上。反正一開(kāi)始我們就有預(yù)期實(shí)現(xiàn)的結(jié)果和設(shè)計(jì)不一定是完全匹配的，糾結(jié)細(xì)枝末節(jié)不如去找源頭有效。

實(shí)現(xiàn)以上的工作流程，就是面向組件庫(kù)設(shè)計(jì)的方法，這可以極大的增加前端實(shí)現(xiàn)界面的速度和完成度，也能大幅度減少設(shè)計(jì)和前端之間的矛盾。

在你們真正理解完這套流程和邏輯時(shí)，就會(huì)明白與其稱(chēng)它為面向組件庫(kù)設(shè)計(jì)，不如叫面向結(jié)果做設(shè)計(jì)。

設(shè)計(jì)師是為了在有限的時(shí)間里結(jié)合前端工程師實(shí)現(xiàn)最優(yōu)的落地結(jié)果，而不是在有限的時(shí)間里讓你做出最好的設(shè)計(jì)圖……

結(jié)尾

這次分享的內(nèi)容比較超綱，需要有一定經(jīng)驗(yàn)才能理解，不要認(rèn)為只是設(shè)計(jì)層面需要搞那么麻煩。

實(shí)際上對(duì)多數(shù)使用組件庫(kù)的前端來(lái)說(shuō)完成項(xiàng)目也是一團(tuán)亂麻，它們的實(shí)際工作內(nèi)容就是 —— 用一套別人寫(xiě)的規(guī)定特別多局限性還很大的代碼，硬套進(jìn)當(dāng)前的項(xiàng)目里！一些復(fù)雜業(yè)務(wù)和需求要怎么實(shí)現(xiàn)是沒(méi)底的，只能見(jiàn)招拆招寫(xiě)一點(diǎn)是一點(diǎn)。

真實(shí)的產(chǎn)品團(tuán)隊(duì)開(kāi)發(fā)流程就是充滿(mǎn)了混亂和熵增的草臺(tái)班子，大家都在摸黑過(guò)河，新人會(huì)幻想一套童話(huà)書(shū)里才有得流程并指望大家按這套說(shuō)明書(shū)實(shí)踐，而成熟的開(kāi)發(fā)和設(shè)計(jì)要根據(jù)現(xiàn)場(chǎng)的碎片建立不同的秩序。

最后說(shuō)一點(diǎn)，這類(lèi)項(xiàng)目很多都有給設(shè)計(jì)師名額，就是因?yàn)楣芾韺?、開(kāi)發(fā)意識(shí)到前面提過(guò)的各類(lèi)設(shè)計(jì)問(wèn)題，但最后人招來(lái)了發(fā)現(xiàn)大多數(shù)設(shè)計(jì)師沒(méi)辦法解決，反而制造出更多的問(wèn)題，積累更多的矛盾……

想要增長(zhǎng)和獲得專(zhuān)業(yè)積累，就停止抱怨開(kāi)始實(shí)踐和嘗試，你們也可以把這套方案發(fā)給你們的前端，再和他們共同討論可行性。

作者：超人的電話(huà)亭