編輯導語：在B端産品中，我們往往更加注重産品功能，但卻忽視了頁面還原度的實現，它直接決定了從産品需求到設計實現。作者結合了自己的工作實踐以及與産品、前端、測試的深度溝通，分享提升頁面還原度的解決方案，希望對你有所啟發。

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

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

大部分開發團隊通過UI走查環節解決頁面還原度低的問題，即在測試階。段由UI設計師對産品的還原度進行走查和标注，開發工程師對問題進行修複。

然而，隻在UI走查環節解決頁面還原度問題，有以下缺陷：

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

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

一、頁面實現還原度低的原因

1. 設計規範和設計組件庫不一緻

• 使用不同設計系統 以Ant Design 和 Arco Design 表單組件為例，兩個設計系統的色值、間距、交互效果等都各有差異，如果設計與前端使用不同的組件庫，設計稿和線上頁面必然大相徑庭。
• 使用同一設計系統前端工程師在開發過程中不會對所有設計元素逐一查看，更不會對比設計稿規範與設計系統默認規範是否一緻，如果設計師對默認的設計規範作出調整且沒有在設計稿中作出标注，同樣會造成設計稿和線上頁面的差異。

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

UI設計師在靜态固定寬度的頁面進行設計，關注的是如何産品需求轉化為設計語言，将設計元素科學合理的布局與排版。前端工程師需要完成的是如何在不同分辨率的情況下，最大可能對設計稿進行還原。

以上案例展示了設計師和前端工程師對同一頁面不同的實現方式，在線上頁面寬度與設計稿一緻的情況下，表單之間的橫向間距都是65px。

但是，如果頁面縮放或者在不同分辨率屏幕下展示，設計認為一行兩列表單的間距依然是65px；而按照前端工程師的實現方式，不同分辨率下單個栅格的寬度是變化的，那麼表單之間的橫向間距必然會發生動态變化。

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

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

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

二、如何提升頁面實現還原度

1. 建立一緻的設計規範和組件庫

建立B端設計組件庫和設計規範，使用範圍不應僅局限于設計團隊内部，應達成整個團隊尤其是前端工程師和設計師的設計規範和組件庫的一緻，從而實現設計稿到線上頁面輸出統一的設計語言，從根本提升設計質量和還原度。

但是，統一和前端的設計規範與組件庫并非易事，需要将産品的發展階段、前端團隊開發團隊工作習慣、設計曆史原因等因素進行綜合考量，筆者結合工作實踐，設計師可以從以下方面提升與前端團隊的一緻性。

（1）設計組件的選擇

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

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

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

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

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

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

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

（4）設計規範

制作設計規範的目的是為了統一設計内部以及與前端工程師的設計規範，提升團隊的協作效率。前端工程師根據設計規範建立公共組件庫，提升前端組件複用率，減少設計與前端的對接成本，提升工作效率。測試工程師根據設計規範建立穩定、一緻的測試用例，提高測試工作效率。

因此在設計規範在制定和更新過程中，需要與開發、測試充分溝通與協作，形成團隊穩定、一緻的規範文檔，從根本上提升協作效率，高效完成界面的開發和驗收。

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

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

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

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

3. 設計思想宣講

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

設計師的本質工作是為了解決問題，使用不同的設計方法，背後隐含的是設計師對産品不同信息的處理和傳達，因此，設計師有必要和團隊成員主動溝通，解釋設計師在設計工作中對不同信息的處理邏輯，設計師如何将文字需求轉化為視覺語言準确傳達給用戶不同專業對同一事物的關注度和敏感度不同，例如需求評審過程中，設計關注排版，後端關注數據，測試關注異常情況。

因此，對同一頁面感知度團隊成員差異巨大，這樣的結果可能會導緻設計師對信息的傳達在頁面上線後大打折扣，因此，設計師必須和團隊成員，尤其是前端工程師分享在設計師在設計過程中，是如何将需求内容轉化為視覺語言傳達給用戶的。

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

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

（1）設計工具的選擇

尺寸查看工具CSS Peeper：

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

截圖 标注工具xnip：

過去的設計走查标注過程，設計師截圖後，需要将截圖拖入設計軟件進行标注和說明，這個過程有幾個問題：1、設計師和前端工程師需要修改顔色、字體，使用箭頭标注間距，增加設計師工作量2、如果一張截圖問題較多，标注的内容互相交叉，會增加前端工程師的查看效率，增加溝通成本使用支持截圖 标注的工具，例如xnip,支持快框選和文字輸入，标注功能支持自動排序和排版，提升工作效率，降低溝通成本。

線上協作表格：

大家在設計走查溝通中，是否遇到這樣的問題使用截圖标注交付截圖文件優點：問題可視化，方便前端快速定位問題缺點：

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

使用文檔記錄問題：

優點：

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

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

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

不同走查問題分類管理：

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

問題解決優先級分級管理：

（2）設計走查标準

設計走查原則：

設計走查的基本原則，即線上實現頁面必須達成的标準一緻性:信息展示一緻;相似的功能和任務，用戶操作交互路徑一緻可用性：頁面間信息層級清晰，信息視覺流流暢，重點明确準确性：基礎控件使用正确；内容展示正确，不存在錯别字；信息架構表達準确。

完整性：操作路徑完整；功能實現完整。

設計走查顆粒度：

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

設計走查溝通：

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

• 問題定位-問題發生的位置和狀态
• 問題是什麼-功能缺失？組件使用錯誤？間距錯誤？
• 問題如何解決

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

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

本文由 @沉迷作圖無法自拔 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部