一、設(shè)計稿文字圖片不要一樣

剛做UI的時候，根本就沒有注意設(shè)計稿文字圖片要保持不一樣。

我以為這些圖片和文字都是后臺配置，認(rèn)為沒有必要單獨去做啊，這不是浪費時間么，本來項目那么緊，那時候做的項目基本和下圖一樣，圖片文字都一模一樣。

直到有一次去面試，面試官問我:＂為什么你的設(shè)計稿圖片文字都是一樣的呢？＂，我對他說，＂因為這些是后臺配置的，所以我就覺得沒有必要設(shè)計＂。他反問道，＂你不設(shè)計出來，我怎么知道這個界面好不好？＂，就這樣短短聊了幾句，他就讓我回家等通知了。

但那時候我并沒有在意，直到后來工作中領(lǐng)導(dǎo)又問了同樣的問題，我才回來做了一個實驗，在網(wǎng)上找一張設(shè)計還不錯的案例，這個界面整體給人清爽簡潔、配圖活躍個性的感覺。

image

然后在將里面的圖都改成一樣的，我就發(fā)現(xiàn)改完之后，確實很難判斷這個界面的好壞，尤其像這種內(nèi)容少圖片多的界面，他的成敗其實重點就在配圖上，如下圖：

image

后來在做設(shè)計稿時，不管在忙，我都會把圖、文字好好編輯，哪怕圖可以丑一點，但是一定要保證不一樣的內(nèi)容。

二、別用其他組件代替

在設(shè)計時，一定不要為了省事直接用其他平臺的組件來代替，這直接會導(dǎo)致設(shè)計效果和規(guī)范的不統(tǒng)一，同時還會浪費大量的溝通時間。

比如我們公司的后臺界面用的 View Ul的框架，現(xiàn)在需要給公司的后臺進(jìn)行優(yōu)化，但是我手上又沒有View的組件庫，如果重新畫感覺有點浪費時間，如下圖：

image

于是想著反正手上有現(xiàn)成的螞蟻金服后臺組件庫，要不直接拖過來用，大不了后面給前端說下，設(shè)計稿只是整體效果，具體的控件還是用原來的樣式。

image

但是，我以為這樣囑咐了前端就沒問題了實際上前端其實搞不懂哪些是用原來的，哪些用現(xiàn)在的，或者他干脆忘記我說的話了，直接就按照設(shè)計稿上來實現(xiàn)了，結(jié)果驗收時才發(fā)現(xiàn)又得重新調(diào)整。

最后，我本來只需花20分鐘畫套控件，但是我卻花了2個小時來和前端溝通，重要的是還浪費了前端的時間。

這件事情讓我明白，有些懶你偷了，遲早是要加倍還回來的。

1、極限值要考慮全面

在設(shè)計時，一定要把極限值考慮全面，我之前在設(shè)計數(shù)據(jù)頁面時，就上過一次當(dāng)。

我在設(shè)計數(shù)據(jù)頁面時，由于整個界面都是數(shù)據(jù)，沒有圖片，因此想著用圖標(biāo)來豐富一下。但是卻忘記了解數(shù)據(jù)最大會顯示多少位，就導(dǎo)致上線后才發(fā)現(xiàn)當(dāng)前樣式容納不下，真實數(shù)據(jù)最長有7位數(shù)，然后我這最大只能展示5位。

image

于是領(lǐng)導(dǎo)通知馬上調(diào)整一版新的出來，于是我只能將圖標(biāo)刪掉，保證數(shù)據(jù)展示出來。如果這樣的情況多次發(fā)生，我想這個月的績效就只能得C了。

image

因此，為了避免這樣的情況再次發(fā)生，我想著要不把界面中常用到的極限值都總結(jié)出來，下次在設(shè)計時就不會這樣手忙腳亂了。

2、列表

• 需要注意標(biāo)題的長短、標(biāo)題過長最多展示幾行、如何做截斷處理；
• 描述文字過長如何處理，是否展開收起；
• 列表中，兩個不確定長短的內(nèi)容，不要排一行，避免內(nèi)容過多排不下；
• 考慮各角色參數(shù)的變化，進(jìn)行適配；
• 考慮圖片適配規(guī)則；
• 考慮交互手勢操作；
• 標(biāo)題域最多支持幾個字，超過如何展示。

