中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

我們公司前段時間進行了3.0項目的開發，本次項目的進展整體上還是比較順利的，但是還是遇到了很多小插曲，其中最讓人崩潰的就是驗收環節，簡直就是跟技術的一場拉鋸戰。當然這場戰爭的始作俑者并不是某一方，而是每個角色身上都有各種各樣的問題。今天就想來客觀的陳述一下整個過程，希望在下次進行項目推進的時候可以有所改進。

目錄：

1. 我們遇到的問題及解決方案；
2. 提升技術更改Bug的要點；
3. 那些容易出錯的地方。

一、我們遇到的問題及解決方案

前提：之前我們公司對設計還原度要求很低，且技術有較高的話語權，他們就覺得UI界面不重要，所以之前我們是沒有設計驗收環節的，界面的問題提上去也是石沉大海，我們每次進行設計驗收都很沮喪，也不會特別摳細節。

但是最近公司高管有了很大的變動，新來的CEO、CTO和產品總監都對設計要求特別高，當然也就特別看重線上效果，所以就有了這次正式的設計驗收環節。

首先，我想總結一下我們在這次驗收中遇到的幾個主要問題：

1. 技術同學對設計稿的理解度不夠

首先檢討一下設計同學的問題，為了圖自己省事，直接用Sketch Measure 導出標注文件給到技術了，對于有適配需要的地方也沒有進行單獨的標記和說明。所以技術同學就會按照自己對頁面的理解進行布局，到驗收的時候設計同學才發現不是自己想要的結果，這個時候要改動的話就會比較困難。因為一開始的框架就不對，技術也沒有時間重新寫一遍，所以就會有很多問題被擱置。

直接導出的標注對界面的準確性要求也特別高，你必須保證所有的界面都準確無誤，不然就會遇到開發者提出的來自靈魂的質問：“為什么這里是15px，那里是16px，兩邊不一樣，究竟讓我們怎么寫？”

聽到這句話是不是有點不服，但是就是你錯了呀。所以時間允許時還是要手動標注，不但可以減少這種質疑，在標注的時候還會對頁面的細節進行盤查，會發現一些遺漏的狀態和缺失的細節，這樣下來最終提交給技術的設計稿會更加完善。

再者，缺少設計稿評審的環節，這個環節主要給技術講述一些適配要求、交互狀態及動效（我們公司近期撤了交互崗位，所以交互的相關工作需要設計同學進行考慮）；同時解答技術同學的一些疑問，這樣就能將一些可預見的問題解決掉，解決后期的溝通成本。

解決方案：

1. 時間允許，盡量進行手動標注/時間緊張需要適配的地方單獨標記；
2. 技術開發前進行設計稿評審。

2. 設計稿的缺失

這個首先當然是設計師的失責，因為我們提交給技術的設計稿的第一要素就是完整度，到開發進入尾聲才發現缺失，那技術同學只有說“對不起，排期吧”。然后設計同學還一肚子委屈，覺得開發不配合。

下面是設計稿中常見的缺失內容：

1. 頁面極限狀態：無內容、無網絡、加載中；
2. 頁面交互狀態：上滑導航欄固定的樣式、社交操作的交互狀態、下拉刷新樣式、按壓狀態等；
3. 頁面適配：文字的極限情況、屏幕橫向豎向的適配、X和Android等各種極限機型的適配。

這些都應該是在出設計稿的時候就考慮清楚的問題，因為技術是根據你的設計稿進行技術排期的，如果你的頁面不完整，后期再增補導致項目延期，這個責任在誰呢？

3. 技術同學的“不配合”

這里的不配合不是說技術同學偷懶不想干活，原因是多方面的：

1. 設計審核時間太靠后，結果就是在我們提交UI問題的時候，產品也在提交功能型的bug，那技術同學同時拿到這兩個問題，按照問題的優先級來說肯定是先改功能性問題，然后你的問題就被擱置了。
2. 技術沒有完美還原設計稿的意識，還是覺得這件事情沒有那么重要，所以覺得設計師摳像素就是跟他們過不去一樣，其實我們也很無奈，因為設計稿就是一個像素一個像素摳起來的呀。
3. 設計的時候沒有考慮開發的可實現性和實現成本，所以就覺得開發應該完全按照自己的設計稿做出來，做不出來就是不配合，設計師尤其愛說“你看XX大廠能寫出來，你咋就寫不出來呢”，這是極其自大且沒有情商的一種表現。首先大廠的技術團隊實力理論上是比小公司要強；另外我們也要傾聽技術同學的聲音，他們也許是因為排期緊張而做不到呢，所以在批判別人之前要首先想想自己的問題，看到客觀存在的問題，然后一起尋找更好的解決方案。

