前言

UI設計師作為展示產品形態的執行層。產品上線前走查視覺與交互還原是必經環節，設計師可能都遇到過一個問題，作圖時連一像素的分割線都糾結好幾次，但是開發完的效果卻不盡人意，UI驗收不通過。然后前端這邊委屈的想拿出藏在鍵盤下的四十米大刀找你來血拼。。。

我們經常會聽到身邊的設計師與開發哥的一些對話，關于對齊，大小，間距等設計還原問題經常會討論很久。甚至有時會覺得，幾個像素的間距是不是有必要這么糾結？

1.設計還原到底是什么

「還原」是指事物恢復到原來的狀況或形狀，互聯網中的「設計還原」是說開發后實際界面和設計稿效果有偏差，進行設計校對。

 

2. 設計還原的現狀

一直以來，設計驗收都不太受重視，一是設計師習慣于把時間用在雕琢設計稿上，而忽略掉后期的設計驗收。二是對自己和合作的程序員極其自信，認為對方能知道到自己所有的點，會完全按照設計稿來。

不同的項目類型還原度也不同：用戶產品>B端產品>后臺。對于用戶產品最好是能做到像素級還原。

 

3.設計還原的意義

在這個快速發展、迭代、更新的時代，互聯網產品的用戶體驗重視度越來越高，而其中的產品設計還原也成為了工作流中重要的一環。

我相信每一名UI設計師，心里應該都有一個前端能100%還原設計稿的夢想，畢竟那是我們艱苦奮斗的勞動成果。

而視覺還原的高低與否，則直接取決于設計-開發-測試這些環節的協作質量，不僅僅影響上線產品的用戶體驗，還影響著作為產品設計最后一環的工作質量。

 

經過走訪UI/UX設計師、前端工程師和測試工程師的還原設計圖的工作場景。深究原因后，線上效果的失真率其實涉及到設計、前端開發、測試這三個環節，分析造成這種現象出現的原因大概有以下幾點：

• 自由發揮，把界面UI設計當作畫布任意揮灑，完全不考慮實現的難度；
• 標注圖不全，沒有詳盡的對接文檔和設計規范；
• 溝通不到位，評審時沒有將設計思路和易錯點交代清楚
• 沒有考慮設計稿擴展性和前端代碼的邏輯，反復修改，增加FE工作量。

 

• 時間緊任務重，沒辦法一張一張看標注圖；
• 直男思維，想怎么寫就怎么寫，反正最后要上線，細不細致都一樣；
• 不知道如何解決，內向不肯和UI溝通找到解決方案。

 

• 測試混亂，測功能時提UIbug；
• 測試頁面還原時，提UIbug不細致，用“請參照UI設計稿”概括一切問題。

 

了解開發依據哪些規則還原設計稿，前期的準備工作是重中之重，設定好每一個細節規則，后期落地還原時才會將頁面的失真率降到最低。

 

1.視覺規范

UI 設計中，設計規范是設計還原一個關鍵步驟。一個好的規范應該是高效的、簡單易懂的。設計規范通?？梢园杨伾⒆煮w、組件等內容制定成規范，不僅僅保證視覺的一致性，也極大方便樣式和組件的復用，后期的維護和開發。在規范的輔助下，開發在搭建全局共用控件時規則更加清晰明了，如按鈕、行間距、字體大小、色值等等。

 

1.1色彩規范

顏色是設計中最重要的元素，顏色的運用與搭配決定設計的品質感。在 UI 設計中，顏色的使用規范主要在于：品牌主色、文本顏色、界面顏色（背景色、線框色）等。

 

1.2 字體規范

文字是APP主要信息的表現，尤其是新聞閱讀、社區APP等制定標準的設計規范和良好的排版方式，用戶使用APP也覺得毫無疲勞感，這一點很重要。不同的字體氣質不一樣，并且不同場景下帶給人的感受也不一樣。所以需要在設計的時候考慮到字體的設計效果，然后在設計規范中注明。主要規范標準字的大小，標準字要注意跟上文的標準色進行組合，突出APP重要的信息和弱化次要的信息。

 

