在 B 端項目中，經常會出現這樣的問題：一個新項目/新功能作為開發人員，他會優先考慮產品功能，而會忽視對于最終頁面呈現的還原度，也就是大家經常提起的“功能優先”，設計稿經常不還原。當我們遇到這樣的情況時，究竟應該如何處理？

我相信很多 B 端設計師都會在工作當中遇到這類問題，因此咱們就來聊聊當項目本身不重視設計，應該怎么辦？

重視自己

我見過同學都會抱怨設計頁面還原很糟糕，導致他不情愿將自己更多的精力花在的設計頁面上，進而在公司常常無所事事（mo yu）

首先給大家講的就是自己重視自己，因為很多設計師遇到這類情況就會自暴自棄，對于頁面細節的驗收也不會太過于上心（設計師會說：提出來他們也不改，后面也不想再提了）導致的結果就是隨著日積月累，一個頁面缺少 20%的設計細節，十個頁面、五十個頁面？或許就會是一個災難

因此在設計不受重視時，首先要做的就是自己重視自己。在工作產出上做到用心、負責，對于需求、設計驗收都認真對待，因為只有自己做好了，這樣才能夠要求團隊的其他成員進行協助

比如一個版本結束后，將設計細節當中的不同問題指派給不同的前端工程師，將頁面上各類設計細節進行明確的標注，這樣都能夠讓研發同事知道你對待工作的態度。一個項目團隊，肯定不會討厭一個認真負責的人

這里建議大家能夠有一個固定的設計驗收表，這樣能夠幫助你。模版不一定是固定，可以根據自己公司的特點進行修改調整
https://d2btn5y74y.feishu.cn/sheets/shtcnUPb1fXtjmwkL5ugxLw6g5r

提出問題

出現上述的問題，其實本質上是“項目趕工”所導致的。我曾經和很多開發都深入聊過這類問題，他們也不是想要刁難咱們，更多是因為項目功能的開發時間都不夠，更別提設計細節

而目前大多數團隊的項目開發方式還是采取 “敏捷開發” （與之相背離的是瀑布流開發，如果不了解的同學可以進行百度），因此在每一個迭代的初期，都可以和項目負責人進行溝通，明確出設計細節還原的具體時間以及設計細節還原要求

這樣能夠在項目剛開始，就和大家明確項目設計要求，比如這一期因為對于功能來說，確實是比較復雜，這樣作為設計師也知道項目整體情況，對于要求進行適當的放寬，那究竟如何放寬，就需要有一個頁面還原相對量化的標準

頁面還原的標準

設定一個頁面還原的基礎標準，本質上是在幫助對開發同學，在理解設計細節上有更深的認識。很多時候你會發現是，一些很明顯的錯誤他們其實是不知道的，比如一個淺灰色和白色，對于他們而言感官上都比較類似，而一些很小的細節作為開發人員很難觀察到，而通過一個標準，他可以對自己的頁面進行檢查，看看是否有問題，比如：

基礎階段：

頁面布局形式、顏色色值、字體大小、控件使用、關鍵元素缺失

中級階段：

描邊的粗細、細節背景顏色上的區分、設計資源的模糊

高級階段：

控件動效、頁面內容文案、提示信息...

當然在這里只是一個簡單舉例，指定頁面還原標準的最終目的是能夠讓開發有量化的標準進而能有更好態度對待設計師、設計細節。并且標準的確定，能夠幫助你在會議上明確迭代標準，進一步提高團隊間的協作效率。而人總是會犯錯的，比如我寫文章也會偶爾出現錯別字，因此在嚴苛過后也要互相理解

當然除了標準，Design Token 也能夠幫助前端快速理解基礎樣式，之后有時間可以單獨來講

明確后續迭代時間

當我們首先做好自己，接提出問題，然后確定好還原標準后，最主要的就是需要在一個版本后知道剩余的問題究竟應該在何時進行完善

通常解決時間存在兩種不同的情況：

1. 在后續 1 - 2 個版本進行迭代，將之前的問題進行解決
2. 將問題匯總，后續進行一次體驗上的大版本更新

這兩種方法本身并沒有什么好壞之分，對于我們而言，就需要將設計細節上的各類問題進行匯總，也會要求設計師需要有一個屬于自己的設計體驗需求池：

通常這類需求池會包括以下幾類問題：

問題描述、問題圖片、負責前端、以及后續迭代時間等等…

這樣等問題出現過后，就能夠確定相應問題對應的開發人員以及后續的時間。畢竟表格是項目管理當中最好用的工具

真誠溝通

當你在團隊當中遇到問題時，更應該多和團隊成員協商溝通。因為都是同事，溝通解決問題才是成年人做事的風格。比如吃一頓飯聊聊問題，大家下樓抽抽煙一起聊聊，偶爾買杯奶茶犒勞為頁面辛苦還原的前端同學，有時候緊張的氛圍往往因為一兩句玩笑就能夠得到舒緩。希望大家都能夠在工作當中順順利利，少一些煩心事（下一期，安利幾款插件，讓頁面驗收嗖嗖嗖~）

在評論區說說實際項目當中，遇到過哪些奇葩事？

歡迎關注作者的微信公眾號：CE青年