前端開發面對設計稿的相關思考

一份設計稿新鮮出爐，你是否是摩拳擦掌，立刻就開工了？

不不不，這裏有坑！產品經理或者交互設計師可能更關注總體交互邏輯，視覺設計師可能更關注頁面的總體美觀度，而你，是要一點點實現出來的人，你更須要思考的是一些細節問題。

動手前來一波提神醒腦的小思考，讓你事半功倍。

從元素角度，檢查缺失的樣式

視覺稿上常常會缺失一些元素，咋一看不會影響總體交互，作的時候才發現有缺漏，就須要反覆溝通這些細節。畢竟設計師也不是隨時有空的，因此儘可能在開工以前就把這些交互樣式一次性與設計師確認好。

• checkbox/radio是否只有勾選或者未勾選的樣式
• 按鈕的hover/disabled樣式是否缺失
• 菜單的hover樣式是否與高亮樣式一致
• 表單是否缺乏校驗提示
• 結果頁（通常是成功/失敗/處理中等）是否有缺失
• 請求中或者頁面加載中是否須要loading處理
• 頁面若無數據應該如何展現
• ...

上面這幾點，就是缺失的高頻元素。此外，還須要審視的地方：

• 若不一樣頁面間類似的元素樣式不一樣，以哪處爲準，儘可能保持統一，若須要不一樣，與設計師溝通好需求
• 切圖是否有遺漏，有時候設計師提供的由sketch導出的html文件內圖標沒有合併，沒法直接切圖，能夠告知設計師切圖或者拿到源文件本身動手
• ...

第一步是一個快速反應的過程，好比看到checkbox就立刻檢查各類勾選狀態樣式是否齊全，看到結果頁就覈對多種狀態是否齊全，這個步驟只須要快速審視頁面上的元素便可。

從組件角度，判斷樣式複用度

拿到一份設計稿時，千萬不要打開第一頁就急匆匆地開始作，這樣等你打開第二頁就會發現，啊蒼天啊！那麼多元素是類似的，可是你前面都作死了，重寫一份效率低，要改又很麻煩。

簡單舉個例子，好比某一頁設計稿上頂部有兩個tab，你直接width: 50%;。

然鵝，不幸的事情發生了，你打開下一頁設計稿，發現這一頁的tab是3個。

這只是最簡單的狀況，修改起來也很快，可是若是一開始你就考慮到tab的數量可能未知，從組件的角度考慮直接用flex佈局就是極好的，這樣不管是一個兩個仍是三個四個你都不須要再改了，樣式的可拓展性就很是強👍。

第二步，把前先後後的設計稿都翻閱一遍，內心大概有個底，哪裏樣式類似能夠抽成UI組件，哪裏效果複雜須要重點關注。

從總體角度，做爲用戶去體驗

最後就是把本身當成一個挑剔又無聊的用戶，來審視整一份設計稿/交互稿，把總體的流程在腦海中過一遍，查看是否在交互上有缺失的地方，提早溝通效率翻倍。

好比：

• 有修改密碼的按鈕卻沒有對應點擊後的交互和樣式？
• 活動頁上有不少活動綵帶，是否須要添加動畫加強交互效果？
• 某個按鈕優先級明顯較高，就放到很深的層級，是否須要調整？
• ...

這裏可能會以爲跟第一步檢查是否有缺失的元素有重複，而個人理解是，第一步是一個根據工做經驗快速反應的過程，而最後這一步，是須要認真理解交互的，把設計稿/交互稿當成一個產品去體驗，根據你的重構經驗和做爲用戶的體驗，把不合理的地方提出來討論。

最後一步，不要以爲你只須要把頁面實現出來，交互有別的專業同事去思考。每一個人考慮的點有所不一樣，這個你們共同努力的產品也會在討論中更加豐富和完整。

思考以上問題的時候快速把問題記下來，交給產品同事或者設計師及時補充，這樣就能夠邊開工邊等着補充的內容，不會出現總體作完了卻有不少細節被遺漏，須要等待的狀況。

另外完工後也能夠本身再對着前期的問題進行檢視，畢竟出現過遺漏的話說明這是一個須要關注的問題。

其實面對設計稿的思考，無非就是站在重構的角度上，把隱藏的問題提早拋出，提升溝通效率，減小無謂的等待時間和糾結時間，工做效率天然upupup。