「頁面還原度」即開發工程師對設計稿的還原程度，頁面還原度的高低，直接決定從產品需求到設計實現的程度是否被準確有效的表達。

拓展閱讀

在 B 端產品中，往往更加重視產品功能的實現，頁面還原度并不被重視；但是功能實現和頁面還原并不是兩個孤立的問題，頁面還原度低，同樣會影響用戶的可用性和易用性，損失的是產品最終的輸出價值和用戶體驗，因此，B 端產品團隊同樣需要重視頁面還原度的實現。

大部分開發團隊通過 UI 走查環節解決頁面還原度低的問題，即在測試階段由 UI 設計師對產品的還原度進行走查和標注，開發工程師對問題進行修復。然而，只在 UI 走查環節解決頁面還原度問題，有以下缺陷：

1. 1. 開發周期有限，頁面還原度問題最終服從于產品功能的實現，修復時間受制于迭代周期被無限推遲，隨著問題的累積，造成開發工作量無限期增加的惡性循環
   2. 全局性的設計問題沒有得到及時修復，無形中增加了設計每次版本迭代中 UI 走查的工作量
   3. 線上頁面是設計工作的執行表現層，在走查環節進行校正，設計的工作質量難以評估和量化

因此，本文結合工作實踐以及與產品、前端、測試的深度溝通，從設計全鏈路探究產品還原度低的原因，并結合工作實踐總結提升頁面還原度的解決方案。

頁面實現還原度低的原因

1. 設計規范和設計組件庫不一致

（1）使用不同設計系統

以 Ant Design 和 Arco Design 表單組件為例，兩個設計系統的色值、間距、交互效果等都各有差異，如果設計與前端使用不同的組件庫，設計稿和線上頁面必然大相徑庭

（2）使用同一設計系統

前端工程師在開發過程中不會對所有設計元素逐一查看，更不會對比設計稿規范與設計系統默認規范是否一致，如果設計師對默認的設計規范作出調整且沒有在設計稿中作出標注，同樣會造成設計稿和線上頁面的差異

2. 前端和設計頁面實現的思考路徑不同

UI 設計師在靜態固定寬度的頁面進行設計，關注的是如何把產品需求轉化為設計語言，將設計元素科學合理的布局與排版。

前端工程師需要完成的是如何在不同分辨率的情況下，最大可能對設計稿進行還原：

以上案例展示了設計師和前端工程師對同一頁面不同的實現方式，在線上頁面寬度與設計稿一致的情況下，表單之間的橫向間距都是 65px。但是，如果頁面縮放或者在不同分辨率屏幕下展示，設計認為一行兩列表單的間距依然是 65px；而按照前端工程師的實現方式，不同分辨率下單個柵格的寬度是變化的，那么表單之間的橫向間距必然會發生動態變化。

3. 設計走查缺乏系統、動態、可追蹤機制

常規的設計走查流程，設計師對線上頁面進行截圖和標注，最后將所有標注截圖匯總給前端工程師。這樣的走查流程有以下問題：

1. 走查問題全部使用描述文字，問題無法進行分類分級管理
2. 工作完成狀態無法反饋，工作量難以追蹤，設計師需要根據前端反饋結果對所有走查問題進行二次檢查

如何提升頁面實現還原度

1. 建立一致的設計規范和組件庫

建立 B 端設計組件庫和設計規范，使用范圍不應僅局限于設計團隊內部，應達成整個團隊尤其是前端工程師和設計師的設計規范和組件庫的一致，從而實現設計稿到線上頁面輸出統一的設計語言，從根本提升設計質量和還原度。但是，統一和前端的設計規范與組件庫并非易事，需要將產品的發展階段、前端團隊開發團隊工作習慣、設計歷史原因等因素進行綜合考量，筆者結合工作實踐，設計師可以從以下方面提升與前端團隊的一致性。

（1）設計組件的選擇

設計師在接收到設計需求后，需要首先和對接的前端工程師和產品經理確認并考慮以下問題：

