我們經常會聽到身邊的設計師與開發哥的一些對話，關于對齊，大小，間距等設計還原問題經常會讨論很久。甚至有時會覺得，幾個像素的間距是不是有必要這麼糾結？
了解設計還原
1.設計還原到底是什麼
「還原」是指事物恢複到原來的狀況或形狀，網際網路中的「設計還原」是說開發後實際界面和設計稿效果有偏差，進行設計校對。
2. 設計還原的現狀
一直以來，設計驗收都不太受重視，一是設計師習慣于把時間用在雕琢設計稿上，而忽略掉後期的設計驗收。二是對自己和合作的程式員極其自信，認為對方能知道到自己所有的點，會完全按照設計稿來。
不同的項目類型還原度也不同：使用者産品>B端産品>背景。對于使用者産品最好是能做到像素級還原。
3.設計還原的意義
在這個快速發展、疊代、更新的時代，網際網路産品的使用者體驗重視度越來越高，而其中的産品設計還原也成為了工作流中重要的一環。
我相信每一名UI設計師，心裡應該都有一個前端能100%還原設計稿的夢想，畢竟那是我們艱苦奮鬥的勞動成果。
而視覺還原的高低與否，則直接取決于設計-開發-測試這些環節的協作品質，不僅僅影響上線産品的使用者體驗，還影響着作為産品設計最後一環的工作品質。
影響設計還原的因素
經過走訪UI/UX設計師、前端工程師和測試工程師的還原設計圖的工作場景。深究原因後，線上效果的失真率其實涉及到設計、前端開發、測試這三個環節，分析造成這種現象出現的原因大概有以下幾點：
1. 從UI設計上來說∶ 視覺處理不規範
- 自由發揮，把界面UI設計當作畫布任意揮灑，完全不考慮實作的難度；
- 标注圖不全，沒有詳盡的對接文檔和設計規範；
- 溝通不到位，評審時沒有将設計思路和易錯點交代清楚
- 沒有考慮設計稿擴充性和前端代碼的邏輯，反複修改，增加FE工作量。
2. 從前端開發來說∶沒有了解設計邏輯
- 時間緊任務重，沒辦法一張一張看标注圖；
- 直男思維，想怎麼寫就怎麼寫，反正最後要上線，細不細緻都一樣；
- 不知道如何解決，内向不肯和UI溝通找到解決方案。
3.從測試走查來說︰傳遞走查不細緻
- 測試混亂，測功能時提UI bug；
- 測試頁面還原時，提UI bug不細緻，用“請參照UI設計稿”概括一切問題。
精準還原的前提
了解開發依據哪些規則還原設計稿，前期的準備工作是重中之重，設定好每一個細節規則，後期落地還原時才會将頁面的失真率降到最低。
1.視覺規範
UI 設計中，設計規範是設計還原一個關鍵步驟。一個好的規範應該是高效的、簡單易懂的。設計規範通常可以把顔色、字型、元件等内容制定成規範，不僅僅保證視覺的一緻性，也極大友善樣式群組件的複用，後期的維護和開發。在規範的輔助下，開發在搭建全局共用控件時規則更加清晰明了，如按鈕、行間距、字型大小、色值等等。
1.1色彩規範
顔色是設計中最重要的元素，顔色的運用與搭配決定設計的品質感。在 UI 設計中，顔色的使用規範主要在于：品牌主色、文本顔色、界面顔色（背景色、線框色）等。
1.2 字型規範
文字是APP主要資訊的表現，尤其是新聞閱讀、社群APP等制定标準的設計規範和良好的排版方式，使用者使用APP也覺得毫無疲勞感，這一點很重要。不同的字型氣質不一樣，并且不同場景下帶給人的感受也不一樣。是以需要在設計的時候考慮到字型的設計效果，然後在設計規範中注明。主要規範标準字的大小，标準字要注意跟上文的标準色進行組合，突出APP重要的資訊和弱化次要的資訊。
1.3圖示規範
在 UI 界面中，具有辨別性質的圖形就是圖示。作為 UI 設計中重要的設計子產品，産品的每個頁面中都有可能存在圖示。
設計規範中，圖示一般按照用途分為兩類：應用圖示、功能圖示。
圖示還應該根據不同的功能需求設計不同的狀态：如常态、選中态、點選态等。
應用圖示：各種應用程式的識别标志，在應用商店裡下載下傳的一些應用程式的标志。
功能圖示：規範中最好标明圖示格式與使用方式。比如 Web 設計，圖檔可以使用 iconfont 管理，可生成代碼傳遞給前端開發；如果是原生 APP，那麼需要标注圖示導出格式與尺寸。
1.4圖檔規範
圖檔作為界面設計的重要組成部分，需要标明尺寸規範，分為不同用途的種類。
1.5控件規範
控件是指産品界面中可操作的部件，與元件是有一些差別的。控件翻譯為 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 個屬性組成的。此外，在盒子模型中，還有寬度 width 和高度 height 兩大輔助性屬性。
舉一個真實界面示例，我們在浏覽器中打開「開發者模式」可以看到網頁的樣式代碼以及目前界面是如何通過「盒子模型」來布局的。
前端并不能簡單的像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；
過程回報：加載狀态、錄入回報、确認彈窗；
結果回報：全局提示、對話框回報；
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-height）。
我以 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.加強團隊建設
良好的團隊合作氛圍是有效的潤滑劑。好的合作關系如同一條戰壕裡的戰友，哪怕多年後回想起來，也應該是一起沖鋒陷陣的光輝歲月。設計師應該認識到自己在整個項目流程中的位置，不卑不亢，把麻煩留給自己，不要推卸責任或者互相推诿，逐漸打造自己的聲譽和氣場。