1. 從一張草圖到一套系統(tǒng)diagram-design 到底在解決什么問題第一次看到 diagram-design 這個詞很多人會以為它只是“畫圖”的另一種說法。但如果你真正在技術(shù)團隊、產(chǎn)品團隊或者咨詢項目里待過就會明白畫圖本身從來不是難點難的是讓圖變成一種可復(fù)用、可協(xié)作、可維護的溝通資產(chǎn)。diagram-design 的核心不是教你用某個工具拖幾個框、連幾條線而是建立一套從信息結(jié)構(gòu)到視覺表達的完整設(shè)計方法。我最初接觸這個方向是因為一個跨部門項目。當時后端、前端、數(shù)據(jù)、運維四個角色坐在一起每個人嘴里說的“系統(tǒng)架構(gòu)”都不一樣。后端畫的是服務(wù)調(diào)用關(guān)系前端畫的是頁面跳轉(zhuǎn)邏輯數(shù)據(jù)畫的是表關(guān)聯(lián)運維畫的是部署拓撲。四張圖放在一起沒有一張是錯的但沒有一張能讓大家對齊。問題出在哪出在圖的“設(shè)計”缺位。大家只是在記錄自己腦子里的東西而不是在設(shè)計一個能讓別人理解的視覺系統(tǒng)。diagram-design 要解決的就是這個問題。它把“畫圖”拆成三個層次第一層是信息層你要先想清楚這張圖要回答什么問題哪些信息是主干哪些是噪音第二層是結(jié)構(gòu)層用什么樣的布局、分組、層級來組織這些信息第三層才是視覺層用什么顏色、線型、圖標、字體來強化結(jié)構(gòu)。大多數(shù)人一上來就跳到第三層結(jié)果就是圖很漂亮但沒人看得懂。這套方法適合誰我總結(jié)下來有三類人最需要一是技術(shù)方案的設(shè)計者比如架構(gòu)師、技術(shù)負責人他們需要用圖來對齊團隊認知二是產(chǎn)品與項目的推動者比如產(chǎn)品經(jīng)理、項目經(jīng)理他們需要用圖來梳理流程和邊界三是任何需要把復(fù)雜信息講清楚的人比如技術(shù)博主、培訓講師、咨詢顧問。哪怕你只是偶爾寫文檔、做匯報掌握 diagram-design 的思路也能讓你的表達效率提升一個檔次。提示不要一上來就打開繪圖工具。先用紙筆或者純文本把信息結(jié)構(gòu)列出來這一步省不得。2. 核心思路拆解為什么大多數(shù)技術(shù)圖都“不好看又不好用”2.1 信息過載一張圖想講完所有事結(jié)果什么都講不清我見過太多“大而全”的架構(gòu)圖。一張圖里塞了二十多個服務(wù)、三十多條連線、十幾種顏色旁邊還密密麻麻標注了各種協(xié)議和端口。畫的人很辛苦看的人很痛苦。這種圖的根本問題是設(shè)計者沒有做“信息取舍”。diagram-design 的第一原則就是一張圖只回答一個核心問題。比如你要畫一個“用戶登錄流程”那這張圖的核心問題就是“請求經(jīng)過了哪些環(huán)節(jié)每個環(huán)節(jié)做了什么判斷”。至于數(shù)據(jù)庫表結(jié)構(gòu)、緩存過期策略、日志采集方式這些都不是這張圖要回答的。你可以用另一張圖去講數(shù)據(jù)模型用第三張圖去講部署。把信息拆開每張圖只承擔一個明確的溝通任務(wù)這才是專業(yè)做法。具體怎么判斷信息該不該留我常用一個“三秒測試”把圖給一個不熟悉這個系統(tǒng)的同事看三秒然后問他“這張圖在講什么”。如果他說不出來說明主干信息不夠突出如果他說出來的和你想表達的偏差很大說明結(jié)構(gòu)有問題。這個測試比任何理論都管用。2.2 結(jié)構(gòu)混亂沒有分組和層級讀者只能自己猜信息選好了接下來是結(jié)構(gòu)。很多人畫圖是“想到哪畫到哪”模塊之間沒有明確的分組層級之間沒有清晰的邊界。讀者看的時候只能靠位置和連線去猜這兩個框是一伙的嗎這個箭頭是主流程還是異常分支diagram-design 強調(diào)用“容器”和“對齊”來表達結(jié)構(gòu)。容器就是視覺上的分組比如用一個淺色背景框把同一層的服務(wù)圈起來或者用一條虛線把異步流程隔開。對齊則是讓同一層級的元素在視覺上保持一致的間距和大小這樣讀者一眼就能看出“這幾個是并列的”。我自己的經(jīng)驗是先把所有元素按邏輯分組列出來再決定用什么樣的容器去表達這些組最后才去調(diào)整位置和連線。這里有個很實用的技巧用“縮進”來思考。就像寫代碼一樣主流程不縮進子步驟縮進一層異常分支再縮進一層。把這個縮進關(guān)系映射到圖上就是從左到右或者從上到下的層級布局。你會發(fā)現(xiàn)很多混亂的圖本質(zhì)上是因為設(shè)計者沒有想清楚邏輯上的縮進關(guān)系。2.3 視覺噪音顏色和線型用得太隨意反而干擾理解視覺層是最容易被過度設(shè)計的地方。我見過有人用七種顏色來區(qū)分不同的服務(wù)結(jié)果讀者根本記不住哪種顏色代表什么。還有人用各種虛線、點線、粗細線但沒有任何圖例說明讀者只能猜。diagram-design 的視覺原則是顏色和線型必須承載明確的語義而且語義數(shù)量要克制。一般來說一張圖里的顏色不要超過四種線型不要超過三種。比如你可以規(guī)定藍色代表同步調(diào)用橙色代表異步消息灰色代表外部依賴紅色代表異常路徑。這樣讀者看一遍圖例就能記住后面看圖就順暢了。還有一個容易被忽略的點是文字。很多人喜歡在框里寫很長的文字甚至把一段話塞進去。正確的做法是框里只寫核心名詞詳細說明放在圖外的注釋或者配套文檔里。圖是用來建立整體認知的不是用來替代文檔的。如果你發(fā)現(xiàn)某個框里的文字超過一行就要考慮是不是該把信息拆到另一張圖或者另一個層級。注意不要為了“好看”而加陰影、漸變、立體效果。這些裝飾性元素會分散注意力而且在不同設(shè)備上顯示效果不可控。扁平、干凈、高對比才是技術(shù)圖的正道。3. 實操過程從零設(shè)計一張可復(fù)用的系統(tǒng)架構(gòu)圖3.1 第一步明確圖的類型和溝通目標動手之前先問自己三個問題這張圖給誰看他們最關(guān)心什么看完之后他們要做什么決策這三個問題的答案決定了圖的類型和詳細程度。比如給管理層看的圖重點是業(yè)務(wù)價值和系統(tǒng)邊界不需要出現(xiàn)具體的服務(wù)名和端口號給開發(fā)團隊看的圖重點是模塊職責和接口關(guān)系需要精確到服務(wù)級別給運維團隊看的圖重點是部署單元和網(wǎng)絡(luò)區(qū)域需要標注節(jié)點和協(xié)議。我通常會先在一張紙上寫下“這張圖要回答的三個問題”然后所有設(shè)計決策都圍繞這三個問題展開。圖的類型也決定了布局方式。流程圖適合從左到右或者從上到下架構(gòu)圖適合分層比如接入層、邏輯層、數(shù)據(jù)層時序圖適合展示交互順序狀態(tài)圖適合展示生命周期。選錯類型后面怎么調(diào)都別扭。我的經(jīng)驗是如果信息之間有明確的時間順序就用流程圖或時序圖如果信息之間是包含和并列關(guān)系就用架構(gòu)圖或思維導(dǎo)圖。3.2 第二步用純文本搭建信息骨架這一步是整個流程里最關(guān)鍵的但大多數(shù)人會跳過。我習慣用縮進列表把所有元素列出來就像寫大綱一樣。比如用戶端移動應(yīng)用網(wǎng)頁端接入層網(wǎng)關(guān)負載均衡邏輯層用戶服務(wù)訂單服務(wù)支付服務(wù)數(shù)據(jù)層主數(shù)據(jù)庫緩存消息隊列這個列表就是圖的骨架。你會發(fā)現(xiàn)一旦用文本把層級關(guān)系寫清楚后面畫圖只是把這個結(jié)構(gòu)“翻譯”成視覺元素而已。而且文本骨架有個好處方便評審和修改。你可以在文檔里讓同事直接改這個列表比改圖快得多。在這個階段還要確定元素之間的連線關(guān)系。我通常會在列表旁邊用箭頭標注比如“用戶端 - 網(wǎng)關(guān)HTTPS 請求”“訂單服務(wù) - 消息隊列異步寫入”。這些標注后面會變成圖上的連線標簽。不要小看這些標簽它們承載了圖里最重要的信息誰和誰交互用什么方式交互。3.3 第三步選擇布局和容器策略骨架有了接下來決定布局。對于分層架構(gòu)我推薦“從上到下”或者“從左到右”的層級布局。從上到下適合展示“請求自上而下流動”從左到右適合展示“數(shù)據(jù)自左向右處理”。兩種都可以關(guān)鍵是保持一致不要一會兒從上到下一會兒從左到右。容器策略上我常用三種背景框、分組標簽、邊界線。背景框適合表達“這些元素屬于同一個邏輯單元”比如“邏輯層”用一個淺灰背景框圈起來分組標簽適合表達“這些元素是同一類”比如在框的左上角寫一個“數(shù)據(jù)層”的標簽邊界線適合表達“這里有一個明確的邊界”比如用虛線表示“系統(tǒng)邊界”或者“信任邊界”。這里有個細節(jié)容器的層級不要超過三層。超過三層讀者就會迷失。如果你發(fā)現(xiàn)需要四層才能表達清楚那說明這張圖承載的信息太多了應(yīng)該拆成兩張圖。我自己的經(jīng)驗是一張圖里最多出現(xiàn)“系統(tǒng) - 模塊 - 服務(wù)”三層再往下就應(yīng)該用另一張圖去展開。3.4 第四步視覺編碼與圖例設(shè)計到了視覺層先定圖例再畫圖。圖例就是“顏色和線型的含義說明”。我通常會在圖的角落放一個小圖例列出所有用到的顏色和線型。比如視覺元素含義藍色實線同步調(diào)用橙色虛線異步消息灰色實線數(shù)據(jù)讀寫紅色虛線異常路徑淺灰背景同一邏輯層定好圖例之后畫圖的時候就嚴格遵守不要隨意增加新的顏色或線型。如果發(fā)現(xiàn)某個元素找不到對應(yīng)的圖例要么修改圖例要么重新思考這個元素是否該出現(xiàn)在這張圖里。字體和字號也有講究。我一般用無襯線字體字號控制在三檔標題最大模塊名中等注釋最小。不要用超過三檔字號否則視覺層級會亂。顏色上背景用白色或極淺的灰色元素用高對比度的顏色文字用深灰或黑色。避免用純黑和純白因為對比度太高長時間看容易疲勞。3.5 第五步導(dǎo)出、評審與迭代圖做完之后不要急著發(fā)布。先導(dǎo)出成圖片或者 PDF發(fā)給兩三個同事看問他們“這張圖在講什么”“有沒有看不懂的地方”。收集反饋之后再修改。我自己的經(jīng)驗是一張重要的架構(gòu)圖至少要經(jīng)過三輪評審才能定稿。第一輪看信息是否完整第二輪看結(jié)構(gòu)是否清晰第三輪看視覺是否一致。導(dǎo)出格式也有講究。如果圖要放在文檔里用 PNG 或者 SVG如果要打印用 PDF如果要嵌入網(wǎng)頁用 SVG 最好因為可以無損縮放。不要用截圖工具直接截屏那樣分辨率不夠放大就模糊了。另外導(dǎo)出的時候要檢查一下文字是否清晰連線是否對齊圖例是否完整。提示給圖起一個清晰的文件名比如“用戶登錄流程-2024-06-架構(gòu)圖-v3.png”。版本號和日期能幫你避免“最終版”“最終版2”“真正最終版”這種混亂。4. 常見問題與排查技巧實錄4.1 連線交叉太多怎么辦連線交叉是架構(gòu)圖里最常見的問題。交叉太多讀者根本追不下去。解決思路有三個第一調(diào)整元素位置把關(guān)系密切的元素放在一起第二用“跳線”或者“斷線”來表示交叉但不連接第三如果交叉實在太多說明這張圖的信息密度太高應(yīng)該拆圖。我自己的經(jīng)驗是優(yōu)先調(diào)整位置。把調(diào)用關(guān)系最頻繁的兩個模塊放在相鄰位置交叉自然就少了。如果調(diào)整位置還不行再考慮用顏色或者線型來區(qū)分不同路徑。最后才考慮跳線因為跳線本身也是一種視覺噪音。4.2 圖例和實際用色不一致這個問題很常見尤其是多人協(xié)作的時候。A 用了藍色表示同步B 用了藍色表示異步最后圖就亂了。解決辦法是在畫圖之前先把圖例定下來并且寫在一個共享文檔里。所有人畫圖都從圖例里取色不要自己臨時決定。如果用的是繪圖工具可以把圖例做成一個模板文件每次畫圖都從模板開始。還有一個技巧用“語義化命名”來管理顏色。比如不要叫“藍色”而是叫“同步調(diào)用色”不要叫“橙色”而是叫“異步消息色”。這樣即使色值有細微差異語義上也不會亂。4.3 圖太大一頁放不下圖太大通常是因為信息太多。我的建議是先問“這張圖的核心問題是什么”然后把所有不直接回答這個問題的元素刪掉。如果刪完之后還是太大就拆成“總覽圖”和“詳細圖”?？傆[圖只放最頂層的模塊和關(guān)系詳細圖去展開某個模塊的內(nèi)部結(jié)構(gòu)。拆圖的時候要保持命名一致?？傆[圖里叫“訂單服務(wù)”詳細圖里也要叫“訂單服務(wù)”不要一會兒叫“訂單模塊”一會兒叫“訂單系統(tǒng)”。命名不一致會讓讀者以為是兩個不同的東西。4.4 讀者反饋“看不懂”如果多個讀者都反饋看不懂那大概率是結(jié)構(gòu)問題而不是視覺問題。這時候不要急著改顏色和字體而是回到信息層重新檢查主干信息是否突出分組是否合理層級是否清晰我通常會找一個完全不了解這個系統(tǒng)的同事讓他看圖說話我在旁邊記錄他卡住的地方。那些卡住的地方就是需要修改的地方。還有一個容易被忽略的點圖的標題和說明。很多人只畫圖不寫標題和說明。讀者不知道這張圖在講什么自然看不懂。正確的做法是給圖起一個明確的標題比如“用戶登錄流程-同步調(diào)用視圖”然后在圖旁邊寫一段簡短的說明告訴讀者這張圖的背景和閱讀順序。4.5 常見問題速查表問題現(xiàn)象可能原因解決思路圖很亂不知道從哪看起缺少明確的主干和閱讀順序用標題和說明引導(dǎo)閱讀突出主干路徑連線交叉太多元素位置不合理或信息密度過高調(diào)整位置拆圖或用跳線顏色太多記不住視覺編碼沒有克制顏色不超過四種定圖例并嚴格遵守文字太多看不清把文檔內(nèi)容塞進了圖里框里只寫核心名詞詳細說明放圖外多人協(xié)作風格不一致缺少統(tǒng)一的模板和圖例建立模板文件統(tǒng)一命名和取色規(guī)則圖放大后模糊導(dǎo)出格式或分辨率不對用 SVG 或高分辨率 PNG避免截屏讀者理解偏差大信息結(jié)構(gòu)有問題回到文本骨架重新檢查分組和層級5. 工具選型與協(xié)作流程讓 diagram-design 真正落地5.1 工具選型的三個維度選工具不要只看“哪個好看”要看三個維度表達力、協(xié)作性、可維護性。表達力是指工具能不能畫出你需要的所有元素和連線協(xié)作性是指多人能不能同時編輯或者方便地評審可維護性是指修改起來是否方便能不能版本管理。純文本繪圖工具比如用代碼描述圖的那種表達力和可維護性很好因為圖就是文本可以放進版本控制系統(tǒng)每次修改都有記錄。但協(xié)作性差一些不寫代碼的同事參與不了。可視化工具表達力和協(xié)作性好但可維護性差改一個元素可能要手動調(diào)整半天而且版本管理困難。我自己的做法是核心架構(gòu)圖用純文本工具畫保證可維護和可追溯匯報和評審用的圖用可視化工具畫保證美觀和易讀。兩者結(jié)合既保證了工程嚴謹性又保證了溝通效果。5.2 協(xié)作流程從“一個人畫”到“一群人維護”diagram-design 要真正落地必須建立協(xié)作流程。我推薦“三階段協(xié)作法”第一階段由一個人負責搭建文本骨架確定信息結(jié)構(gòu)和分組第二階段相關(guān)角色各自認領(lǐng)自己負責的部分補充細節(jié)和連線第三階段由一個人統(tǒng)一做視覺編碼和導(dǎo)出保證風格一致。這個流程的關(guān)鍵是信息結(jié)構(gòu)和視覺編碼分開。不要讓每個人都去調(diào)顏色和位置那樣一定會亂。信息結(jié)構(gòu)可以多人協(xié)作視覺編碼必須一個人統(tǒng)一負責。這個人不需要是設(shè)計專家但必須理解圖例和布局規(guī)則。注意每次修改圖之后都要更新版本號和修改記錄。不要覆蓋舊版本因為舊版本可能在某個文檔或者匯報里被引用過。保留歷史版本能幫你追溯“為什么當時這么設(shè)計”。5.3 模板化讓每次畫圖都從“半成品”開始如果你經(jīng)常畫同類型的圖一定要做模板。模板里預(yù)置好圖例、顏色、字體、容器樣式、常用元素。每次畫新圖從模板復(fù)制一份只改內(nèi)容和連線。這樣能保證風格一致也能節(jié)省大量時間。我自己的模板里包含一個標準圖例區(qū)、一個標題區(qū)、一個說明區(qū)、三套預(yù)設(shè)的容器樣式系統(tǒng)邊界、邏輯分組、外部依賴、一套標準的連線樣式同步、異步、數(shù)據(jù)、異常。每次畫圖先選模板再填內(nèi)容。實測下來畫圖時間能減少一半以上而且風格統(tǒng)一評審的時候少了很多“這個顏色為什么和上次不一樣”的爭論。5.4 從圖到文檔讓 diagram-design 成為溝通資產(chǎn)圖不是終點圖是溝通的起點。一張好的架構(gòu)圖應(yīng)該能直接嵌入技術(shù)方案文檔、產(chǎn)品需求文檔或者運維手冊。所以畫圖的時候要考慮“這張圖后面會放在哪里”。如果放在文檔里圖的尺寸和比例要適配文檔頁面如果放在匯報里圖的重點要更突出細節(jié)要更少。我通常會在圖旁邊配一段“閱讀說明”告訴讀者這張圖的背景、閱讀順序和關(guān)鍵結(jié)論。這段說明和圖一起維護圖改了說明也要改。這樣即使圖本身有細節(jié)調(diào)整讀者也能快速理解圖的意圖。時間長了這些圖和說明就變成了團隊的溝通資產(chǎn)新成員入職的時候看一遍圖就能快速了解系統(tǒng)全貌。6. 進階技巧讓圖真正“活”起來6.1 用“視圖”而不是“一張圖”來表達復(fù)雜系統(tǒng)復(fù)雜系統(tǒng)不可能用一張圖講清楚。正確的做法是設(shè)計一組“視圖”每個視圖回答一個特定問題。比如上下文視圖回答“系統(tǒng)邊界在哪里”容器視圖回答“系統(tǒng)由哪些模塊組成”組件視圖回答“模塊內(nèi)部如何實現(xiàn)”部署視圖回答“系統(tǒng)如何部署”。這組視圖合在一起才是完整的系統(tǒng)描述。每個視圖之間要保持一致性。上下文視圖里叫“訂單系統(tǒng)”容器視圖里也要叫“訂單系統(tǒng)”。視圖之間的元素要有映射關(guān)系讀者可以從一個視圖跳到另一個視圖逐步深入。這種“視圖組”的設(shè)計方法比一張大圖有效得多。6.2 用“顏色語義”建立跨圖的統(tǒng)一語言如果你畫的圖不止一張那顏色語義就特別重要。我建議在團隊里建立一套“顏色語義規(guī)范”比如藍色永遠代表同步調(diào)用橙色永遠代表異步消息綠色永遠代表數(shù)據(jù)存儲紅色永遠代表異常或告警。這套規(guī)范一旦建立所有圖都遵守讀者看任何一張圖都能快速理解。這套規(guī)范不需要很復(fù)雜四到六種顏色就夠了。關(guān)鍵是一致性和克制。不要今天用藍色表示同步明天用藍色表示數(shù)據(jù)。一旦語義混亂圖的價值就大打折扣。6.3 用“漸進式披露”降低閱讀門檻一張圖里信息太多讀者會望而生畏。解決辦法是“漸進式披露”先給一個總覽圖只放最頂層的模塊和關(guān)系然后給每個模塊一張詳細圖展開內(nèi)部結(jié)構(gòu)最后給關(guān)鍵流程一張時序圖展示交互細節(jié)。讀者可以按需深入不需要一開始就面對所有細節(jié)。這種分層設(shè)計也方便不同角色的讀者各取所需。管理層看總覽圖就夠了開發(fā)看詳細圖運維看部署圖。同一套圖服務(wù)不同角色這才是 diagram-design 的真正價值。6.4 定期回顧和更新圖不是畫完就完了系統(tǒng)在演進圖也要跟著更新。我建議每季度做一次“圖回顧”檢查所有圖是否還準確是否有過時的元素是否有新的模塊需要補充?；仡櫟臅r候順便清理一下不再使用的圖避免文檔里堆滿過時信息。更新圖的時候要記錄修改原因。比如“2024年6月訂單服務(wù)拆分為訂單服務(wù)和履約服務(wù)更新容器視圖”。這些記錄能幫后來的人理解圖的演變過程也能避免“為什么這里多了一個服務(wù)”的困惑。7. 我踩過的坑和總結(jié)出的經(jīng)驗7.1 不要追求“一張圖講完所有事”這是我早期最大的坑?？傁胗靡粡垐D把所有東西都畫進去結(jié)果圖越畫越大越畫越亂最后連自己都看不懂。后來我強迫自己“一張圖只回答一個問題”圖反而清晰了溝通效率也高了。現(xiàn)在我看到那種密密麻麻的“大圖”就知道設(shè)計者還沒想清楚要表達什么。7.2 先定圖例再畫圖這個習慣幫我省了很多時間。以前畫圖是邊畫邊想顏色畫到一半發(fā)現(xiàn)顏色不夠用又回頭改前面的?，F(xiàn)在我先花五分鐘定圖例把顏色和線型的含義寫下來然后嚴格按照圖例畫。畫的過程中如果需要新顏色先停下來想“這個新顏色代表什么語義”想清楚了再加。這樣畫出來的圖一致性很好評審的時候也少了很多“這個顏色什么意思”的問題。7.3 文本骨架比繪圖技巧更重要我見過很多繪圖技巧很好的人畫出來的圖很漂亮但信息結(jié)構(gòu)一塌糊涂。也見過繪圖技巧一般的人用最簡單的框和線畫出來的圖卻非常清晰。區(qū)別就在文本骨架。花十分鐘用文本把信息結(jié)構(gòu)列清楚比花一小時調(diào)顏色和位置有價值得多。我現(xiàn)在畫任何圖之前都會先在文檔里寫一個縮進列表確認結(jié)構(gòu)沒問題了再打開繪圖工具。7.4 讓不懂的人看圖說話這是檢驗圖是否清晰的終極方法。找一個完全不了解這個系統(tǒng)的同事讓他看圖然后復(fù)述他理解的內(nèi)容。他卡住的地方就是圖需要修改的地方。這個方法比任何自我檢查都有效因為設(shè)計者對自己的系統(tǒng)太熟悉了很容易忽略別人看不懂的地方。7.5 圖和文檔一起維護圖不是孤立的它總是和文檔、代碼、配置一起存在。所以圖改了相關(guān)的文檔也要改。我習慣在圖旁邊放一個“關(guān)聯(lián)文檔”列表列出所有引用這張圖的地方。圖更新的時候順便檢查這些文檔是否需要同步更新。這樣能避免“圖更新了文檔還是舊的”這種常見問題。7.6 不要過度設(shè)計最后一條經(jīng)驗不要為了“專業(yè)感”而過度設(shè)計。陰影、漸變、立體效果、復(fù)雜的圖標這些在技術(shù)圖里都是噪音。干凈、扁平、高對比、結(jié)構(gòu)清晰才是技術(shù)圖應(yīng)該追求的方向。我見過太多圖視覺上很花哨但信息傳達效率很低。記住圖是用來溝通的不是用來炫技的。提示如果你不確定某個視覺元素該不該加問自己“這個元素幫助讀者理解信息了嗎”。如果答案是否定的就刪掉。8. 從 diagram-design 延伸出的更多可能8.1 用 diagram-design 思路做技術(shù)分享這套方法不僅適用于畫架構(gòu)圖也適用于做技術(shù)分享。一次好的技術(shù)分享本質(zhì)上也是一次“信息設(shè)計”先確定核心觀點再組織結(jié)構(gòu)最后才是視覺呈現(xiàn)。很多人做分享PPT 做得很漂亮但聽眾聽完不知道重點是什么。問題就出在信息層和結(jié)構(gòu)層沒有設(shè)計好。我自己的做法是先用文本列出分享的“三個核心觀點”然后圍繞每個觀點組織論據(jù)和案例最后才做 PPT。PPT 里的每一頁都只回答一個問題。這樣分享下來聽眾能記住核心觀點而不是被花哨的動畫和配色分散注意力。8.2 用 diagram-design 思路寫技術(shù)文檔技術(shù)文檔的排版和配圖也可以用 diagram-design 的思路來優(yōu)化。文檔的標題層級就是結(jié)構(gòu)層段落的分組就是容器重點標注就是視覺編碼。一篇好的技術(shù)文檔讀者掃一眼標題就能知道結(jié)構(gòu)看一段就能抓住重點。我寫文檔的時候會先列一個縮進大綱確認邏輯結(jié)構(gòu)沒問題再填充內(nèi)容。配圖的時候會確保每張圖都有明確的標題和說明圖和文互相呼應(yīng)。這樣寫出來的文檔可讀性很好也方便后續(xù)維護。8.3 用 diagram-design 思路做知識管理知識管理也可以用這套思路。把知識庫當成一個“系統(tǒng)”每個知識點是一個“元素”知識點之間的關(guān)系是“連線”。用容器來分組用標簽來分類用圖例來統(tǒng)一命名規(guī)范。這樣知識庫就不會變成一堆散亂的筆記而是一個結(jié)構(gòu)清晰、可以快速檢索的系統(tǒng)。我自己的知識庫就是按這個思路組織的頂層是領(lǐng)域中層是主題底層是具體筆記。每個筆記都有明確的標簽和關(guān)聯(lián)鏈接。找東西的時候從頂層往下鉆很快就能定位到需要的內(nèi)容。這套方法用了幾年知識庫越來越大但從來沒有亂過。8.4 用 diagram-design 思路做項目復(fù)盤項目復(fù)盤也可以用這套思路。把項目過程畫成一張流程圖標注關(guān)鍵決策點和轉(zhuǎn)折點用不同顏色區(qū)分“做對的”和“做錯的”。這樣復(fù)盤的時候一目了然不會變成流水賬。而且圖可以復(fù)用下一個項目復(fù)盤的時候可以參考上一個項目的圖看看哪些坑又踩了哪些經(jīng)驗可以復(fù)用。我自己的復(fù)盤模板里有一張標準的“項目時間線圖”標注了里程碑、決策點、風險事件和結(jié)果。每次復(fù)盤先填這張圖然后圍繞圖展開討論。這樣復(fù)盤效率很高也能積累出團隊自己的“項目模式庫”。9. 最后分享幾個我常用的實操小技巧第一個技巧用“灰度測試”檢查圖的層次。把圖導(dǎo)出成灰度圖看看在沒有顏色的情況下結(jié)構(gòu)是否依然清晰。如果灰度圖看起來一團糟說明你過度依賴顏色來表達結(jié)構(gòu)應(yīng)該加強容器和對齊。第二個技巧用“縮小測試”檢查圖的主干。把圖縮小到 25%看看還能不能看出主干路徑。如果縮小后什么都看不清說明信息密度太高應(yīng)該拆圖或者簡化。第三個技巧用“打印測試”檢查圖的細節(jié)。把圖打印出來看看文字是否清晰連線是否對齊。屏幕上看著沒問題打印出來可能就模糊了。尤其是給領(lǐng)導(dǎo)匯報的圖一定要打印測試。第四個技巧用“命名規(guī)范”管理圖的版本。文件名里包含“主題-日期-版本號”比如“用戶登錄流程-20240601-v3”。不要用“最終版”“修改版”這種模糊命名時間長了根本分不清哪個是哪個。第五個技巧用“圖例模板”統(tǒng)一團隊風格。把圖例做成一個共享文件所有人畫圖都從里面取色和取線型。這樣即使多人協(xié)作風格也能保持一致。實測下來這個小習慣能減少很多評審時的爭論。第六個技巧用“閱讀說明”降低溝通成本。每張重要的圖旁邊配一段簡短的閱讀說明告訴讀者這張圖的背景、閱讀順序和關(guān)鍵結(jié)論。這段說明不需要很長三五句話就夠但能顯著提升圖的溝通效率。這些技巧都不復(fù)雜但都是我在實際項目中反復(fù)驗證過的。diagram-design 的核心不是工具而是思維方式先想清楚要表達什么再設(shè)計結(jié)構(gòu)最后才是視覺。把這個順序搞對了圖自然就清晰了。