1. 是否有統一的設計組件庫，如果沒有，此次版本是否需要建立；
2. 當前產品的設計組件庫是什么，組件庫是否可以覆蓋當前產品的大部分需求；如果答案為是，建議繼續沿用當前的設計組件庫；
3. 當前版本是否有更換設計組件庫的需求，如果需要，更換何種組件庫。

在前面的案例中，我們看到使用不同的第三方組件庫，頁面差異很大，因此，設計師在開始初始，需要盡量和前端（或者前端和設計師）使用一致的設計組件庫

（2）設計組件庫更新機制

B 端產品業務復雜，大部分第三方設計組件庫并不能覆蓋全部的設計需求，設計師依然需要創建符合產品需求的設計組件；此外，設計師會對現有的第三方組件庫根據產品需要進行微調；設計師對設計組件庫的改造和更新，同樣需要團隊成員特別是設計師和前端工程師評審通過，保持前端工程師和設計師組件一致

（3）設計師使用組件保持克制

設計師需要充分考慮產品的可用性和用戶的學習成本，在組件的使用過程中保持克制，組件的使用需要定義明確的規則和范圍，如果僅僅因為“好看”而使用不同風格的設計組件，會極大增加開發團隊的學習成本，造成團隊成員使用組件的混亂和困惑。

（4）設計規范

制作設計規范的目的是為了統一設計內部以及與前端工程師的設計規范，提升團隊的協作效率。前端工程師根據設計規范建立公共組件庫，提升前端組件復用率，減少設計與前端的對接成本，提升工作效率。測試工程師根據設計規范建立穩定、一致的測試用例，提高測試工作效率。因此在設計規范在制定和更新過程中，需要與開發、測試充分溝通與協作，形成團隊穩定、一致的規范文檔，從根本上提升協作效率，高效完成界面的開發和驗收。

2. 設計師需要了解前端知識

設計師在設計過程中需要代入前端思維開展設計工作，雖然設計師最終交付的是一個靜態尺寸的設計稿，但是在設計各個階段，都需要充分考慮不同排版和設計元素排列在不同分辨率設備中的顯示效果，理解前端實現頁面的基本邏輯和適配規則，將設計語言轉化為前端規則，最大程度實現頁面的還原。

1. 制定設計規范，與前端同步模版頁面的設計規范和規則，例如柵格規范，適配規則
2. 在設計過程中，考慮設計元素排版與布局在不同分辨率的展示效果，與前端溝通，采用何種方式最大程度實現不同分辨率下的頁面高度還原
3. 設計走查過程中，理解前端的實現方式，分析頁面實現的合理性，與前端工程師解決走查問題的合理解決方案。

如果有設計同學的設計工具是 Figma，強烈建議大家學習 Figma 的自動布局和智能組件制作功能，Figma 自動布局的實現方式和前端實現邏輯是高度一致，使用自動布局思維進行設計，可以進一步提升和前端的溝通效率。

拓展閱讀

3. 設計思想宣講

在設計走查工作中，經常會遇到一些這樣的情況，前端工程師不理解為什么設計師對一個字體的字號、字重、不同元素的間距反復強調，設計稿和線上頁面不仔細查看，并不能看出區別，為何設計師對于這些像素級的差異要“錙銖必較”？諸如此類的問題，其根本原因在于團隊成員并不理解設計師的工作，停留于設計師就是把設計組件擺的“好看”的認知誤區。

設計師的本質工作是為了解決問題，使用不同的設計方法，背后隱含的是設計師對產品不同信息的處理和傳達，因此，設計師有必要和團隊成員主動溝通，解釋設計師在設計工作中對不同信息的處理邏輯，設計師如何將文字需求轉化為視覺語言準確傳達給用戶。不同專業對同一事物的關注度和敏感度不同，例如需求評審過程中，設計關注排版，后端關注數據，測試關注異常情況。因此，對同一頁面感知度團隊成員差異巨大，這樣的結果可能會導致設計師對信息的傳達在頁面上線后大打折扣，因此，設計師必須和團隊成員，尤其是前端工程師分享在設計師在設計過程中，是如何將需求內容轉化為視覺語言傳達給用戶的。