1.3 圖標規范

在 UI 界面中，具有標識性質的圖形就是圖標。作為 UI 設計中重要的設計模塊，產品的每個頁面中都有可能存在圖標。

設計規范中，圖標一般按照用途分為兩類：應用圖標、功能圖標。

圖標還應該根據不同的功能需求設計不同的狀態：如常態、選中態、點擊態等。

應用圖標：各種應用程序的識別標志，在應用商店里下載的一些應用程序的標志。

 

功能圖標：規范中最好標明圖標格式與使用方式。比如 Web 設計，圖片可以使用 iconfont 管理，可生成代碼交付給前端開發；如果是原生 APP，那么需要標注圖標導出格式與尺寸。

 

1.4 圖片規范

圖片作為界面設計的重要組成部分，需要標明尺寸規范，分為不同用途的種類。

 

1.5 控件規范

控件是指產品界面中可操作的部件，與組件是有一些區別的?？丶g為 Control，組件翻譯為 Component。

通俗的解釋說法就是組件為多個元素組合而成，控件為單一元素組合而成。

常用的 UI 控件（Control）：按鈕、輸入框、下拉列表、下拉菜單、單選框、復選框、選項卡、搜索框、分頁、切換按鈕、步進器、進度條、角標等。

 

1.5.1 按鈕

按鈕有 5 個狀態：正常、點擊、懸停、加載、禁用。需要在規范中分別羅列出這五個狀態，標注上對應的按鈕填充色、邊框色、圓角值、按鈕寬度和高度，按鈕文本大小、顏色值。如果是圖標按鈕的話，除了上述參數值以外，還需要標注 icon 和按鈕文本之間的間距，icon 圖標的大小。

 

1.5.2 輸入框

用于單行信息錄入文字上下居中顯示，支持鍵盤錄入和剪切板輸入文本，對特定格式的文本進行處理：密碼隱藏顯示、身份證、卡號分段顯示，標注寬高。

 

1.5.3 選擇

選擇可分為單選與多選，并且也有五種不同狀態：未選擇、已選中、未選懸停、已選失效、未選失效項。規范中需展示出所有效果狀態。

 

1.5.4 進度條

用于向用戶展示步驟的步數以及當前所處的進程。

 

1.6 缺省頁

• 空狀態頁面：顯示對應的頁面空狀態的圖標，增加相應的引導按鈕。
• 無網絡狀態：在沒有連接到網絡時的提示頁面。
• 404&505頁面：發生未知錯誤時的頁面。

 

2.組件規范

常用的 UI 組件（Component）：表格、對話框、提示條、氣泡提示、日期選擇器、多級選擇器、標簽輸入框、組合框、上傳等。

如果UI忽略規范，前端在不知道有可復用組件的情況下，很可能每一次都要手動書寫代碼。寫的代碼越多，遺漏掉細節和犯錯的可能性越大，導致效率降低。最關鍵的是，對于今后的迭代，前端又得一個頁面一個頁面修改。

 

2.1組件的好處

統一性：

1)整個產品不同模塊的業務按照統一規范使用，提升整個產品的視覺交互統一性，減少開發樣式，提升開發效率。

2)避免設計師自由發揮新的組件控件樣式。

3)統一交互設計規則，減少用戶操作的迷惑感，提升產品的體驗。

 

高效性：

1)一套組件可以幫助設計師簡單處理產品經理的初步需求，設計師通過拖動組件搭建界面來跟產品經理對需求，確認完善需求后再進一步推進需求。節約時間，提升工作效率。

2)減少制作組件控件的時間，不需要對組件重新下定義，提升設計效率，可將更多時間放在流程體驗和設計推動上。

 

延續性：

1)通過設計規范，在以后更新中可以連續迭代，避免斷層。

2)團隊即使有成員離開或者加入，通過設計規范和組件庫可以快速的接手和進行正常工作。

 

