如何提升設計的還原度?從這2方面入手!

0 評論 3173 瀏覽 10 收藏 13 分鐘

在日常工作中,設計還原度低是我們經常會遇到的問題,那么該如何解決這一問題呢?本文將結合相關實際案例,與大家分享相關內容,希望對你有所啟發。

設計還原度低是我們日常工作中經常遇到的問題。最近有同學就有這樣的問題:

有沒有什么工具或者具體的方法提升組內的設計還原度?組內前端同學經常無視設計稿上的細節,導致線上慘不忍睹,產品的體驗大打折扣,跟他說了也還是不改。有沒有什么制度或者流程,督促他們調動自覺性的方法?

這個問題其實是一個常見現象,當然了,設計的還原度只能盡可能的提高,沒有那種完全100%確保一致的方法,本文將結合實際的案例與大家進行分享~

01 關于設計還原度

對咱們設計師而言,保證設計還原度一直是我們工作的重中之重。

那我們一直糾結的還原度究竟是指什么?

「設計還原」指的是針對開發后的產品與原先設計的產品效果的偏差,進行交互以及視覺效果的比對。

為了保證設計質量得以保證,我們經常是在產品驗收環節的最后一步才進行設計走查。作為臨近上線才開始介入,最后導致因為時間不不夠,只能優化部分設計和功能上的問題。

設計還原度一直是團隊努力提升的工作,它本質上是一個合作的問題,即使再怎么克服,總會存在一些偏差。

  • 一是設計交接環節。設計師陷入了知識的陷阱,覺得前端能力很強,不需要做太多的標注。覺得他們可以跟自己一樣對像素敏感,完全可以做到設計稿的一比一還原;
  • 二是設計驗收環節。設計師工作職責定位有誤,覺得自己的主要工作是把稿子做好,至于后續稿子的還原是測試的責任,跟我們沒多大關系;

在這個競爭日趨激烈的互聯網環境下,用戶對于體驗的要求越來越高,這其中的設計還原度則是保證產品體驗的關鍵一環,確保產品的高品質在線。

02 設計交接環節

根據「特斯勒定律」我們得知“任何系統都有其固有的復雜性,這個復雜無法減少,我們唯一能做的是把復雜進行轉移”。既然設計的還原度是由前期交接環節以及后期設計驗收環節共同努力才提升的,如果我們設計在前期交接環節多花點時間,多站在前端的角度去思考,這樣在驗收環節我們會更加省力。

為了避免與他人因為交接而導致產品理解的斷層,我們有3個注意事項:

2.1 思維同頻(了解套路)

我們與前端同學的思維同頻特別重要,需要主動了解開發是根據哪些規則還原我們的設計稿,只有在實現方式上達成意識的統一,我們才能一起解決問題。

了解開發思維,首先就需要了解最基礎的「盒子」概念。

「盒子」概念是 CSS 語言的術語,講的是在頁面進行布局時,我們需要將頁面中所有的元素看成一個個的矩形的盒子。CSS 決定了這些盒子的大小、位置以及屬性。每個盒子由四個部分組成:

  1. content:內容區域,該區域可以定義 width 和 height。
  2. padding:內容區域和邊框之間的空間量。
  3. border:內容區域和內容邊距周圍的粗細和樣式。
  4. margin:邊框和元素邊緣的空間量。

當我們了解這個概念后就會有意識的在設計中帶入盒子思維,比如相同模塊保持各個元素間距、尺寸的統一,合理的規劃好每一個元素的布局。確保前端可以直接復用之前的樣式,避免在開發期間因為每一個元素的間距差異而提升精準還原的難度。

2.2 重視組件(避免挖坑)

在團隊人數較多時,多個前端參與同一項目的研發,每個前端針對同樣的模塊可能有著自己不同的編寫樣式,最終導致大量的代碼冗余,效率低且還原度無法得到保證。為了保證產品體驗的一致性,我們需要在交接中統一設計思維,使用組件進行約束。

2.2.1 總結通用組件

通用組件又稱為原子組件,是一種底層組件。比如:提示框、輸入框、開關、按鈕等。我們最耳熟能詳的通用組件網站就是 Ant Design 。借助通用組件,我們可以確保設計稿具備較高的一致性,提升設計與開發的協同效率;

2.2.2 封裝業務組件

為了更好的將組件服務于業務需求,解決業務問題,實現業務目標。我們需要將通用組件圍繞真實的業務場景進一步封裝,以便于后續快速迭代,比如:標題欄、表格高級篩選欄等。借助業務組件,設計師可以直接套用之前的組件樣式,稍作調整即可落地,省時省力。前端則可以解決跨項目復用問題,減少重復代碼和重復開發,在敏捷開發流程中保證代碼質量,確保設計的還原度;