4. 科學合理的設計走查流程

上文筆者介紹了常規設計走查流程帶來的諸多問題，經過不斷地實踐和探索，對設計走查過程不斷優化，形成了一套更加高效的的設計走查流程

（1）設計工具的選擇

走查工具

工欲善其事，必先利其器。選擇合適的設計工具可以極大的提高工作效率。在這里為大家推薦兩款優秀的設計走查工具；

尺寸查看工具 CSS Peeper

網站鏈接：https://csspeeper.com/

設計師在設計走查過程中往往需要“像素眼”對線上的每一個設計元素屬性、間距進行核對，甚至需要右鍵檢查元素查看前端的數值是否能和設計稿一致。使用 CSS Peeper 神器后，設計師可以直接點擊設計元素查看 CSS 樣式，還可以看到 padding、margin 值，大幅度提升設計師設計走查的工作效率

截圖+標注工具 xnip

過去的設計走查標注過程，設計師截圖后，需要將截圖拖入設計軟件進行標注和說明，這個過程有幾個問題：

1. 設計師和前端工程師需要修改顏色、字體，使用箭頭標注間距，增加設計師工作量
2. 如果一張截圖問題較多，標注的內容互相交叉，會增加前端工程師的查看效率，增加溝通成本

使用支持截圖+標注的工具，例如 xnip,支持快框選和文字輸入，標注功能支持自動排序和排版，提升工作效率，降低溝通成本

線上協作表格

大家在設計走查溝通中，是否遇到這樣的問題

① 使用截圖標注交付截圖文件

優點：問題可視化，方便前端快速定位問題

缺點：

1. 設計單方面反饋前端，需要再次查看線上頁面進行還原檢查
2. 前端工程師查看都是具體的標注問題，難以確定解決的優先級，可能導致高風險問題由于交付時間的原因而沒有及時得到解決
3. 設計師和前端工程師的工作難以被量化

② 使用文檔記錄問題

優點：

1. 可以對設計走查問題分類分級管理
2. 方便對設計問題進行追蹤和管理
3. 設計師工作可以被量化

缺點：問題難以可視化，增加溝通成本

基于以上在設計走查過程中遇到的問題，我們使用在線表格類工具，對所有設計走查問題分類、分級，支持團隊成員對所有走查問題實時內容可見、可編輯，結合 xnip 工具，對需要截圖標注的問題作為補充。

不同走查問題分類管理

• 功能缺陷問題提交測試工程師
• 設計規范問題反饋前端工程師
• 交互優化建議問題由設計師做記錄，建立設計優化需求

問題解決優先級分級管理

• 「重要」問題優先處理
• 「一般」問題可非此次功能發布前處理

（2）設計走查標準

設計走查原則

設計走查的基本原則，即線上實現頁面必須達成的標準

1. 一致性:信息展示一致;相似的功能和任務，用戶操作交互路徑一致
2. 可用性：頁面間信息層級清晰，信息視覺流流暢，重點明確
3. 準確性：基礎控件使用正確；內容展示正確，不存在錯別字；信息架構表達準確
4. 完整性：操作路徑完整；功能實現完整

設計走查顆粒度

設計走查的顆粒度，一般來自于產品開發目標和開發周期。一般情況下，如果產品開發周期緊迫，產品目標是優先實現功能交付，那么設計師可以將功能實現的相關問題標注為高優先級問題優先解決；如果產品的目標是 UI 重構或者體驗優化，那么影響產品界面還原和體驗優化的問題也應提升為高優先級。

設計走查溝通

設計師對走查問題的描述，應該描述準確。

1. 問題定位-問題發生的位置和狀態；
2. 問題是什么-功能缺失？組件使用錯誤？間距錯誤？
3. 問題如何解決；

設計師在走查問題中，盡量直接描述問題，減少使用“請查看設計稿”這樣的表述，降低設計師和前端工程師的溝通成本。

本次分享到這里就結束了，希望可以對大家有所幫助，我們下期再見