2.2組件化的特點

通用性：

意味著足夠基礎和常見且不帶業務屬性，參與設計每秒的每個人都應該知道這個組件的功能及目的，同時一定一定擴展性。

靈活性：

是要求元件的組合需要靈活，可以在不同場景下可以通過相互組合來快速構建交互框架原型圖，并根據不同頁面結構的變化來適應新的業務需求。

選擇性性：

指的是適用于多個業務或產品，在設計過程和研發過程中都可以高頻轉換。

 

2.3組件化分類

我們根據當下現有的業務場景和對往后一段時期的業務發展方向進行規劃，將組件庫的組件類型分為通用組件和業務組件。一般業務組件庫是不對外的，所以在Ant Design官網只能看到通用組件部分。

 

2.3.1 通用組件

指適用范圍廣，擴大頻次高，可重復使用多個業務且不包含業務邏輯。某些導航欄，按鈕，吐司，彈窗等。我們將通用組件細分為五個子類別：基礎組件，導航，數據錄入，數據展示，操作反饋。

 

2.3.2 業務組件

這類組件對比通用組件而言最大的特點就是包含了一系列業務屬性，跟產品功能有重疊的關聯性，因此影響到適用范圍可能僅限于于1?2個業務系統或特殊場景，且復使用頻次不高。畢竟使用場景特殊也有限，放出參考意義不大。

 

2.3.3 組件化搭建流程場景

組件化的搭建在兩種場景下進行：

• 1）產品立項前就開始組件化，在產品0到1之前，擁有一套組件和設計規范。設計師可以從以前項目的組件庫和設計規范直接套用并修改，這樣項目前期設計做起來更加方便且省時省力少挖坑。
• 2）產品經歷過0到1后，產品趨于成熟，這個時候開始做組件化。組件化搭建最多會有六個步驟，分別為：梳理類目、場景走查、問題分析、方案設計、生成插件庫、驗證開發。

 

具體的組件化設計升級流程我總結成了下圖：

當團隊搭建完成組件化之后，接下來就是成員間的使用，這一過程有業務需求產生組件模板、組件模版形成頁面、頁面形成頁面流程和頁面流程形成用戶體驗。組件庫重建之初無法一應俱全，是需要后續設計師不斷的維護與迭代的。

 

3.詳盡標注

關于設計輸出，現在很多像藍湖、zeplin、Pxcooker這種標注軟件把設計師從手動標注解救出來，往往把視覺稿在藍湖一扔就完事，前端開發完界面視覺還原度還是不高。

因為標注軟件只能負責生成元素的尺寸、樣式，遇到復雜樣式即使你反復衡量的一些像素，開發還是會漏掉。這樣很有可能出現視覺災難。

所以，一些復雜而又關鍵的頁面我建議可以貼心的做些手動標注，主動告訴開發重要性和注意點。

 

我們現在工作中會有兩種標注情景：

3.1. 運營標注

因為很多數據是后臺傳輸到前端，有圖片、有文字，每個內容都需要給運營設置一個上傳標準。

 

3.2 開發標注

開發標注是從設計稿落地成代碼的主要參考，除了藍湖提供的標注，我們還需要寫一些重要部分設計說明，例如：模塊區分、局部特殊設計（該內容根據自身產品而確定）。

3.2.1 常規手動標注

 

3.2.2 特殊模塊/頁面劃分說明

復雜的表單設計，是很具有代表性的復雜頁面，根據頁面的布局進行原型化示例，幫助前端更好的搭建代碼框架。

 

4.同步切圖邏輯

關于切圖，切圖之前應跟開發確定好輸出的格式和尺寸，確定應該用 SVG，一倍圖或是兩倍圖，SVG體量小渲染質量好，單色使時還能替換顏色，PNG則通常用在實景圖，一倍圖和二倍圖則根據實際需要進行輸出。

如果要做分層動畫，那我們就涉及到分層切圖，如果桌面端和手機端樣式差別較大，那我們需要和開發溝通好如何實現，是否需要特殊切圖，所有的特殊切圖合特殊樣式，我們都應該提前跟開發溝通好。

 