3、表單

• 輸入域展示寬度確定；
• 對于地址、備注等文本框當(dāng)文字超過一行如何展現(xiàn)，是滾動還是換行，輸入文字是否有限制數(shù)量；
• 考慮當(dāng)標(biāo)題超過1行如何顯示，

4、彈窗、提示框、控制面板等

• 當(dāng)內(nèi)容超過一行如何顯示；
• 后臺獲取的數(shù)字、文字一定要去后臺確定最長數(shù)據(jù)，保證當(dāng)前設(shè)計能夠承載。

三、所有流程都需展示出來

在設(shè)計時，一定要把整個流程的界面都設(shè)計出來，哪怕是一個 Toast、一個彈窗也要展示出來。

我就犯過這樣的問題，之前我在設(shè)計購物車列表時，界面中有個刪除按鈕，需要二次確認(rèn)彈窗，類似下圖當(dāng)當(dāng)上面的彈窗，于是我口頭告知前端這里直接加個二次確認(rèn)的彈窗組件即可，我就不畫出來了，但是由于時間比較長，他們寫的時候就忘記了。

image

后來也是在驗收時才發(fā)現(xiàn)，刪除的時候直接就刪除了，沒有二次確認(rèn)，收藏成功也沒有提示。這時候只好在拜托前端加上。

因此這次的教訓(xùn)告訴我，盡量將各流程都畫出來，不僅可以讓自己邏輯更清晰，不易漏掉界面，同時也不怕前端忘記，從而減少溝通成本。

四、所有狀態(tài)都應(yīng)設(shè)計出來

界面中的狀態(tài)，以前我都是根據(jù)自己的經(jīng)驗來設(shè)計，但是人腦有時候是最不靠譜的，當(dāng)我們大腦高度緊張時，就容易出現(xiàn)漏考慮的情況。

比如下面貝殼的提交表單，在設(shè)計時我們需要考慮默認(rèn)態(tài)是什么，選中是什么；預(yù)算金額的滑塊最小時如何顯示，最大時如何顯示；選擇區(qū)域時默認(rèn)是什么狀態(tài)、選中是什么狀態(tài)，聯(lián)動的狀態(tài)又是什么。鍵盤彈起的默認(rèn)狀態(tài)和輸入狀態(tài)，鍵盤收起彈出收起的交互操作，以及提示、成功、失敗等反饋的效果都需要設(shè)計出來。

image

是不是看著腦袋都很暈，這種表單流程，我在設(shè)計時就很容易將地址聯(lián)動、鍵盤交互這些漏掉。因此為了避免這種情況發(fā)生，我同樣根據(jù)項目制作了一份常見的狀態(tài)表，避免考慮不周全的情況。

1、列表

• 空狀態(tài)如何顯示，是否需要引導(dǎo)
• 列表標(biāo)題過長如何顯示
• 描述文字為空、正常、過長如何顯示
• 翻頁加載樣式、沒有更多內(nèi)容的樣式
• 數(shù)據(jù)加載提示
• 默認(rèn)狀態(tài)、點擊狀態(tài)、長按狀態(tài)

2、表單輸入

• 考慮默認(rèn)狀態(tài)、編輯狀態(tài)、常態(tài)
• 輸入時的鍵盤交互操作
• 報錯、網(wǎng)絡(luò)斷開、成功、失敗等提示
• 編輯后跳轉(zhuǎn)到哪里？是直接跳轉(zhuǎn)到列表，還是需要展示預(yù)覽輸入有邏輯關(guān)系的內(nèi)容如何交互
• 輸入出行意外該如何處理，是否保存，需要做什么操作輸入特殊字符是否做限制

3、按鈕

• 正常、觸發(fā)、禁用、加載等狀態(tài)

4、搜索

• 在當(dāng)前頁操作，還是跳轉(zhuǎn)到新頁面
• 實時搜索，還是提交后才更新數(shù)據(jù)
• 正常態(tài)、觸發(fā)態(tài)、輸入態(tài)、提交態(tài)
• 歷史記錄最多展示幾條數(shù)據(jù)？是否支持清空

參考資料

小公司沒人帶如何提升自己，我是這樣做的！