最近一次方案評審評審人指著我投出來的服務(wù)調(diào)用圖說“你這張圖根本看不出重點而且這些箭頭到底是從哪發(fā)出來的”我下意識想反駁但低頭看了一眼自己那三十二個節(jié)點、大小不一的方框、七種顏色的連線話咽了回去。信息全對畫法不對。從那之后我把“畫圖”這件事正式改名為“圖表設(shè)計”diagram-design并且意識到它根本不是繪圖技能而是溝通技能。這篇內(nèi)容想分享的是我在多輪架構(gòu)評審、方案輸出和團(tuán)隊文檔共建過程中沉淀下來的圖表設(shè)計經(jīng)驗。從信息分層、工具選型、繪制規(guī)范到真實項目里的翻車記錄和模板化維護(hù)適合正在做系統(tǒng)設(shè)計、技術(shù)方案或產(chǎn)品流程圖的讀者。如果你也畫過“信息齊但沒人愛看”的圖這篇文章應(yīng)該能幫上忙。1. 圖表設(shè)計這個項目到底在解決什么問題1.1 為什么大部分技術(shù)方案圖一眼看去像草稿早幾年我做平臺架構(gòu)梳理時最大的困惑不是畫不出圖而是畫出來的圖沒人愿意細(xì)看。節(jié)點大小全靠手感服務(wù)方框有的胖有的瘦連線從節(jié)點正下方拉出來繞了半圈才找到目標(biāo)顏色隨心挑紅色代表服務(wù)紅色又代表告警。每張圖都是獨立風(fēng)格放在一起沒有任何統(tǒng)一的視覺語言。我把這類問題歸為“草稿感”圖上信息其實都在但閱讀者需要在腦內(nèi)重新做一次分類和路徑解析才能看懂。這中間消耗的認(rèn)知成本就是實打?qū)嵉臏贤ǔ杀尽３霈F(xiàn)草稿感的根源是大多數(shù)人動手前跳過了信息設(shè)計這一步。打開畫布就直接從第一個組件開始拖拽畫到一半發(fā)現(xiàn)右側(cè)空間不夠于是整體縮小某條線跨了三層節(jié)點為了不讓它穿過文字又繞了個大彎。所有調(diào)整都是局部反應(yīng)式的結(jié)果自然是一張結(jié)構(gòu)松散、層級混亂的圖。后來我把繪圖流程拆成“信息架構(gòu) → 布局規(guī)劃 → 視覺設(shè)計 → 細(xì)節(jié)標(biāo)注”四步每步都有明確產(chǎn)出這種草稿感才基本消失。這也是這篇文章想傳遞的核心方法。1.2 設(shè)計圖表的三個核心目標(biāo)可讀、可溯、可維護(hù)整理這套方法的時候我逐漸把一張圖的評價標(biāo)準(zhǔn)收斂成三個詞可讀、可溯、可維護(hù)?？勺x性就是“三秒定律”讀者掃一眼圖能不能在幾秒內(nèi)判斷出主干結(jié)構(gòu)。比如一張支付鏈路圖第一反應(yīng)應(yīng)該是“發(fā)起方 → 網(wǎng)關(guān) → 外部渠道”這條主線而不是先被左下角某個節(jié)點的顏色吸引。達(dá)成可讀性靠的是視覺層級粗細(xì)、深淺、留白、對齊全部在服務(wù)主干信息?？勺匪菪允侵笀D中每個元素都有明確歸屬和含義。節(jié)點顏色代表什么、實線和虛線代表什么、帶箭頭與不帶箭頭的線有什么區(qū)別圖例必須說明而且要全局一致?？勺匪菪圆畹膱D讀者經(jīng)常需要停下來問“這條虛線是什么意思”閱讀節(jié)奏就被打斷了?？删S護(hù)性則是給三個月后的自己留后路。架構(gòu)圖總要修改如果節(jié)點坐標(biāo)、樣式完全散落在畫布上每次修改都是一次推倒重來。把組件模板化、圖層命名規(guī)范化、源文件歸檔好后續(xù)維護(hù)成本能下降一個量級。這三個目標(biāo)聽著抽象落地時每一環(huán)都有細(xì)節(jié)接下來我按完整的實戰(zhàn)順序展開。2. 圖前準(zhǔn)備先設(shè)計信息層級再動手畫2.1 動筆前先寫一句話回答三個問題現(xiàn)在我的習(xí)慣是畫圖前先寫一句話回答三個問題。首先是給誰看。是給做技術(shù)評審的同事看還是給剛加入團(tuán)隊的新成員做培訓(xùn)還是給外部協(xié)作方做對接說明不同讀者決定了圖的抽象層級。給評審專家看的圖可以畫到服務(wù)內(nèi)部細(xì)節(jié)給外部對接方看的圖只需要畫清邊界和接口。其次是表達(dá)什么。是“系統(tǒng)如何處理一次請求”還是“服務(wù)之間的依賴關(guān)系”還是“某段流程在什么條件下走到異常分支”這三者對應(yīng)完全不同的圖畫法混在一起畫必亂。最后是希望讀者看完后做什么。是確認(rèn)方案可行理解接入步驟還是純介紹、沒有目的做決策的圖要突出備選項和結(jié)論做培訓(xùn)的圖要照顧閱讀順序做介紹的圖則可以適當(dāng)放寬細(xì)節(jié)。想清楚這三件事圖的主干信息就浮出來了。例如“給新成員介紹賬號服務(wù)的整體結(jié)構(gòu)”主干就是“接入層 → 業(yè)務(wù)服務(wù) → 存儲層”依賴的緩存和消息隊列放到第二層視覺重點即可。2.2 把信息拆成四類元素容器、節(jié)點、連線、標(biāo)注動手之前我把所有要呈現(xiàn)的信息拆成四類節(jié)點服務(wù)、模塊、實體、決策點這類最小信息單元容器系統(tǒng)邊界、組織邊界、環(huán)境邊界表達(dá)歸屬關(guān)系連線節(jié)點之間的關(guān)系方向表達(dá)數(shù)據(jù)流、調(diào)用流或依賴標(biāo)注對前三者的補(bǔ)充包括圖例、注釋、關(guān)鍵路徑說明。這個拆分看似基礎(chǔ)實則是防止畫圖途中“混型”的關(guān)鍵。我見過最常見的混型是把環(huán)境邊界畫成一個大色塊色塊里放一個服務(wù)節(jié)點顏色和色塊一樣讀者根本分不清哪個是邊界、哪個是組件。我自己通常先用文字清單列出每類元素每類一行。信息拆完這張圖的內(nèi)容就定稿了后面在畫布上做的是排版而不是臨時增減內(nèi)容。臨時增減是“草稿感”的重要來源。2.3 布局方向與視覺錨點先排閱讀順序信息拆完之后要做的不是馬上拖節(jié)點而是先排閱讀順序。絕大多數(shù)人的閱讀習(xí)慣是“從上到下、從左到右”技術(shù)圖最常用的三種布局方向自頂向下適合請求處理流程、分層架構(gòu)主線從頂部入口流到底部出口自左向右適合時間序列、數(shù)據(jù)流管線、發(fā)布流程核心放射圍繞中心服務(wù)的依賴圖適合表達(dá)“誰依賴誰”的結(jié)構(gòu)關(guān)系。定了方向之后還要確定視覺錨點第一眼該落在哪里。通常我會把最重要的節(jié)點放在畫布中上部偏左的位置也就是接近黃金分割的地方讓它在第一時間被看到。錨點確定后其他元素圍繞錨點展開而不是平均鋪滿畫布。我早期畫圖總喜歡把內(nèi)容“鋪滿畫布”結(jié)果讀者視線被四個角拉著跑最后靠圖例下面的注釋才能拼出主線。后來改掉這個習(xí)慣先想主線放哪里、什么是背景再想細(xì)節(jié)放哪里圖的骨架立刻清晰了。3. 工具選型與工程化配置別貪多夠用且可維護(hù)3.1 主流繪圖工具的真實體驗對比工具不是核心但選錯工具會讓人陷入“畫得很爽、維護(hù)很痛”的處境。我實際用下來把幾種常用工具的感受整理成了表格工具定位優(yōu)點不足適合場景draw.io通用繪圖上手快、免費、快捷鍵批量排版方便樣式能力有限模板需要自建架構(gòu)圖、部署圖的精細(xì)整理Excalidraw手繪風(fēng)草稿畫得爽、協(xié)作體驗好手繪風(fēng)不夠正式元素規(guī)范弱頭腦風(fēng)暴、早期草圖Mermaid代碼生成圖文本即圖、可進(jìn)版本庫、易diff復(fù)雜布局控制弱、中文排版一般時序圖、狀態(tài)圖、簡單流程圖PlantUML代碼生成圖時序和用例圖自動化強(qiáng)語法學(xué)習(xí)成本生成圖風(fēng)格偏“程序員味”時序圖、用例圖Graphviz點線圖引擎自動排布節(jié)點、減少交叉效果好樣式定制曲線陡峭依賴關(guān)系、結(jié)構(gòu)類大圖這張表不追求全面只記錄我自己的判斷邏輯開會隨手畫用Excalidraw作為文檔交付的技術(shù)圖用draw.io精細(xì)排版內(nèi)容以流程和時序為主、又希望圖能進(jìn)代碼庫走評審用Mermaid。3.2 為什么我們最終走雙軌方案團(tuán)隊最終確定的是“手動精修 代碼生成”雙軌方案。架構(gòu)圖、部署圖、全景圖這類“版式即信息”的圖用draw.io。這類圖里的分層、邊界、間距本身就在表達(dá)結(jié)構(gòu)手動排布才能完全掌控排版質(zhì)量。為了保證多人協(xié)作時風(fēng)格統(tǒng)一我建設(shè)了一套團(tuán)隊模板預(yù)置好畫布大小、字體、配色、節(jié)點樣式、圖層命名規(guī)則所有人畫圖都從模板開始而不是從空白畫布開始。時序圖、狀態(tài)圖、數(shù)據(jù)流這類“順序即信息”的圖用Mermaid寫在Markdown文檔里。這類圖改一個分支就要重排一張甚至多張圖代碼方式只要改幾行文本再生成就行非常適合頻繁變更的內(nèi)容。雙軌方案的代價是兩套語法都要熟收益是靜態(tài)圖的質(zhì)量上限和動態(tài)圖的維護(hù)成本都被控制住了。這種選擇邏輯也可以遷移到其他領(lǐng)域選工具不是選最好看的而是選“交付質(zhì)量”和“維護(hù)成本”兩頭都能接受的。4. 實操全流程從一張空白畫布到一張能交付的架構(gòu)圖4.1 畫布、柵格與字體基線先說畫布。我默認(rèn)用16:9分辨率按1920×1080或1280×720來定因為大多數(shù)評審場景是投影或共享屏幕這個比例最舒服。畫布統(tǒng)一之后多張圖放在同一篇文檔里并排看視覺上才能連貫。第二步是柵格。以draw.io為例把網(wǎng)格尺寸設(shè)為24像素并開啟“對齊到網(wǎng)格”。不要小看這個設(shè)置均勻的節(jié)點間距、對齊的邊界線都是從柵格來的。沒有柵格約束的手工排版畫到一半再看就是歪的。第三步是字體。技術(shù)方案圖里的中文我優(yōu)先用思源黑體或微軟雅黑這類現(xiàn)代無襯線字體正文用12到14像素標(biāo)題用16到18像素端口號、命令、類名這類固定寬度信息用等寬字體。整套字體在一個項目里保持固定不要一張圖換一個。4.2 配色基線主色、輔助色與語義色配色這塊我踩過大坑早期一張圖用六種顏色每種都像主色結(jié)果整張圖沒有主次。現(xiàn)在的規(guī)范是把顏色分成三層主色只選1種表達(dá)核心鏈路或核心組件讓讀者一眼鎖定重點輔助色2到3種表達(dá)不同類別的系統(tǒng)或模塊比如應(yīng)用服務(wù)、數(shù)據(jù)存儲、中間件各一個語義色紅黃綠只能用于狀態(tài)和風(fēng)險比如異常、進(jìn)行中、正常。這套體系的好處是讀者只要看過一次圖例再看團(tuán)隊任何一張圖都能立刻理解顏色含義。顏色一旦承擔(dān)統(tǒng)一語義就不再是裝飾而是信息通道。另一個容易被忽略的細(xì)節(jié)是文字對比度。淺色背景上不要使用低飽和度的淺灰文字投影環(huán)境下幾乎看不清。我自己在淺灰底上寫字會強(qiáng)制用深灰或黑色文本閱讀體驗差別非常大。4.3 節(jié)點、容器與連線的繪制規(guī)范節(jié)點的尺寸盡量統(tǒng)一最多根據(jù)內(nèi)容多少做1.25倍以內(nèi)的浮動不要忽大忽小。圓角矩形取中等圓角別過度圓潤邊框線寬統(tǒng)一2像素重點節(jié)點可以用3像素加粗并疊加主色。容器的畫法是淺底色加標(biāo)題條用來表示系統(tǒng)邊界。容器內(nèi)節(jié)點不要貼著容器邊線至少留出一個柵格單位的呼吸空間。容器標(biāo)題用16像素內(nèi)嵌節(jié)點正文用14像素層級落差要明顯才不會讓人分不清邊界和組件。連線的優(yōu)先級最高。連線盡量使用正交連線也就是直線加直角折線這是技術(shù)圖最穩(wěn)的選擇視覺上干凈曲線只用于數(shù)據(jù)流、事件流這類需要“流動感”的場景。連線方向要明確帶箭頭表示調(diào)用或數(shù)據(jù)流向指針一定指向被依賴方。線寬上普通連線用1.5像素重點鏈路用2像素這樣才能拉開層次。4.4 標(biāo)注與注釋的放置策略最后是標(biāo)注。圖例固定放在右下角注釋塊放在左下角關(guān)鍵路徑可以用淺色覆蓋框標(biāo)出但覆蓋框絕不能擋住任何連線和節(jié)點。一個很實際的經(jīng)驗是注釋永遠(yuǎn)不要離它解釋的對象太遠(yuǎn)最好用一條短虛線直接引出。否則讀者看完注釋還要回到圖上找位置閱讀成本立刻翻倍。我自己還習(xí)慣給圖編一個標(biāo)題欄寫在左上角包含圖名、日期和版本號方便評審時對圖說話。5. 真實項目里的三個翻車現(xiàn)場與排查鏈路5.1 翻車一一張網(wǎng)關(guān)架構(gòu)圖變成“毛線團(tuán)”某次我提交了一張網(wǎng)關(guān)改造方案圖圖上三十個服務(wù)節(jié)點彼此依賴關(guān)系交錯。評審人盯著圖看了半天最后說了一句“這圖我沒法看?！蔽业呐挪樗悸贩秩阶?。第一步把圖縮小到三分之一用人眼整體掃一遍看主干是否清晰。結(jié)果發(fā)現(xiàn)主線被支線打斷根本找不到入口在哪。第二步把所有節(jié)點按“接入層、核心層、外部依賴”三層歸類發(fā)現(xiàn)問題出在初始布局不同層級的服務(wù)全部平鋪在一條泳道上橫向距離很遠(yuǎn)連線自然又長又交叉。第三步重新排布為三個池子接入層在最上核心層在中間外部依賴在最下。同層內(nèi)部再按調(diào)用頻率從左到右排序。修復(fù)之后連線交叉數(shù)從17處降到3處主干一眼可見。這次翻車的教訓(xùn)是連線亂不要急著做局部挪動先回到信息分層層面去重新組織節(jié)點位置。局部微調(diào)治標(biāo)不治本重新分層才是治本。5.2 翻車二一張全景圖變成“千層餅”還有一次我想把一套完整平臺的架構(gòu)畫成一張全景圖用戶層、接入層、應(yīng)用層、領(lǐng)域?qū)?、基礎(chǔ)層、網(wǎng)絡(luò)層全部塞進(jìn)去每層還有二級組件。結(jié)果縮小時看不清名稱放大時找不到所屬層級評審時完全沒法用。排查之后我發(fā)現(xiàn)病根不在排版而在抽象層級一張圖承載了三層甚至四層抽象這是設(shè)計目標(biāo)本身出了問題。解決方案是拆分視角給不同讀者做不同的圖面向評審的圖只畫四個抽象層每層一個容器內(nèi)部不展開細(xì)節(jié)面向開發(fā)的圖單獨畫每個容器內(nèi)部的服務(wù)與依賴一張圖只覆蓋一個容器面向運維的圖單獨畫部署環(huán)境與網(wǎng)絡(luò)邊界。三張圖合起來才是完整架構(gòu)但任意一張圖都只聚焦在一個抽象層級上。后來我給自己立了規(guī)矩同一張圖里抽象層級盡量不超過兩層容器算一層容器內(nèi)的節(jié)點算第二層。5.3 翻車三PNG導(dǎo)出后在大屏上糊成一片某次評審前我把架構(gòu)圖導(dǎo)出成PNG發(fā)給對方。會議室大屏一放文字邊緣發(fā)虛細(xì)線全部消失。那次的排查鏈路比較典型。第一步確認(rèn)不是屏幕問題。筆記本上放大到200%看還是虛的說明是位圖本身分辨率不足。第二步檢查導(dǎo)出設(shè)置。發(fā)現(xiàn)當(dāng)時導(dǎo)出PNG的縮放比例只有1倍1920×1080的畫布導(dǎo)出后就是1920像素寬放到大屏上細(xì)節(jié)全部丟失。第三步改成導(dǎo)出SVG。SVG是矢量格式文字是真正的文本和曲線無論放大多少倍都不會虛化。那次之后團(tuán)隊約定改成兩條評審交付優(yōu)先用PDF或SVG禁止直接發(fā)PNG如果平臺只收位圖PNG的最小寬度像素要按目標(biāo)屏幕做倍率換算不能隨手導(dǎo)出一張。這個翻車也解決了字體問題SVG里沒嵌入字體時換一臺機(jī)器就可能替換字體、導(dǎo)致排版變化。所以涉及特殊字體的圖導(dǎo)出前要做字形轉(zhuǎn)曲或者嵌入字體子集。6. 讓圖表資產(chǎn)像代碼一樣被維護(hù)6.1 模板化、組件化與圖層命名規(guī)范團(tuán)隊圖表數(shù)量多了以后最痛苦的事是“一個通用需求改動導(dǎo)致所有圖都要跟著動”。這個問題的解法是把圖表的元素當(dāng)成代碼里的組件來維護(hù)。我在draw.io里建了組件庫服務(wù)節(jié)點、數(shù)據(jù)庫節(jié)點、消息隊列節(jié)點、容器框、各種箭頭、異常標(biāo)記等全部做成可拖拽的模板。模板的默認(rèn)樣式統(tǒng)一維護(hù)。畫新圖時從組件庫里拖組件而不是復(fù)制一張舊圖再刪改內(nèi)容。復(fù)制舊圖的方式很容易留下歷史元素圖層會越來越臟。圖層命名規(guī)范則參考了CSS的命名思路拆成三段層級、模塊名、元素描述。例如一條網(wǎng)關(guān)節(jié)點的圖層名可以寫成“L1_PAYMENT_GATEWAY_NODE”。命名越清晰后續(xù)協(xié)作時別人越容易查找和修改。模板化帶來的額外紅利是需要調(diào)整組件樣式時可以通過批量樣式替換一次生效不需要逐張圖手動改。這也是圖表資產(chǎn)不會像散裝圖片那樣快速腐爛的關(guān)鍵。6.2 讓圖表進(jìn)版本庫像代碼一樣被審查最后一步我把圖表源文件放進(jìn)了項目的版本庫而不是存在個人電腦或聊天軟件的傳輸記錄里。流程是draw.io的源文件以XMI格式存入Git倉庫Mermaid的圖直接用Markdown源碼存儲每次架構(gòu)變更都伴隨圖表的變更評審時圖和代碼一起看凡是圖上與代碼不一致的地方評審中直接標(biāo)出來絕不接受“圖先大略畫著代碼以后再對”的說法。有人覺得這套流程麻煩我的經(jīng)驗是圖表一旦不納入版本管理三個月后就會變成一張“沒人敢信的歷史截圖”。把圖當(dāng)代碼審查、當(dāng)代碼演進(jìn)圖表資產(chǎn)才能真正變成團(tuán)隊的知識資產(chǎn)而不是一次性的溝通草稿。走到這一步再回頭看“diagram-design”這個項目名它對我來說已經(jīng)不只是一種技巧或工具而是一套工程習(xí)慣先想清楚信息層級再選擇工具和布局用統(tǒng)一規(guī)范約束視覺表達(dá)最后把圖表納入版本體系持續(xù)演進(jìn)。最后再分享一個小習(xí)慣每張圖交付之前我都會做一次“三個月后測試”想象三個月后的自己或者一個完全沒參與項目的新同事只看這張圖、不看任何解釋能不能說出這張圖想表達(dá)什么。如果答案是否定的那問題多半不在繪圖技巧而在信息架構(gòu)沒理清。這個自測非常簡單但它幫我攔下了很多無效圖表。圖表設(shè)計這件事做到最后拼的不是軟件熟練度而是對信息層級的敏感度和對讀者的體諒。希望這套從規(guī)劃、繪制到維護(hù)的經(jīng)驗?zāi)茏屇愕膱D紙少一點“草稿感”多一點“一次就能讀懂”的確定性。