有時候，設計師做出來的設計稿，開發處理完之后卻是另一個模樣，完全不是一個版本。因此在進行產品開發前，設計需要做的一件事情是做好還原度走查。那么如何進行還原度走查呢？作者進行了相關分享，希望對你有所幫助。

寫在前面

作為設計師，你一定遇到過這樣的情況，自己做的設計稿，被開發出來后卻完全換了一個模樣。不僅視覺上有問題，交互上也有錯誤。而要想避免這樣的情況，我們就一定要重視還原度走查這個階段。

它是我們產品上線前的必要保障。雖然測試同學會幫助我們驗證一些流程上的問題，但更多的還原度細節問題，比如交互和字號間距等，則更多依靠我們設計師的來檢查。而在還原度走查的過程中，個人認為主要分為以下幾個部分：

一、還原度何時開始

經過對比驗證，發現還原度在測試進行第一輪測試后進行，效率和時間能夠最大化。

原因如下：

• 第一輪沒結束前，很多功能性bug會存在，如果介入過早，很難跑完全部流程，加大還原度介入難度。
• 一些明顯的交互和視覺問題，測試團隊在第一輪是能夠發現的，也能減少一部分工作量；
• 如果等bug解決得差不多，可能都二輪后了，這時候才開始走查的話，那么留給設計師的時間就會非常少，因為結測的時間已經固定，這可能導致開發可能沒有足夠的時間修正問題。

二、還原度檢查內容

當我們拿到開發提測的版本后，應該針對于哪些內容進行檢測呢。本人認為可以整體檢查可以分為以下3個部分：

2.1 整體流程

當我們拿到產品后，第一時間可以看下我們的整體的流程是否有遺漏，整體流程是否能夠跑通。

首先需要確保我們的產品沒有大的流程問題后，這個時候就可以開始細節的部分。避免某些大的流程被忽略，這往往需要更多的開發量，越早提出來開發就越早介入修改。

雖然這個過程基本都會被測試團隊在第一輪的時候查驗出來，但為了避免有遺漏，我們最好還是先把全流程跑一遍以避免發生問題。

2.2 交互內容

當流程跑完，這個時候我們就可以進入到交互細節的檢查。一般來說我們在檢查時主要注意以下幾個方面：

A. 結合交互說明進行逐條驗證

一般我們的交互說明已經非常詳盡，包含各類異常狀態和細節交互。因此我的建議是在驗證的時候可以結合我們之前的交互說明進行對照驗證，避免某些部分被遺漏或者忽略。

出現問題有可能是我們的交互闡述的不夠清晰或者說研發沒有了解設計的邏輯，這些情況都是有可能發生的，因此我們在還原度驗證時更需要細心驗證和溝通。

B. 交互說明未提及的異常狀態

這其實是很多設計師經常遇到的問題。我們在寫交互說明的時候不可避免會忽略某些細節點。這個時候如果出現交互說明漏掉的異常狀態，就需要和開發團隊進行溝通。

如果是重要且影響體驗的問題，可能就需要拉著開發團隊進行溝通，評估下時間進行修改；

如果是不重要且不影響的體驗的問題，就可以等下個迭代或者后續再進行對應修改；同時對問題做好記錄，避免下次再出現類似問題。

這同時也反向要求我們在交互說明中盡可能考慮得更加全面，才能避免多次返工。關于這塊有個小建議，可以將平時遺漏的交互記錄下來，形成關于自己薄弱交互環節的自查表。通過建立專屬的交互自查表來強化自己對于各類狀態的認知，從而將說明寫得更加詳盡和完善。

2.3 視覺內容

視覺的還原度檢查可以說是占據了整體檢查的大部分內容。畢竟功能或者交互還有測試團隊幫忙驗證，但視覺細節只能靠設計師本人來進行走查了。在這里我將其分為以下幾塊內容：

1.「像素眼」觀察法

由于習慣問題，設計師對于字體的大小，元素的對齊有一種天生的敏感，因此對于某些比較明顯的還原度問題，設計師是能夠通過直接觀察發現的，比如某些元素沒有左對齊。

但這種只適合很多明顯偏差的元素，在大部分時候，設計師還是需要借助輔助工具來協助進行還原度走查。

2. 檢查元素（F12）協助走查

在很多時候，我們發現某些元素存在問題，但不確定的時候，我們就需要借助檢查元素輔助還原度走查。檢查元素如何操作呢，可以通過右鍵-檢查或者直接按F12來調出，通過鼠標選擇元素，即可查看該元素的所有屬性，包括字號、顏色、寬度等等都可以直觀的看到。