5.了解開發思維

設計-開發這個環節的協作質量對視覺還原起著決定性的重要影響。但是，由于本身的工作性質，我們和開發之間溝通是個棘手又麻煩的歷史遺留難題。設計師與開發雞同鴨講從而導致視覺還原度低下的局面，幾乎每天都在上演。

俗話說“知己知彼百戰百勝”。如果設計師能夠了解一些基本的開發術語以及開發流程，就可以更好的打破溝通隔閡。

那網頁設計稿的實現具體是怎樣操作的呢？

步驟可以概括如下：

 

5.1 設計師的要了解的「盒子模型」

5.1.1  什么是盒子模型

在開發的工作流當中反復提到的盒子模型。雖然不需要完全了解前端是怎么通過代碼來落地你的設計稿的，但你一定要知道什么是「盒子模型」。

「盒子模型」是前端的基礎知識。在「盒子模型」理論中，頁面中的所有元素都可以看成一個盒子，并且占據著一定的頁面空間。

一個頁面由很多這樣的盒子組成，這些盒子之間會互相影響，因此掌握盒子模型需要從兩個方面來理解：一是理解單獨一個盒子的內部結構，二是理解多個盒子之間的相互關系。

 

5.1.2  盒子模型的組成

每個元素都看成一個盒子，盒子模型是由 content（內容）、padding（內邊距）、margin（外邊距）和 border（邊框）這 4 個屬性組成的。此外，在盒子模型中，還有寬度 1 和高度 1 兩大輔助性屬性。

舉一個真實界面示例，我們在瀏覽器中打開「開發者模式」可以看到網頁的樣式代碼以及當前界面是如何通過「盒子模型」來布局的。

前端并不能簡單的像UI畫圖時一樣，隨意地拖放一個可見元素到某一個位置。他們要通過把每一個元素裝進一個「盒子」中，再去界面中定位它所處的位置。

 

5.1.3  了解盒子模型對于UI的好處

當你摸清了前端是如何布局實現你的設計稿后，你在作圖的過程中就會開始懂得站在落地的角度思考問題，善用「盒子」，將界面中每一塊布局「盒子化」。

我舉一個示例，如果我們不使用「盒子」，當我們在做一個卡片時，前端并不知道UI是如何定義每一個元素的間距。比如，然后將這一個間距套用在他也不知道應該設置為多高的「盒子」當中。

所以UI在出稿時就帶入「盒子模型」思維，合理地構思好每一塊元素的布局，一方面可以幫助自己在輸出頁面時，布局更加合理；另一方面可以在前端落地時輔助前端準確還原。

優秀的設計離不開開發人員的落地支持。作為設計師，協同開發人員完成設計落地也是工作中重要的一環。做好以下幾點，站在開發人員的角度為他們“多想一步”，高質量的設計還原指日可待。

 

1.設計宣講

在進行設計還原的時候我更希望大家把設計評審的環節重視起來，之前也有詳細的講到過《如何進行設計評審》的。因為我認為評審對于設計還原的意義是把問題前置化。通過設計評審可以把改版視覺變化最大的地方和開發說明清楚。這些改版布局框架改變都會增加開發工作量。這個環節把握好了，那基本都能實現出來，特殊情況除外，比如前期忽略了一些后臺數據的問題。

有些細微的地方需要我們特別像開發說明，也加深他們的印象，在實現時候就減少出錯，像開發走讀的時候，只把關鍵核心點，規則講清楚，我們前面每走一步，都是為了后面我們檢視還原度的時候要輕松一些，開發也輕松一些，就比如前期基礎沒打好，后面深入很難。（如果大視覺沒還原好，如何叫開發打磨細節？）設計師做好會議記錄（記錄問題及解決方案，以及達成的共識），并且在會議結束后以郵件形式發送前端們，抄送產品和運營，確保會議內容的傳達到位。讓設計師與前端工程師相關問題達成一致，提升工作效率。

