五大中心關鍵要素，如何能讓設計稿復原度像我們原版視覺一樣
定稿前的評審
整理一份標注文檔
向開發宣講標注
積極響應開發的每一個疑問
開發復原度檢視
1. 定稿前的評審
和誰評審?這里當然是和產品經理，設計指導，還有開發同窗，測試妹妹們(為什么沒有boss，由于boss你基本看不到啦)。
當然在最開端初期不需求叫這么多人，直接和設計指導就好了，由于版落地設計，是需求屢次評審的，所以前期這里我們就不談了，那么在設計中期評審就一定要拉上產品鏈中的關鍵角色。
首先評審的時分一定要把改版視覺變化更大的要和開發闡明分明，規劃框架改動都會增加開發工作量，能否完成或者完成能否功耗很高(普通有動效就會有很大功耗)，這時分開發leader 就會在這里提早預估判別下，由于這個環節假如不把握好，到后期假如呈現不測，完成難度大，那么就又得重新修正視覺，那時分，時間是十分慌張的，所以一定要把握好各個關節環節
這里有人會問，框架前期不是交互曾經和開發評審了嗎?這個不一定的，由于假如我們在設計過程中，靈感迸發，有些之前想的不到位的，這時分可能會做一些改動啥的，搞不好就把部分框架改了一些，所以一定要留意這些細節點。
這個環節把握好了，那根本都能完成出來，特殊狀況除外，比方前期疏忽了一些后臺數據的問題
為什么要整理一份標注文檔?
這里文檔不一定要非常嚴厲的依照交互文檔或者視覺標準文檔來做，能夠簡易的做，關鍵是能讓開發看得懂。
文檔里面放什么?是全部放?
假如是小版本迭代，那么相對簡單一些，由于前面幾本控件曾經有了，只需標注里面寫分明了，能夠不需求寫文檔。
那假如是大版本迭代呢?比方7.0到8.0一個全新的視覺言語，那么這時分就必需整理一份文檔。
文檔里面就把這次更新迭代的共同的頁面整理出來，公共控件，整理出來標注一份就好了，然后闡明細節處置問題。
比方：
list幾品種型，單雙行高度，假如是動態list，那么寫明字符截斷規則，假如能夠允許換行，那么寫分明最多換幾行，普通最多3(多言語時分用)，超大形式如何處置?普通list文字上下都會標有一個高度，這樣即便是超大形式，超大字體也不會招致控件交叉。
導航在超大形式下處置規則如何，多言語如何換行(比方阿語)，換行規則是什么?先減少字體，在換行?等等
圖片宮格規劃類型的如何處置，小屏和大屏顯現幾個(指的是phone和pad)，橫豎屏顯現規則是什么，如何完成自順應規劃等
記住banner一定要給出比例，常用21:916:94:3
十分關鍵的一點，設計師標注一定要把點擊區域標注出來，假如你不標注出來，開發直接拿你切圖填充進去，然后最后招致可用性十分差，最后招致來回調試。
這個環節是標注的中心局部，十分細微的復原完成這步十分關鍵
3. 向開發宣講標注
為什么要向開發走讀layout? 由于有些細微的中央需求我們特別像開發闡明，也加深他們的映像，在完成時分就減少出錯，像開發走讀的時分，只把關鍵中心點，規則講分明，我們前面每走一步，都是為了后面我們檢視復原度的時分要輕松一些，開發也輕松一些，就比方前期根底沒打好，后面深化很難。(假如大視覺沒復原好，如何叫開發打磨細節?)
4. 積極響應開發的每一個疑問
在開發慌張環節中，即便我們前面一切工作都準備好了，也很難防止開發不找我溝通，這時分我們要積極回應他們，并且和他們一同處置問題，比方某些難度大一點的頁面，開發完成效果和設計稿差別不小，那么這時分，開發會截一張他們完成的效果圖給你看，這時你就要認真去找問題，不要一口咬定就是開發的緣由，先溝通詳細緣由，然后找出處理方法，假如是標注呈現問題，比方標注標死了，頁面不靈敏，適配局限性很大。
