面對讓人“崩潰”的設(shè)計驗(yàn)收,我們要如何解決?
我們公司前段時間進(jìn)行了3.0項(xiàng)目的開發(fā),本次項(xiàng)目的進(jìn)展整體上還是比較順利的,但是還是遇到了很多小插曲,其中最讓人崩潰的就是驗(yàn)收環(huán)節(jié),簡直就是跟技術(shù)的一場拉鋸戰(zhàn)。當(dāng)然這場戰(zhàn)爭的始作俑者并不是某一方,而是每個角色身上都有各種各樣的問題。今天就想來客觀的陳述一下整個過程,希望在下次進(jìn)行項(xiàng)目推進(jìn)的時候可以有所改進(jìn)。
目錄:
- 我們遇到的問題及解決方案;
- 提升技術(shù)更改Bug的要點(diǎn);
- 那些容易出錯的地方。
一、我們遇到的問題及解決方案
前提:之前我們公司對設(shè)計還原度要求很低,且技術(shù)有較高的話語權(quán),他們就覺得UI界面不重要,所以之前我們是沒有設(shè)計驗(yàn)收環(huán)節(jié)的,界面的問題提上去也是石沉大海,我們每次進(jìn)行設(shè)計驗(yàn)收都很沮喪,也不會特別摳細(xì)節(jié)。
但是最近公司高管有了很大的變動,新來的CEO、CTO和產(chǎn)品總監(jiān)都對設(shè)計要求特別高,當(dāng)然也就特別看重線上效果,所以就有了這次正式的設(shè)計驗(yàn)收環(huán)節(jié)。
首先,我想總結(jié)一下我們在這次驗(yàn)收中遇到的幾個主要問題:
1. 技術(shù)同學(xué)對設(shè)計稿的理解度不夠
首先檢討一下設(shè)計同學(xué)的問題,為了圖自己省事,直接用Sketch Measure 導(dǎo)出標(biāo)注文件給到技術(shù)了,對于有適配需要的地方也沒有進(jìn)行單獨(dú)的標(biāo)記和說明。所以技術(shù)同學(xué)就會按照自己對頁面的理解進(jìn)行布局,到驗(yàn)收的時候設(shè)計同學(xué)才發(fā)現(xiàn)不是自己想要的結(jié)果,這個時候要改動的話就會比較困難。因?yàn)橐婚_始的框架就不對,技術(shù)也沒有時間重新寫一遍,所以就會有很多問題被擱置。
直接導(dǎo)出的標(biāo)注對界面的準(zhǔn)確性要求也特別高,你必須保證所有的界面都準(zhǔn)確無誤,不然就會遇到開發(fā)者提出的來自靈魂的質(zhì)問:“為什么這里是15px,那里是16px,兩邊不一樣,究竟讓我們怎么寫?”
聽到這句話是不是有點(diǎn)不服,但是就是你錯了呀。所以時間允許時還是要手動標(biāo)注,不但可以減少這種質(zhì)疑,在標(biāo)注的時候還會對頁面的細(xì)節(jié)進(jìn)行盤查,會發(fā)現(xiàn)一些遺漏的狀態(tài)和缺失的細(xì)節(jié),這樣下來最終提交給技術(shù)的設(shè)計稿會更加完善。
再者,缺少設(shè)計稿評審的環(huán)節(jié),這個環(huán)節(jié)主要給技術(shù)講述一些適配要求、交互狀態(tài)及動效(我們公司近期撤了交互崗位,所以交互的相關(guān)工作需要設(shè)計同學(xué)進(jìn)行考慮);同時解答技術(shù)同學(xué)的一些疑問,這樣就能將一些可預(yù)見的問題解決掉,解決后期的溝通成本。
解決方案:
- 時間允許,盡量進(jìn)行手動標(biāo)注/時間緊張需要適配的地方單獨(dú)標(biāo)記;
- 技術(shù)開發(fā)前進(jìn)行設(shè)計稿評審。
2. 設(shè)計稿的缺失
這個首先當(dāng)然是設(shè)計師的失責(zé),因?yàn)槲覀兲峤唤o技術(shù)的設(shè)計稿的第一要素就是完整度,到開發(fā)進(jìn)入尾聲才發(fā)現(xiàn)缺失,那技術(shù)同學(xué)只有說“對不起,排期吧”。然后設(shè)計同學(xué)還一肚子委屈,覺得開發(fā)不配合。
下面是設(shè)計稿中常見的缺失內(nèi)容:
- 頁面極限狀態(tài):無內(nèi)容、無網(wǎng)絡(luò)、加載中;
- 頁面交互狀態(tài):上滑導(dǎo)航欄固定的樣式、社交操作的交互狀態(tài)、下拉刷新樣式、按壓狀態(tài)等;
- 頁面適配:文字的極限情況、屏幕橫向豎向的適配、X和Android等各種極限機(jī)型的適配。
這些都應(yīng)該是在出設(shè)計稿的時候就考慮清楚的問題,因?yàn)榧夹g(shù)是根據(jù)你的設(shè)計稿進(jìn)行技術(shù)排期的,如果你的頁面不完整,后期再增補(bǔ)導(dǎo)致項(xiàng)目延期,這個責(zé)任在誰呢?
3. 技術(shù)同學(xué)的“不配合”
這里的不配合不是說技術(shù)同學(xué)偷懶不想干活,原因是多方面的:
- 設(shè)計審核時間太靠后,結(jié)果就是在我們提交UI問題的時候,產(chǎn)品也在提交功能型的bug,那技術(shù)同學(xué)同時拿到這兩個問題,按照問題的優(yōu)先級來說肯定是先改功能性問題,然后你的問題就被擱置了。
- 技術(shù)沒有完美還原設(shè)計稿的意識,還是覺得這件事情沒有那么重要,所以覺得設(shè)計師摳像素就是跟他們過不去一樣,其實(shí)我們也很無奈,因?yàn)樵O(shè)計稿就是一個像素一個像素?fù)钙饋淼难健?/li>
- 設(shè)計的時候沒有考慮開發(fā)的可實(shí)現(xiàn)性和實(shí)現(xiàn)成本,所以就覺得開發(fā)應(yīng)該完全按照自己的設(shè)計稿做出來,做不出來就是不配合,設(shè)計師尤其愛說“你看XX大廠能寫出來,你咋就寫不出來呢”,這是極其自大且沒有情商的一種表現(xiàn)。首先大廠的技術(shù)團(tuán)隊(duì)實(shí)力理論上是比小公司要強(qiáng);另外我們也要傾聽技術(shù)同學(xué)的聲音,他們也許是因?yàn)榕牌诰o張而做不到呢,所以在批判別人之前要首先想想自己的問題,看到客觀存在的問題,然后一起尋找更好的解決方案。
解決方案:
- 提前進(jìn)行設(shè)計驗(yàn)收,最好是提前知道模塊的開發(fā)者,這樣后期一對一進(jìn)行模塊的打版驗(yàn)收效率更高;
- 設(shè)計時考慮開發(fā)成本和可實(shí)現(xiàn)性。
4. 設(shè)計驗(yàn)收不完整
之前沒有完整驗(yàn)收的經(jīng)驗(yàn),所以我們基本上是看到哪里是哪里,沒有一個系統(tǒng)的驗(yàn)收框架,這樣就會導(dǎo)致在驗(yàn)收的時候會有缺失,然后會被其他同事發(fā)現(xiàn)還挺尷尬的,測試是由測試用例的。所以我們也應(yīng)該輸出一份設(shè)計審核清單,對照表格進(jìn)行驗(yàn)收,才能避免遺漏。
5. 通用樣式未進(jìn)行組件化開發(fā)
從源頭來說這個是我們自己的問題,因?yàn)闆]有將通用模塊進(jìn)行組件化整理。同時技術(shù)同學(xué)也沒有這個意識(或者是組內(nèi)配合度不夠),因?yàn)槲覀儽敬雾?xiàng)目是視覺升級,所以有些模塊的開發(fā)者會根據(jù)設(shè)計稿新出,有些是直接調(diào)用之前的樣式,這樣導(dǎo)致的結(jié)果就是不同模塊的彈層樣式不一致的尷尬結(jié)果。
解決方案:
通用模塊樣式進(jìn)行組件化整理,比如Toast、對話框、錯誤提示等。協(xié)助技術(shù)進(jìn)行組件化開發(fā)。
提升技術(shù)更改bug效率的要點(diǎn)
1. 不要只是告知技術(shù)錯哪里了,而是直接告知技術(shù)更改的方案
比如說圖片尺寸錯了,有些設(shè)計師就直接標(biāo)注出來說這里出錯了,請參考設(shè)計標(biāo)注重新調(diào)整。另一個設(shè)計師不僅標(biāo)注哪里錯了,還直接標(biāo)出這個圖片尺寸是多大。很明顯技術(shù)看第二個設(shè)計師給的驗(yàn)收文檔更改的效率更高。
2. 間距錯,直接告知需要增減多少
這個是本次驗(yàn)收的時候發(fā)現(xiàn)的一個很大的問題,由于文字內(nèi)邊距的影響,開發(fā)同學(xué)按照設(shè)計稿標(biāo)注數(shù)值寫出來的頁面跟設(shè)計稿有偏差,這個時候我們就需要比對實(shí)際頁面和設(shè)計稿之間的差距,直接告知技術(shù)應(yīng)該增減多少像素,不然問題很難解決。
另外,我們之前在進(jìn)行頁面設(shè)計的時候習(xí)慣于將文字大小和行高設(shè)置一樣的大小,這種方式是不對的,因?yàn)锳ndroid和IOS系統(tǒng)默認(rèn)的字體都有內(nèi)邊距,并且Sketch默認(rèn)的文字內(nèi)邊距跟IOS的默認(rèn)字是一樣的; Android系統(tǒng)文字的內(nèi)邊距會比Sketch的大一丟丟,這種誤差是在可接受范圍內(nèi)的,如果開發(fā)時間很緊的情況下,可以忽略不計。所以進(jìn)行頁面設(shè)計的時候不用手動調(diào)整文字行高
三、容易出問題的地方
同時我們發(fā)現(xiàn)技術(shù)開發(fā)的過程中有兩個地方是非常容易出錯的,并且調(diào)整起來的修改成本也比較高,主要有三個地方投影、間隔線、文字加粗。
1. 投影
投影最好少用為妙,首先是因?yàn)榧夹g(shù)實(shí)現(xiàn)成本很高,其次即使寫出來了跟你想要的樣式偏差也會很大,需要不斷的溝通調(diào)整,會花費(fèi)很長的時間;再者多個投影卡片聚合在一起的時候,進(jìn)行多機(jī)型適配,能把設(shè)計師和技術(shù)同學(xué)都折磨瘋的。所以為了節(jié)省開發(fā)成本,呵護(hù)我們和開發(fā)同學(xué)友誼的小船,能少用盡量少用。
2. 間隔線
間隔線不管在幾倍的機(jī)型下,都應(yīng)該保持1px的線條高度,但是很多時候技術(shù)開發(fā)的時候并沒有注意到這種適配方式,結(jié)果就是在2倍機(jī)型下是顯示2px,3倍機(jī)型下顯示3px。這個問題很容易出現(xiàn)也很容易避免,就是將線條適配規(guī)則跟所有的技術(shù)同學(xué)周知一下即可。
3. Android加粗
Android的系統(tǒng)默認(rèn)字體是思源,在系統(tǒng)默認(rèn)的字體庫里(我們的技術(shù)同學(xué)告知的)只有3個自重,細(xì)體、常規(guī)體、和超粗字體,導(dǎo)致的結(jié)果就是Android機(jī)型上的加粗字體會顯得格外粗重。我們摸索出一個解決方案就是Android字體加粗的時候減少一個字號,這樣頁面才能顯得平衡。
總結(jié)
以上就是我們本次開發(fā)驗(yàn)收過程中發(fā)現(xiàn)的問題和一些小小的經(jīng)驗(yàn),希望我們的驗(yàn)收總結(jié)可以給大家一些啟發(fā)和借鑒。
當(dāng)然如果有更好的解決方式也歡迎留言告知我,我非常樂意傾聽大家的意見,期待更好的解決方案。
參考文獻(xiàn):
《最好的UI設(shè)計師》· 顏偉(海邊來的設(shè)計師) · 電子工業(yè)出版社 · 2018第九章 驗(yàn)收
本文由 @Wendy 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
寫的很棒,關(guān)注了,期待再次分享!
安卓加粗這個問題困擾我很久了…收獲了收獲了~
??????
總結(jié)的教訓(xùn)值得吸取……這里有個疑問,在設(shè)計審核清單時,因?yàn)椴煌脑O(shè)計活動,審核機(jī)制和內(nèi)容是不同的,你如何確保你設(shè)計的審核清單是完整的呢?在這一點(diǎn)上是否能給出自己的見解或者思考路徑呢?
可以說2/3的問題都是缺少交互干預(yù)造成的~
總體很受益
期待你后續(xù)的作品
我會持續(xù)關(guān)注
為啥撤掉交互崗位….感覺很多坑例如設(shè)計稿的缺失里的問題是交互撤掉造成的