2.3 設計宣講(同步內容)

設計過程更像是一個集思廣益的過程,這期間大家由一個抽象的需求變為具象的方案,背后肯定有著自己的獨特見解,這就需要我們在評審環節講述自己的設計理念,更需要借這次會議與開發同學對齊目標。

挑開天窗說亮話,在評審會期間有些細微的地方我們需要著重說明,把設計中視覺變化較大的地方講清楚,加深他們印象,幫助前端同學理解,同時前端同學也需要開誠布公的反饋當前實現的技術問題,避免帶著疑問工作。

宣講會期間的問題以及解決方案需要以會議記錄的形式記錄,并在會議結束后向項目組全部成員,以郵件的形式同步會議記錄(大家的共識),確保會議內容傳達到位。

03 設計驗收環節

設計驗收又稱設計走查、還原度驗證。當我們通過郵件或者群收到前端發送的驗收通知時,就可以開始設計的驗收工作了。

在設計驗收環節前我們得要求前端和測試同學先測一遍,確保設計還原度最大程度的保證,再介入設計的驗收。現實中很多前端同學一開發完立即要求我們進行走查,那時候我們會浪費大量的精力去找那些顯而易見的問題,重復工作會讓設計與測試的工作量顯著增大。

3.1 錯誤清單(講清問題)

驗收后我們需要注意問題的整理和存檔,最好使用公開且實時的在線工具進行整理,在錯誤清單中標明類目、講清問題、問題優先級、問題責任人以及一些特殊場景。

3.1.1 問題描述

為了更清楚的講明問題,需要提供線上具體位置的截圖和設計稿的截圖(標注出差異點),向前端同學清晰的講清楚當前存在的問題以及具體可以怎么調整。比如:真實尺寸多大,字號多少等。

3.1.2 問題責任人

講清責權范圍,這樣便于開發可以快速定位自己負責的業務模塊,也便于后續修改后的復查。

3.1.3 問題優先級

找出問題后一定要幫助前端同學標注出優先級,要不然他們會根據難度自己選擇,大概率選擇容易修改的問題調整,重要的問題反而擱置。在劃分優先級時可根據影響程度、出現頻率來進行評估,可分為三級。

  • 嚴重的可用性問題:嚴重的交互問題,每次操作該問題必定出現,會中斷用戶操作流程,必須立即解決;
  • 重要的可用性問題:出現頻率比較高,導致用戶產生困惑,需要花時間理解,對用戶體驗有一定影響;
  • 一般的可用性問題:不影響用戶流程體驗,存在頁面樣式方面(字體、色值、間距、對齊方式等)的問題。

3.1.4 特殊場景

完成主要流程走查后,我們需要注意特殊場景是否存在問題。例如數據異常、內容缺失、空狀態等。同時要考慮不同尺寸下產品的自適應問題,是否存在錯位、文案無法填充等情況。

這里值得注意的是,錯誤清單需要填寫兩次,第一次是前端開發完的首次走查,第二次是前端根據第一次錯誤清單修復后的再次復查,看看是否有新的問題。當問題解決后滿足上線的需求,則需要我們及時關閉錯誤清單中問題修復狀態,這意味著當前問題已經解決。

3.2 當面聯調(見面三分親)

走查不是為了發現問題,而是為了最終解決問題。當我們提交錯誤清單后,我們也需要時不時的與問題負責人當面溝通,一些跟進問題的修復進度。

面對面對接的效率是最高的,此時的前端面對一大堆錯誤清單可能滿腹怨言,雖然會按照問題優先級逐一解決,但是當快到上線前時間較緊時也會存留部分問題等到下次迭代時再解決。這時候如果我們多一些當面溝通的技巧,也會讓對方心情愉悅些,說不定也會稍微提升一些效率完成殘留問題的修復。

04 寫在最后

設計還原度的提升是大家共同努力的結果,如果我們在前期盡可能的換位思考、在規范下輸出設計、建立完善的驗收制度,才可以確保較高的設計還原度。

以上只是我針對提升設計還原度的個人感悟,希望該文章對你有所啟發,也歡迎感興趣的同學一起探討~

專欄作家

江鳥,微信公眾號:江鳥的設計生活,人人都是產品經理專欄作家。8年互聯網行業經驗,擅長體驗設計思維、設計方法論、交互設計研究。

本文原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Pixabay,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!