在開發緊張環節中，即使我們前面所有工作都準備好了，也很難避免開發不找我溝通，這時候我們要積極回應他們，并且和他們一起處理問題，比如某些難度大一點的頁面，開發實現效果和設計稿差異不小，那么這時候，開發會截一張他們實現的效果圖給你看，這時你就要仔細去找問題，不要一口咬定就是開發的原因，先溝通具體原因，然后找出解決辦法，如果是標注出現問題，比如標注標死了，頁面不靈活，適配局限性很大。

 

2.視覺走查

在視覺走查的時候我們可以把test環境下的頁面和設計稿拿出來對比。走查頭部、尾部等位置是否完整統一，按鈕樣式、反饋狀態、報錯等樣式是否統一；是否有缺少的場景和狀態，根據任務流程對場景和狀態進行排查，保證設計的完整性。

這里給大家推薦兩個視覺走查方法：

1) 大家來找茬法

驗收的時候，我們需要把開發實現后的效果截圖，然后再去和設計稿做對比。

我們可以直接把截圖放在設計圖上方，降低透明度，大致比對下，就知道哪里不太對，然后再具體標注需要修改地方的參數。

 

2) 頁面重構走查

走查還原的時候，在Chrome瀏覽器的空白處右鍵點擊檢查，找到里面的Computed窗口，我們可以找到具體的文字、間距、投影等屬性。有時候一些比較細微的調整，我們可以雙擊具體的數值進行調整，調整到自己滿意之后再給到具體的數值給開發，這樣就不用在我們搖擺不定的情況下，造成雙方的困擾。

 

3.交互反饋

3.1 確保可用性

設計任務流程，進行設計走查，在移動App端，我們所設計的應用是建立在手指點擊操作的基礎上進行使用的。我們的手指不像鼠標一樣能夠精確定位和響應，所以我們需要在設計的過程中確保可點擊的區域能夠較為明顯的識別。

 

3.2 確保易讀性

文本內容是大部分產品的重要組成部分，所以文本的排版是非常重要的（很多人說中文排版不好看，那是因為你不會用中文排版的方式去做排版）。確保文字清晰、易閱讀是在文字處理上的必須保證的。

在眾多設計原理中，格式塔原理一直被廣泛應用，它可以很好的梳理界面信息結構、層級關系，從而提升設計的可讀性。在自查過程中，我們可以通過格式塔原理檢驗頁面中的元素是否符合標準。

 

3.3 反饋機制

當用戶和產品需要交互時，會使用不同的模式反饋信息或結果，為用戶在各個階段提供必要、積極、及時的反饋，避免過度反饋，以免帶來不必要的打擾。

常見的三種反饋信息如下，大家可以在此基礎上自查是否有反饋、反饋是否傳達清晰，是否對用戶有即時的響應等細節，：

• 提示信息：如警告、通知，常見形式 Alert、Badge、Popover；
• 過程反饋：加載狀態、錄入反饋、確認彈窗；
• 結果反饋：全局提示、對話框反饋；

 

3.4 動效還原

動效這塊是產品中比較高規格的一個存在，所以在使用的過程中一定要謹慎，不能隨意加入多余的動效，導致在使用產品的過程中出現問題。

 

4. 觀察敏感點

在我走查的經驗多了以后，發現  最容易造成落地頁面與設計稿視覺差異的，其實就是顏色與間距還有圖標的視覺錯覺。不要小看這兩個細節元素，把控不好它們會讓落地頁面效果大打折扣。所以在進行頁面還原的可以著重對比一下幾點:

 

4.1 分割線

在驗收的時候要特別注意分割線的問題，分割線是在所有屏幕上都是1px，但是很多程序員沒有注意這個，或者說設計師在開發前沒有特別說明，程序員就寫成了1pt，因為pt是1x下的單位，px是實際單位。

所以在做分割線的是，單位需要是「px」，這樣才能保證每個屏幕的分割線都是1像素。