利用這種方法我們可以檢查得非常細致，比如某些細微的間距是否準確，都可以檢查出來。

那么在這里我們可以簡單介紹下前端的盒子模型，也就是你在檢查元素中可以看到類似盒子的元素。盒子模型是CSS中的概念。所有的HTML元素都可以看作一個盒子，是用來設計和布局時使用。它包括我們常見的邊距、邊框、填充和實際內容。通過了解盒模型有助于我們理解前端是如何進行頁面布局的，同時也幫助我們在走查時更直觀地看到其中的間距和寬度等。

其實檢查元素還能輔助交互狀態走查，這可能是很多設計師忽略的一個點。比如我們設定了hover按鈕時有灰色底塊，此時我們如何驗證灰色塊的色值和大小是否準確呢。

其實輔助元素也可以幫忙，如下圖所示，我們通過勾選hover這個狀態，界面中就會直接呈現當前元素的hover狀態：

3. 借助工具輔助走查

目前市面上有兩種常用的工具，想必很多設計師也已經知道了。分別是CSS Peeper和Copiexl。

首先推薦的是CSS Peeper。這款插件其實就是類似于檢查元素，只是界面會更簡潔，相比于檢查元素去掉了很多干擾元素，打開后我們點擊頁面上的元素就能夠直接看到其對應的元素屬性和間距等。對于設計師群體來說還是比較友好的。

地址：https://csspeeper.com/

第二款的則是字節出品的Copiexl。其對比方式會比較簡單粗暴，就是將設計稿和開發稿在相同尺寸下進行疊加對比，從而看出來有哪些區域是不一樣的，從而快速找出不對的地方。教程官網都有，我這里就不進行詳細介紹了。

地址：https://copixel.bytedance.com/

三、還原度如何記錄

通過以上幾種類型的檢查，基本上都可以檢查出大部分還原度問題，那么此時如何與進行溝通呢，這個時候避免以下兩個做法：

1. 直接當面找到開發，給他說很多還原度問題。因為開發在這個階段也有很多其他工作，不僅會打斷他工作，他也不一定記得這么多細節；
2. 直接將還原度問題在聊天窗口直接發出去。通過聊天記錄看還原度，不僅不方便查看，還很容易遺漏掉部分信息。

因此正確的做法是建立一份還原度文檔記錄表，內容包含：模塊，具體問題，問題截圖，問題嚴重程度，解決狀態，對應開發。

在這里需要注意的一點就是面對間距問題不正確時，不要直接跟開發說你去找設計文件對照下，而是直觀地在還原度截圖中告知他這里的正確間距，這樣能夠節省雙方的時間，也避免開發再次看成錯誤的尺寸。

這樣的話不僅能夠清晰記錄每條還原度，開發還能夠根據重要程度有優先級地改掉問題，同時也可以為我們后續做校驗提供支撐。

四、如何讓整體變得更好

通過整體流程的梳理，不難看出還原度驗證過程其實也是協作過程。因此想要很高的還原度，我們也需要在以下方面做得更好：

• 團隊內部有嚴謹的設計規范，避免多設計師協作時同一控件用了不同的表現形式；
• 注重設計宣講和重點標注。在進研發時設計宣講是必要的，能夠讓研發人員了解我們的整體設計邏輯以及我們關注的重點，同時我們在寫交互時也可以將重點字段用不同的顏色進行標記，從而讓研發人員在寫得時候能夠引起重視
• 注重信息同步。我們所有的改動都需要將其同步給研發和測試人員，同時也可以在我們的設計稿上標記好更新內容，這樣整體的協作會變得更加順暢，也避免信息差導致的更新不及時。
• 避免頻繁修改，不論是誰面對頻繁修改都是不太開心的，因此我們對于已經進入迭代的設計稿，因此如果面對必要的修改時要及時同步信息。如果一些不太重要的改動也可以先放一放，后面再改。

寫在最后

當我們驗證完畢后，記得有一份還原度報告作為最終的檢測憑證。因為在大部分的研發迭代中，或多或少都存在一些遺留的問題，還原度報告可以清晰的記錄這些問題，也方便在后續版本中進行修復。

當然，即使經過上述的檢驗，也不可避免有遺漏之處，但沒有關系，只需要將其記錄下來，一些小的優化點我們可以在后面的排期中安排時間進行對應的修改。

以上就是本次還原度想要說的，希望能夠對大家有一些幫助。