解決方案：

1. 提前進行設計驗收，最好是提前知道模塊的開發者，這樣后期一對一進行模塊的打版驗收效率更高；
2. 設計時考慮開發成本和可實現性。

4. 設計驗收不完整

之前沒有完整驗收的經驗，所以我們基本上是看到哪里是哪里，沒有一個系統的驗收框架，這樣就會導致在驗收的時候會有缺失，然后會被其他同事發現還挺尷尬的，測試是由測試用例的。所以我們也應該輸出一份設計審核清單，對照表格進行驗收，才能避免遺漏。

5. 通用樣式未進行組件化開發

從源頭來說這個是我們自己的問題，因為沒有將通用模塊進行組件化整理。同時技術同學也沒有這個意識（或者是組內配合度不夠），因為我們本次項目是視覺升級，所以有些模塊的開發者會根據設計稿新出，有些是直接調用之前的樣式，這樣導致的結果就是不同模塊的彈層樣式不一致的尷尬結果。

解決方案：

通用模塊樣式進行組件化整理，比如Toast、對話框、錯誤提示等。協助技術進行組件化開發。

提升技術更改bug效率的要點

1. 不要只是告知技術錯哪里了，而是直接告知技術更改的方案

比如說圖片尺寸錯了，有些設計師就直接標注出來說這里出錯了，請參考設計標注重新調整。另一個設計師不僅標注哪里錯了，還直接標出這個圖片尺寸是多大。很明顯技術看第二個設計師給的驗收文檔更改的效率更高。

2. 間距錯，直接告知需要增減多少

這個是本次驗收的時候發現的一個很大的問題，由于文字內邊距的影響，開發同學按照設計稿標注數值寫出來的頁面跟設計稿有偏差，這個時候我們就需要比對實際頁面和設計稿之間的差距，直接告知技術應該增減多少像素，不然問題很難解決。

另外，我們之前在進行頁面設計的時候習慣于將文字大小和行高設置一樣的大小，這種方式是不對的，因為Android和IOS系統默認的字體都有內邊距，并且Sketch默認的文字內邊距跟IOS的默認字是一樣的; Android系統文字的內邊距會比Sketch的大一丟丟，這種誤差是在可接受范圍內的，如果開發時間很緊的情況下，可以忽略不計。所以進行頁面設計的時候不用手動調整文字行高

三、容易出問題的地方

同時我們發現技術開發的過程中有兩個地方是非常容易出錯的，并且調整起來的修改成本也比較高，主要有三個地方投影、間隔線、文字加粗。

1. 投影

投影最好少用為妙，首先是因為技術實現成本很高，其次即使寫出來了跟你想要的樣式偏差也會很大，需要不斷的溝通調整，會花費很長的時間；再者多個投影卡片聚合在一起的時候，進行多機型適配，能把設計師和技術同學都折磨瘋的。所以為了節省開發成本，呵護我們和開發同學友誼的小船，能少用盡量少用。

2. 間隔線

間隔線不管在幾倍的機型下，都應該保持1px的線條高度，但是很多時候技術開發的時候并沒有注意到這種適配方式，結果就是在2倍機型下是顯示2px，3倍機型下顯示3px。這個問題很容易出現也很容易避免，就是將線條適配規則跟所有的技術同學周知一下即可。

3. Android加粗

Android的系統默認字體是思源，在系統默認的字體庫里（我們的技術同學告知的）只有3個自重，細體、常規體、和超粗字體，導致的結果就是Android機型上的加粗字體會顯得格外粗重。我們摸索出一個解決方案就是Android字體加粗的時候減少一個字號，這樣頁面才能顯得平衡。

總結

以上就是我們本次開發驗收過程中發現的問題和一些小小的經驗，希望我們的驗收總結可以給大家一些啟發和借鑒。

當然如果有更好的解決方式也歡迎留言告知我，我非常樂意傾聽大家的意見，期待更好的解決方案。

參考文獻：

《最好的UI設計師》· 顏偉(海邊來的設計師) · 電子工業出版社 · 2018第九章 驗收

本文由 @Wendy 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議