下面主要以3個主要場景來分點解釋分割線的標注：1. 列表流；2.feed流； 3. 內容塊之間。

 

4.2 投影

陰影作為一個重要的視覺元素，讓主元素和其他元素從背景中“彈出”并擁有深度，更好地將信息層級呈現給用戶。常規投影與彌散陰影推薦使用css代碼完美實現；特殊情況下還需提前與開發人員溝通權衡各種方式的利弊，選擇適合項目產品的實現方式。

結合自己實際的工作經驗和與開發人員溝通的心得，實現彌散投影的方法，可以通過兩個方法實現：

 

4.2.1 切圖對接開發人員

雖然切圖可以解決這個問題，但是切圖也有一些弊端，因為每個卡片都使用切圖的話，會使開發的包變大，可能會出現加載慢，閃退等情況，這些體驗也是很糟糕了。所以在這個過程中的一些問題務必要提前與開發人員及項目人員溝通好。

 

4.2.2 CSS代碼實現

常規情況下，效果都比較好，但是也會遇到一些遇到異常情況，比如不規則形狀，通常用代碼也比較復雜，這個時候需要提前與開發人員溝通切圖情況，避免后期一些問題。

在做設計的過程中，我們需要更好地理解下游的工作，達到一個高效的溝通。不管是哪一種方法，沒有對錯之分，關鍵是要懂得“權衡利弊”，提前與開發人員溝通到位。只要是適合自己公司項目且能夠高效還原設計稿的方法，都是值得一用的。

 

4.3 文字行高

文本間距也是影響落地效果的關鍵因素之一，文本間距指的是，純文本與其他元素之間的間距。UI出稿時應該注意  文本行高可能導致前端的測量誤差。文本間距主要的原因是 sketch 與 ios 系統中字體的行高不同。最簡單的解決方法是通過手動調整 sketch 中字體的行高，業界常用的行高是字體 size 的1.2或者1.4倍，實際這兩個值都是夠不準確的。

首先我們要理解什么是行高（line-1）。

我以 Sketch 為例。當我們設置了一個70px的文本，Sketch 會默認給我們設置文本為98px行高。文本的上下會包含一定的空白像素。

如果UI不設定行高規范，落地過程中就會出現以下問題：

 

行高的解決辦法

面對行高的問題，我一般會在設計的過程中，輸出規范行高（可以是x倍行高，也可以是具體的行高值，如28px的多行文本行高為40px），和前端進行對接落地。最簡單的解決方法是通過手動調整 sketch 中字體的行高，業界常用的行高是字體 size 的1.2或者1.4倍，實際這兩個值都是夠不準確的。

最近看到了一個新的公式可以同步開發根據字號設置行高。

設字號為x，行高=x+2ceil（x/10），ceil（）的意思是向上取整數 L（行高） 比如： 12 + 2 * ceil(12/10) = 16

注意這里適用于單行行高，由于多行涉及到的排版問題不僅僅是行高帶來的，有機會的話可以單獨聊一下。

推薦DoraemonKit 是一個功能平臺，能夠讓每一個 App 快速接入一些常用的或者你沒有實現的一些輔助開發工具、測試效率工具、視覺輔助工具，而且能夠完美在 Doraemon 面板中接入你已經實現的與業務緊密耦合的一些非通有的輔助工具，并搭配滴滴的dokit平臺，讓功能得到延伸，接入方便，便于擴展。

 

4.4 視覺重心修正

在設計上為了保證界面的視覺平衡，往往不是設計軟件直接精準對齊，我們總是會通過調整間距、大小或者角度補齊一些負空間，讓畫面保持視覺平衡。

還有設計中通常向右箭頭來表示模塊入口，當我們把箭頭和文字右對齊，箭頭視覺上會更外突，這時候我們會往里面縮進1至2像素，但是切圖完給完全不知情的前端后，設計師要主動講解一下，或者寫進規范里。

