職場上,設計師應有的技能
最近團隊來了很多有潛力的小萌新,想起以前自己一步步踩過的坑,真不想這些小朋友再踩一次。但同時自己有懶得一個個去說工作要怎么入手blablabla(而且說了別人也沒法一口氣消化完)。于是就寫了關于設計師該有怎么樣的工作習慣這篇文章。在平臺潛水那么久,學了那么多前輩的經驗,終于可以自己分享點什么了~
一、設計師“看”什么
1. 原型
(1)需求完整性
需求是否設計完整不僅會決定設計師能否高效交付,還會延長開發周期。所以團隊里的人都有責任為需求的完整性負責。設計師在需求評審之前要認真看原型,理解業務。
一次需求評審通常包含一個或多個功能,要保證每個功能的流程(正向/逆向)、狀態、權限等都有清晰的說明。并要時刻保持全局思考,多維度的審查該功能操作時是否對其他模塊內容有聯動性,這樣的聯動對現在的頁面和交互是否有影響。
(2)需求合理性
一個完整的需求不一定是完美的。產品人員利用原型傳遞需求,但他們的原型通常并不是最優的信息呈現方式或者功能交互方式。設計師需要在完全理解業務需求后,站在用戶的角度思考最優方式。
2. 設計規范
(1)交互規范
作圖時布局要符合交互規范。交互設計應該遵守從大到小的原則進行,結構層—>框架層—>內容呈現。
- 首先需要清晰知道將要設計的目標頁面在整個項目結構里面屬于哪一層,例如外層列表/詳情頁/抽屜層等;
- 頁面布局要符合當前頁面層次的布局規范,例如模塊位置、標題位置、操作區位置等;
- 模塊內容呈現要符合交互規范里面的組件規范,優先選擇組件庫的組件或者項目積累的業務組件。
(2)UI規范
頁面表現層的細節應符合UI規范。看UI規范的時候除了要知道規范里面固定的值(比如字體大小有12px、14px、16px等),更重要的是要看這些值的使用場景(比如12px的字是備注型文案、14px是普通正文等),保持風格統一就是從這些視覺元素的統一開始的。
3. 競品
設計師要具備一定的競品分析意識和能力。競品分析可以讓設計師更了解行業同類產品在類似的業務場景的解決方案,從側面獲取行業背景和目標用戶的行為習慣等方面的參考。多看競品也可以開拓設計師的眼界,從交互和視覺上對認識標桿競品,能更客觀的看待自己的設計質量以及發現項目中存在的設計優化點。
特別是初級設計師,在接到任務后最好不要馬上動手??梢远嗫纯赐愋偷母偲罚磩e人對同樣的功能是怎么做交互和視覺的,這樣可以更直觀的去理解業務需求(剛入門通??葱枨蠖紩X得太抽象難理解)。
4.?產品核心數據
設計師應該重視自己輸出物的實際效果有沒有達到預期。最直觀的方法是看真實數據。一般在項目開始時PD除了會說本次產品目標,還會取相關數據期望值。如果PD沒有給出數據期望值的話,設計也應主動留意落地后數據的變化,一般可以看以下幾種數據:
- 用戶去留:頁面PV、UV;
- 用戶關注點:用戶使用路徑/關鍵頁PV、UV;
- 用戶轉化率:用戶流失步驟/頁面跳出量、流失原因(操作埋點)。
5. 科學的設計理論
設計理論是整個設計的靈魂及核心,凸顯你的整個設計作品是以什么理論作為基礎及支撐的依據。就像你如果覺得自己是作為一個具備獨立思考能力及判斷能力的社會人,那應該具備的三觀,這是你在整個社會上生活、工作、處事、待人、對物等等的原則及判斷基礎。
設計師應該是感性的+理性的,很多優秀的設計師都會把自己的工作經驗總結成方法論。缺少感性,設計師就會變成圖形的搬運工;缺少理性,設計師就很容易陷入“我認為我覺得”狀態。好的設計除了在視覺層打動人,還要有對應的設計理論做支持,才能讓更多的人讀懂設計師的勞動成果。
6. 流行設計
設計師看流行設計是最基礎的職業素養。如果一直不接收外界信息,人的思維方式會固化、思考能力會鈍化。設計師要保持自己靈感源源不斷必須要多看好的設計,潛移默化中吸取別人的優點,感受時代的設計潮流。這樣在我們進行設計時才不至于固步自封閉門造車,而且對待同樣的需求我們可以短時間內發散性的思考解決方案,提高工作效率和質量。
二、設計師“做”什么
1. 設計圖
無論是什么設計工作,都離不開設計圖。就像老話說的“字如其人”,當設計圖給到很多協作人員看和使用的時候,它就代表了設計師的為人性格和處事風格。如果不想協作人員對自己有不好的印象,設計師就要對設計圖有管理意識。
- 畫板、圖層命名是否讓人能看懂;有些設計師沒有命名習慣,設計圖里全是“未命名1、copy1”,就像天書一樣讓人無從閱讀,甚至有種想打人的沖動。
- 畫板排列是否有一定邏輯;就算畫板命名好了,排列方式和順序也是很重要的。不同模塊應該要明顯的分隔開,同樣頁面不同狀態應該盡量放在靠近的位置,方便別人查看。
2. 清晰的設計說明
無論設計圖做的多棒,交互多炫酷,沒有說明都是耍流氓。設計說明主要的服務對象是開發人員,他們實現一張設計圖的時間可能是我們的好幾倍,所以設計師應該多為他們著想,不要再讓開發擠出時間去猜你的設計怎么實現。
另一方面,要是設計說明不夠全面和清晰,會導致開發人員在多方評審時沒辦法準確判斷方案可行性,最終實現效果與設計不符。這時候開發可能會給三種態度——生無可戀但還是給你改、無語至極并表示沒時間以后再改、一臉正經地說做~不~了~
所以為了保持設計和開發的友好邦交,說明還是寫清楚點吧。
設計說明通常包括以下幾點:
- 操作方式:鼠標hover、點擊、滾動、拖動……
- 交互效果:頁面載入、出現、消失、跳轉到xxx、形變、變色……
- 動態描述:(建議使用動畫庫)各種位移、漸隱漸顯、動畫時長、延時……
- 適配方式:頁面寬度改變時,哪里固定寬高、哪里跟隨改變、有沒有最大最小值;滾動頁面時,誰固定、誰滾動。
- 數據展示:默認填充值、輸入內容類型、輸入極限……
- 錯誤提示:提示方式(彈窗、toast、氣泡……)、提示文案。
3. 設計規范
設計師除了要懂得看規范,還要懂得做規范,做一個詳細的設計規范有很多的意義 :
- 對于同一家公司的多個產品線來說,有一個統一UI規范,可以對多個產品在圖標、主題色彩等方面進行規范,使得產品統一;
- 多個UI設計師共同合作時,有一個既定的規則大家可以遵守,省得大家各做各的,做出來的東西不像一個產品;
- 有時UI規范也可以對研發和測試童鞋們的工作予以指導。
- 沒有一份設計規范能做到盡善盡美,遇到設計規范沒覆蓋的點,無論是規范的制定者還是執行者,都有義務去把它豐滿起來。
4. 嚴謹的設計評審
嚴謹的設計評審應該包括三個步驟:自審、內審、多方評審。
自審最能體現一個設計師是否對工作負責。工作過程中多少都有錯誤和缺漏,這些問題應該先在自己能力范圍內通過自查進行修補。設計圖拿出去就代表著自己,沒有人是專門為別人的錯漏買單。如果時間充足而不自審,是設計師工作態度問題;如果時間不充足導致沒時間自審,那要么是設計師時間管理出了問題,要么就是項目給予的設計時間不合理。
在內審和多方評審時,設計師應該對設計評審保持開放樂觀的心態。設計評審絕對不是為了吊打設計圖而存在的,設計評審上每個人都應該追求業務實現的最佳方式,客觀地站在自己擅長的位置上對設計圖提出建設性的建議。雖然評審時總有人會以非常主觀的思維說出模棱兩可的評價,例如不好看、不大氣、怪怪得……
這時候設計師應該放寬心態,耐心的引導他說出具體的問題所在,或者可以回歸到從產品目標推導設計方案的過程,讓大家在統一的頻道里對話。
5. 100%的設計還原
設計師要對落地效果負責。設計圖交給開發人員后,設計師還要對落地效果進行跟蹤和控制。在跟蹤階段,開發人員會因為種種原因對設計圖產生各種各樣的疑問或者需要設計師提供更多的資源,設計師需要盡量快速地響應,解答他們疑惑、給予可行范圍內的幫助,避免工期延長。在落地效果控制階段,設計師應該認真做好UI測試,把與設計圖不符的地方記錄清楚,并把UI bug按照嚴重程度區分。在有限的項目時間內讓開發修改嚴重影響的bug,其他的可以在協商修改時間后再修改。
三、設計師“想”什么
1. 提煉設計亮點
設計師提煉自己的設計亮點,不僅能時刻鞭策自己不要拿“路人設計圖”敷衍項目,還能提升自己對設計理論的實際理解,而且最重要的是讓項目決策者更透徹明白你的方案,提高過稿率。所以當設計師完成任務后找不到自己一絲絲的亮點,那就是出問題了,好好自審一下吧。
設計師可以從以下幾點提煉出亮點:
- 設計目標是怎么推導出來的;
- 設計目標在方案里是怎么體現;
- 優化前和優化后的對比,優化具有什么意義;
- 需求的復雜性及設計后的易用性;
- 為什么這個設計圖就這么美?。ㄒ曈X呈現用了什么方法、元素)
2. 挖掘產品體驗優化點
好的設計師對產品有owner意識,根據市場競爭、客戶使用等情況,產品需要穩定的持續迭代才能保持活力和競爭里,迭代過程中項目組每個人都有義務為產品的穩定成長出力。這時候設計師并不單純是一個接收指令的角色,設計師可以像產品一樣通過各種各樣的方法挖掘出產品的體驗優化點,進行記錄、分類、積累,在下一版本策劃時提出來給項目決策人評估要不要做。
3. 總結項目經驗
項目是設計師成長最快的途徑。不僅在做項目的過程中鍛煉設計師落地能力,項目結束后如果設計師能把經驗做適時的總結,這些經驗就能得到很好的升華,可以成為下次項目的養分。這樣設計師每次開始新的項目或者開啟下一階段的工作時都會信心滿滿,因為他知道自己之前什么做法是好的,可以繼續使用。什么做法是不好的,要避免踩坑。
當經驗積累到一定程度時,很多做法可以連接起來形成一套有效的工作流程,這時候設計師不僅具備自己承擔項目落地角色,還可以幫助其他設計師知道他們的落地工作。
4. 發現自己的不足
人無完人,設計產物也會反應出設計師各種各樣的缺點,比如:缺乏邏輯思考的人畫的圖就會有流程上的狀態缺失,沖動急性子的人設計圖上會有很多細節不完善等等。設計師要保持空杯心態,時刻發現自己不足之處,并予以改正。
本文由 @湯圓 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
請問動畫庫是什么?
https://daneden.github.io/animate.css/
像這種,設計師可以跟前端用動畫名稱來交流,省事很多
謝謝哦