項目會有些需要展示logo的地方， 有的圓形，有的長方形，有的純文字，尺寸差距比較懸殊。這種情況下，我們需要給他限制一個高度，在這個高度以內，再根據logo本身的體量來調整圖形的大小，處理好logo的視覺平衡。

 

5.考慮特殊場景

特殊場景在設計過程中常常會被忽略，等到在現實中碰到才會意識到缺失異常狀態會非常尷尬，所以大家在完成主流程設計后，一定也要考慮到特殊場景。大家可以參照以下幾種場景對設計進行自查優化調整。

網絡異常

考慮到網絡異常情況時，通常產品會通過異常狀態頁面或者交互反饋來告知用戶當前的異常狀態和如何解決問題（解決方案引導、刷新、toast）。

 

服務器異常

服務器異常狀況較少出現，時間也較短，通常不提示具體原因，設計處理方式為在新頁面展示缺省頁，文案+插畫的形式給予用戶提示及重試引導。

 

空狀態

空狀態指的是頁面中無內容，主要的幾個情況，設計師需要根據不同的場景給出文案+插畫的表現形式引導用戶：

• 無權限，針對的是某些需要權限開啟后才能獲取內容的頁面；
• 搜索無結果，對應搜索無相應結果的空狀態提示；
• 內容為空，如初始狀態、內容被清空后的狀態。

 

內容缺失

內容缺失展示效果的考慮，設定頁面圖片缺失的占位圖。

 

加載頁面的表達方式

考慮網絡加載或者數據加載的時候會等待幾秒鐘，通常產品會有一個簡單頁面的占位圖形式來減輕用戶在等待時的焦慮感。可以是loading，也可以是整體頁面的刷新動效。

 

6.關注機型適配問題

設計還原的時候最后還還看一下不同機型適配的問題。保證不同機型的界面呈現效果一致。

6.1 動態眼光

手機適配的時候很多設計師會遇到一個問題，就是在750*1335的屏幕上做的設計圖，但是適配到640*1136的屏幕上就有元素放不下。所以設計師在出圖時需要用動態的眼光去考慮問題。

知識點：在簡單的界面中，由于本身界面的內容比較少，確定位置就會比較難，因為要考慮到不同的界面內容要怎么放才能保持視覺統一，這個時候可以先將界面中的信息分成不同的幾個部分，先保證每個部分內的固定內容，再確定自適應的內容。

 

6.2 固定適配內容

在簡單的界面中，由于本身界面的內容比較少，確定位置就會比較難，因為要考慮到不同的界面內容要怎么放才能保持視覺統一，這個時候可以先將界面中的信息分成不同的幾個部分，先保證每個部分內的固定內容，再確定自適應的內容。

 

6.2.1 圖標或按鈕

 

6.2.2 搜索框

 

6.2.3 Y軸間距

一般來說，Y軸的間如果在相近的組件里，都會是固定的，不會有變化

 

6.2.4 圖片

像這種圖片的列表或者，十字縱橫的頭像或文字，大小都是固定的，變得會是間距或者數量，如下圖所示：

對于比較復雜的模塊，快速找到將以上所說的固定因素和自適應因素，除了能夠讓標注效率大大提高之外，還能夠找到合適的適配方法，避免出現開發完成后才發現某機型適配效果不理想的情況。

 

6.3 自適配內容

自適配內容也給大家梳理出來。

6.3.1 文字彈性適配

文字流指在多行文字的情況下，文字數量變化會影像頁面布局和元素大小，如下圖所示：

文字彈性適配一般涉及的是寬度適配。寬度適配普遍使用的是間距適配，即定好左右頁邊距，中間彈性拉伸。當文字左右兩邊有內容的時候，我們需要標明文字可顯示的范圍，也就是說它最多能顯示幾個字。這種方式可以做到較好的適配，也是做快速常用的適配方法。

 

6.3.2 banner

這里說的圖片是指banner或者feed流里的圖片，適配的方法大多都是自適應，界面中的元素間距和數量不變，元素尺寸進行等比縮放，比較適用于固定比例，但尺寸隨屏幕寬度變化的元素，如下圖所示：

對于比較復雜的模塊，快速找到將以上所說的固定因素和自適應因素，除了能夠讓標注效率大大提高之外，還能夠找到合適的適配方法，避免出現開發完成后才發現某機型適配效果不理想的情況。

 

假設視覺還原上真的出了問題，首先要尋找原因，是自己沒做到位？還是對方沒理解你的想法？我感覺可以按照一下幾個方法去做

1. 提升設計輸出質量

設計團隊內部先弄明白改版的意義，畫好標注色值、像素的示意圖和文檔，做好產品原型等任何能讓對方不需糾結，直接可以上手的工作。做好前期的準備工作，盡可能的多做思考，完善設計稿，尤其是邊界情況，把自己的問題留給自己，這樣可能產生的設計還原問題就會大幅減少。多向開發同學請教，即便遇到技術確實難以實現的情況，不要逃避或者過于固執，了解具體原因，不斷累積自己的技術知識。自己的專業、努力是贏得程序員尊重的前提，贏得他們的尊重你才能順利開展工作。

 

2.提高設計師話語權

這是一個比較復雜而且需要長期努力的話題。每個公司都會有其實際情況存在，團隊越大，情況越復雜。設計師團隊或者個人的話語權如果很弱，確實會面對十分被動的處境。首先需要說明的是，話語權是贏得的，而不是賦予的。想要改善被動的局面，要認清所處的環境，問題的癥結，調整定位，并付出努力。只有證明了設計確實能夠解決問題，甚至驅動商業價值，才會逐步提升話語權。

 

3.灌輸用戶體驗的重要性

完成一項任務時最重要的是團隊的思維模式是否統一，設計師在乎用戶體驗，工程師只在乎開發成本。那問題沒辦法達成一致是很正常的。想要讓大家認同你的看法，就要在平常不斷的潛移默化影響別人。比如沒事多跟公司其他人聊產品，聊體驗，聊感受，慢慢給他們灌輸體驗的重要性。只要你的話題有趣，人有趣，沒有人會拒絕跟你聊，時間長了，整個團隊的思路就會有所轉變。

 

4.按照進度和優先級優化

設計師自己可以先按優先級去排布還原順序，看這1像素是否對當前產品重要性。在搞清楚產品進度、優先級的情況下，記錄所有還原問題，自己標記優先級，整理完畢后一次性給他，再跟程序員解決方案和時間。也可以與開發同學共同摸索一套雙方都能接受的清單模式，標明問題，修改建議，重要層級，根據實際情況詳細說明或者簡要說明，能夠當面溝通更佳。

 

5.加強團隊建設

良好的團隊合作氛圍是有效的潤滑劑。好的合作關系如同一條戰壕里的戰友，哪怕多年后回想起來，也應該是一起沖鋒陷陣的光輝歲月。設計師應該認識到自己在整個項目流程中的位置，不卑不亢，把麻煩留給自己，不要推卸責任或者互相推諉，逐步打造自己的聲譽和氣場。

 

結語

一個優質的項目落地是各部門協同合作的成果，就像我們玩游戲，后期高質量的輸出也需要前期優秀的輔助來打鋪墊。在“協同作戰”的基礎上，靈活運用規范、標注和走查的方法來主動推動項目的進行，不僅可以讓設計稿得到最大程度的還原，也可以提升我們協作能力和對環節的把控能力。

任何問題只要多交流，會避免很多阻塞情況。出于設計師的角度當然都希望每一張視覺稿得到100%的還原，因為用戶只看你上線效果，但是往往排期緊張需要一些取舍。我希望能在有限的時間內做到最好。

在后期設計還原的時候，我們可以換位思考，把自己當做程序員，站在他們的角度去思考問題，怎么樣的驗收方式會更方便開發修改，減少重復返工的次數，情愿驗收標注的時候多花10分鐘，也要把修改意見寫詳細，幫開發節省時間，反過來也幫我們自己減少了二次驗收的成本。