<address id="ttjl9"></address>

      <noframes id="ttjl9"><address id="ttjl9"><nobr id="ttjl9"></nobr></address>
      <form id="ttjl9"></form>
        <em id="ttjl9"><span id="ttjl9"></span></em>
        <address id="ttjl9"></address>

          <noframes id="ttjl9"><form id="ttjl9"></form>

          互聯網B端設計不可缺失的一項技能——視覺校驗

          2021-6-17    ui設計分享達人


          今天這篇文章,傳授我在工作中關于校驗的心得~





          01.  在工作中遇到的狀況

          不管是在大公司工作、還是小公司工作,設計師常常會遇到這樣的問題,在新產品發布之前,都會做一遍線上的ui視覺校驗,在這個過程中,前端開發工程師所寫的界面總會發生圖片變形,文字字號不對,元素與元素之間不對齊的事情發生。


          設計師給前端開發工程師標記了已經實現頁面中錯誤的地方,但是多數前端開發工程師一聽那么多頭都大了,在緊張的上線日期限制下更有甚者不予理睬直接上線,用戶吐槽設計不嚴謹,導致設計背鍋。

          為什么老板會覺得不好呢?其實是產品在用戶體驗的本能層次出現的不好的體驗。


          02.  好產品具備的特征

          全球的認知心理學家(美)諾曼在《情感化設計》這本書中講產品本能水平的設計——本能層;行為水平的設計——行為層;反思水平的設計——反思層。


          如果把產品做的做為產品一個目標的話,我們可以利用產品五要素把產品劃分5個層次,再用諾曼教授提出的感情感化設計的3個層次聯系起來,并把這些情感分為5個緯度進行考察就可以得到下面這張知識網絡圖。

          從上面這張圖我們可以看出用戶評判一個產品好壞的標準還是來自于產品的表現層、框架層、結構層中的直觀體驗也就本能層次和行為層次的感受,如果產品的吸引度、完成度、滿意度、忠誠度、推薦度的數據很高也就證明產品很好,如果數據表現不好那可以判斷產品還是有需要提升的地方。


          回到第一張圖片,老板覺得有問題的原因就在于產品在本能層次的不合格,那重點來了有什么設計方法可以避免本能層出現問題的情況嗎?我的答案是可以使用設計走查這個方法。


          03.  設計走查的意義

          一名專業的B端設計師,并不是說你把設計稿做的很完美,把標注和切圖完整的交給開發小哥哥之后就完事了,其實在這個階段設計只是完成設計工作中產出效果圖的工作,并沒有進行最后驗收的環節,如果開發還原出來的產品跟設計稿差距較大的話,設計其實也是要負很大責任的。


          就好比工廠的流水線中一臺電腦的生產,把電腦從工廠搬到運輸車上也算是電腦生產完畢,但是必須要送到客戶手里,客戶簽字確認,工廠才能算是電腦賣出去了,由此可見設計走查是保證用戶有高質量體驗的不可缺少的一個環節。


          我理解設計走查的意義在于3點:

          1、確保產品的設計細節的還原度合格,從而保證產品的視覺效果和交互體驗能滿足用戶需求。

          2、是設計師衡量設計師是否合格設計師的一項重要指標;

          3、通過細致入微的專業設計素質贏得公司團隊內部設計話語權的提升。


          既然設計走查這么重要為什么大家還會忽視呢?其實大家對設計走查的看法有一個誤區,如果你想成為一名專業的B端設計師,一定要改變以上的錯誤觀念,擺正一個正確的設計觀念。


          設計師在公司代表著視覺上的最高水準,設計稿則是設計師專業能力的體現,如果一個設計師的能力是100分,設計稿的分值90分,開發實現后的產品分值為50分,在沒有進行設計校驗的情況下,這時候將產品發布出去,用戶或者老板只知道該公司的產品設計只有50分,而不會知道背后設計師最高的水準是100分。


          慢慢的設計師就會在開發團隊中做設計變得很被動,越被動就會越沒有話語權,所以對一名專業的B端設計師來說,除了擁有很強大的效果圖設計能力之外,還需要有保證效果圖落地能力。




          01.  設計走查的種類

          設計走查是一種設計層面找尋問題的方法,多數應用在找尋產品問題或者是對項目開發過程中的測試環節。具體的方式我歸類為3種:


          1)體驗設計走查:是指人機交互之間的細節體驗、比如非力度測試、滿意度測試。可用性測試的調查這些方法都是體驗走查的一部分。

          2)交互設計走查:是指針對產品場景與場景之間的動態交互效果進行走查。

          3)視覺設計走查:是指前端開發出來的靜態頁跟設計師出得效果進行視覺細節的校對和檢查,確保開發出來的視覺和設計圖保持一致。


          02.  制作走查表的三種方法

          設很多人會納悶了,我們公司是沒有這種走差表的那怎么進行這三種設計走查呢?這里告訴大家我的一個工作辦法,總共分為3個階段“尋找·借鑒”——“思考·定制”——“優化·完善”。


          a.尋找·借鑒

          當大家有一個知識的概念如果想更深入了了解這個概念就需要在網上找一些關于這個概念的信息,這個過程就是尋找。如果大家沒有做過類似這種設計走查的經驗,那第一時間也是去尋找,尋找設計走差的概念甚至是做好了的走查表用過工作中,那有人會有疑問那不是抄襲嗎?我的回答“是的”,但是大家要想清楚一個問題,在工作中用最高效簡單的辦法是完成工作內容是最重要的。


          可能還會有人問,別的公司和我們公司做的行業不同,那別人公司的走差表我們公司能用嗎?我的回答是可以復用70%左右的,那剩下的30%就需要進入下一個步驟“思考·定制”階段了。


          b.思考·定制

          當我們完成第一步之后,就需要做自己所處的行業或者產品有一個認知,思考我們的用戶類型是什么,他們的使用場景是什么,他們最需要解決的需求是什么等等問題,然后在根據這些問題定制一系列體驗、交互、設計的問題,那就成為了自己產品定制的一份設計走查表了。


          c.優化·完善

          任何工作都需要持續迭代,為了變得更好的適合當前的工作。比如在第二階段定制的問題有些微交互動效果的問題前年是用戶比較在意的,現在很多產品都有了微交互動效了現在還問意義就沒有那么大了,我們的設計走查表也要根據互聯網的大環境不斷的進行優化和完善。



          03.  產品表現層——視覺校驗

          設計走查和設計校驗并沒有大的區分,但是我理解設計走查是一個比較新型的詞,設計走查的范圍要比設計校驗的范圍大一些。


          有些公司會把設計走查應用與改版之前當作找尋產品問題的一種方法,也有一些公司會把設計走查應用于項目做完開發在測試環節做測試的一種方法。比如在啟動產品改版前可以通過“視覺設計基礎自查表”來收集產品目前的視覺體驗問題;

          當項目處于即將上線在測試階段時候可以使用“視覺設計基礎自查表”來審查產品視覺實現層面是否合格,現在很多公司都用更簡單的“設計校驗問題記錄”表格來把視覺問題記錄。


          04.  視覺校驗需要審查那些緯度

          設計校驗驗收表可以簡單的理解為是用于審查產品表現層的“形狀、色彩、字體、構成、質感、動效這六點問題的記錄的表格。其實這六點也是諾曼教授提出的感情感化設計中本能層次和行為層次審查的六點。




          再講如何做之前,大家還是要先了解一下驗收流程中的步驟。


          01.  視覺校驗做什么

          這里描述兩點一個是開發階段、測試階段的流程。

          在公司的項目開發階段:是設計師設計完效果圖,進行標注(現在大家都是使用第三方標注軟件比如藍湖、摹刻、Sketch Measure 等),在交付開發。


          在項目測試階段:一般都是產品經理發起一個項目進入測試階段的通知把設計師、開發、測試、和產品經理都設置為參與者,之后由測試人員進行產品功能邏輯的測試、設計師進行視覺驗收;驗收完成后產品經理驗收測試結果,如有問題找開發進行修改;修改完畢再找測試、設計、產品進行確認,沒問題就封版了,產品經理確認發版日期,如果還有問題就再修改。


          02.  視覺校驗的驗收標準

          很多剛入行的設計新手,在校驗階段不知道那些緯度的視覺差別,以至于很多視覺元素都需要查看,對于c端誰是來說界面的場景因為交互比較簡單還能應付,


          但是對于模塊功能復雜、交互場景眾多的B端ui設計來說每個場景都要查看很耗費精力工作效率也不高。


          所以我總結以下幾個高頻出現問題的點供大家參考,大家可以按照以下幾個緯度進行視覺走查,提高自己在工作中的效率。


          a.檢查設計稿的可行性

          人無完人,再專業的設計師,也不可能100%保證自己的設計方案就是最好的設計方案,在交付設計稿前期設計師應該自我檢查自己的設計稿是否能清晰的傳遞信息,對于一些重要的模塊是否能凸顯出來,對于一些比較復雜的交互場景開發是否能夠實現,市場上眾多的屏幕尺寸,這樣的布局方式是否是最為合理的等這些緯度進行思考做設計,保證設計方案的可行性。

          這里我舉一個我真實的案例,起初我接到的需求就是設計一個模塊里面信息排版,如果我采用我直接采用第一個方案那肯定是不行,因為信息層級區分不夠明顯,所以第二個方案把數字標簽用顏色進行了區分,但是我又想如果出現文案比較多的場景,對齊方式都是左對齊那“指標值”的細心就不可能保持左對齊,所以我又出了第四個方案,目前來看第四種方案可是適應多種場景,算是最佳方案。


          假設當時我就交付前端開發第一種方案,上線后出現問題,還需要調整到第四種方案,慢慢的前端開發就會質疑設計的專業能力,后續合作也會難以推進了。


          b.組件調用是否正確

          B端產品的業務復雜、,模塊交叉設計數量多,所以在設計b端產品初級都是用原子化的思維搭建一個組件庫,前端是開發階段在樣式庫中寫一個標準的控件樣式,然后在不同的頁面場景中調用公共樣式,原理類似于我們在 Sketch 中搭建 Symbol。我們要從兩個方面看組件是否調用正確。


          1)公共組件是否正確

          公共組件調用正確,好處就是公產品的整體視覺風格是一致的,比如頁面的側邊導航,搜索場景、詳情頁場景布局是否一致,在斷網或者報錯的場景中出現提醒條樣式是否一致??蛇M行交互的按鈕樣式出現的交互狀態的按鈕是否一致等等。


          2)業務組件是否正確

          在真實開發場景中,有一些前端開發在雖然調用一個樣式,但是在設計規范中一個樣式可能會有多個尺寸,比如這個按鈕,在開發階段避免不了出現樣式雖然是對的,但是尺寸調用錯誤的情況出現,所以要查看一下組件的樣式和尺寸前端開發是否調用正確。

          按照這個思路去設計最為重要的就是要檢查開發人員調用的組件庫的規格是否是我們設計稿的規格,以此類推去整體的布局、按鈕樣式,報錯樣式。


          這里需要描述的內容相對較多,以后有機會我可以再補充一份關于《如何搭B端建組件庫》的文章,咱們詳細聊一聊。


          c.空間關系是否一致

          空間關系可以簡單的理解為模塊與模塊之間的“間距”關系和組件與組件之間“間距”的關系。


          1)模塊與模塊之間——間距

          所有模塊(卡片)之間的間距,這里具體指的頁面布局包括橫向間距和縱向間距,大家可以采用4px(或者8px)的倍數進行刪格布局,把刪格布局的基礎規范梳理出來,以這個規范當作標注來審查橫向間距和縱向間距。


          2)組件與組件之間——間距

          另外一點就是我們在搭建組件階段,組件與組件之間的間距關系是否一致,不要出現不對齊的情況出現。


          3)為什么要用統一間距

          大家了解空間關系都看那些緯度后,我們再來解答一下大家的心中的疑惑??傉f要間距要保持一致,但是為什么要保持一致呢?主要原因有以下三點:


          對于如何使用間距,我建議大家可以看一看《寫給大家看的設計書》里面關于版式設計四大原則的講解和有關格式塔原理的文章。



          d.文案的顯示是否清晰

          在ui設計中,我們總避免不了與字體打交道,字體也經常是我們在設計中容易忽視的部分,影響字體的清晰度無非是字體、字號,字重,段間距這幾個參數的設計。


          1)字體

          字體的實現其實是電腦渲染的一個過程,mac電腦默認字體是蘋方,wids電腦默認字體是微軟雅黑。在字體的選擇里面行業里是有標準的規范的,比如ont-family:serif、sans-serif、monospace、cursive和fantasy這無種字體,前端在編寫代碼時候會把這種多個字體名稱保存為“字體的回退機制”來定義,意思就是如果展示的設備(瀏覽器)檢索是沒有第一款字體就依次順延使用下一款字體,這個大家只需要了解就好,在字體選擇中使用頻次最多的還是對數字字體的選擇。


          對于數字的字體設計要提前查看是否字體有版權。這里分享一個可以免費查詢字體的網站:https://fonts.safe.#/?from=bd

          不同的網站對字體排序的方式可能不一樣,有興趣的小伙伴可以用下面這個的方法進行查看。


          2)字號/行高

          對字體的字號也要進行走查,因為在開發階段在不同的瀏覽器種顯示的字號會有變形的情況出現。


          另外考慮各個瀏覽器的兼容問題,pc端建議使用最好的字號是12pt,因為12pt可以保證在現在市面上的瀏覽器種是可以清晰顯示的,如果有特殊場景需要用到12pt以下的字號,需要和開發說明并且標注出來。


          3)字重

          設計區分文案層級的場景使用頻率最高、視覺效果最好的設計方法就是給字體加粗的字體樣式了。


          這里要注意的是初級設計師的眼力可能還沒有達到很高的水平,尤其是最小的字體顯示加粗或者不加粗的效果視覺在電腦那么大的屏幕上感官并不是很明顯,所以最好可以通過從代碼的層面進行核對,具體方式可以看圖:



          e.顏色的選擇是否科學

          產品是給用戶呈現面積最大的一個元素對用戶來說感官層也是表現最為明顯的一個元素,所以在校驗中“顏色”是最容易造成落地頁面與設計稿視覺差異的一個因素。


          1)色差

          因為大家屏幕的技術一般是LG屏幕(屏幕的使用時間越長色彩的還原度越低)。


          雖然有的時候在查看代碼時候色值是正確的,但是也要根據具體的場景進行分析,這里建議大家不要使用具有不透明度的色值(雖然在c端中經常會使用,有不透明度會使顏色比較透亮但是在B端產品中定位是工具,工具就要以效率在第一位,美觀在第二位,所以這個場景的顏色使用盡量以清晰展示為第一準則。


          2)顏色種類

          b端產品中,柱狀圖、折線圖的樣式比較多,在設計這類圖標時候盡量避免多種顏色的出現,還是因為B端產品定位的原因,太多的顏色設計勢必會干擾用戶進行判斷。



          g.圖標的尺寸是否合理

          不管是在C端產品還是B端產品中圖標的也是高頻出現的一個元素,圖標本身的意思就是簡化文字信息,通過圖形去高效的傳達一個固定的文案信息。


          對于圖標的設計走查大致分為兩點:


          1)大小

          我們在設計icon圖標時候,會根據不同的場景進行圖標尺寸的規范輸出,但是在真實的開發環境當中,開發在使用我們提供的插件(藍湖)進行icon下載時候,會提供3種icon的尺寸下載,前端開發在使用切圖時候往往會忽視掉圖標的尺寸問題,對于圖標的設計走查,是否圖標使用的尺寸是我們設計使用的規范,所以第一個就要看大小是否能清晰的展示。


          2)svg格式開發

          因為pc電腦的屏幕尺寸、分辨率往往是高于移動端的屏幕尺寸、分辨率,圖標的切片做的太小上傳到屏幕上會出現模糊的展示效果,如果圖標不能清晰的展示圖標所呈現的圖形,那就會造成用戶一定的識別障礙,所以一定要保證圖標不要有模糊的情況出現,盡量使用svg格式圖標切片給到開發。



          設計校驗工作不能說難,但是有耐心有細心的設計師都可以完成的,一遍視覺校驗需要1——2天的時間,相對來時比較耗費大家的精力。


          換個角度思考,如果我們從項目開發的前期就控制設計走查的工作量,那我們可能會減少了走查的工作量。接下來我們就聊一聊怎么減少設計校驗的工作量。


          01.  了解需要視覺校驗的原因

          前面我們一直講的是做視覺校驗需要校驗的維度,我相信更多的設計師還是希望把精力放在做設計效果圖階段,畢竟如何做只能單純的提高我們的校驗的效率,想要在開發過程中減少對項目的設計校驗的工作,


          我們需要清楚兩個答案,一個是“在開發過程中為啥需要設計走查”和“開發不愿意修改的原因”。


          a.誰負責實現樣式

          開篇我已經講了設計走查的意義(原因),為啥要做視覺校驗其實和設計走查的原因差不多,但是我想從開發流程再聊一聊。在一個產品開發中設計師下游需要對接人的人員角色統稱為開發工程師。


          但是在這類角色中其實也是會細分為三種角色:前端工程師、后段工程師、測試工程師。而前端工程師是我們主要對接工作內容的對象。

          因為做項目多數情況是多人寫作共同完成的工作可以從上面圖片可以看出,前端工程師是實現我們效果圖樣式的主要人員。


          b.前端工程師心里所想

          前端工程師的工作內容需要一一查看設計師提供的標注,然后再一一去實現,所以難免不了心里會這樣所想:好麻煩,如不我自己按照感覺寫。


          在真實的工作中,前端開發按照規范進行項目開發這種思路是對的,但是設計師強硬的要求前端開發工程師,按照規范進行開發是過于“理想化”的一種表現。


          所以我們還是要先從自身出發,循循漸進的要求前端工程師按照我們的設計規范進行開發,這就來到我們下一個話題。


          02.  如何避免呢

          那么接下來我們來聊一聊身為設計師我們要怎么做,才能避免進入過多的設計校驗呢。


          a.了解開發實現原理

          如果想成為一個高端進階的設計師,我們要給自己增加籌碼,那最為直接增加籌碼的方式就是——站在開發者的視野看待問題,了解開發思維。


          國內前端寫樣式的代碼基本上是HTML+css,jacascript,注意這不算是編程,只是一個寫樣式的語言,簡單的理解就是盒子模型(css語言)


          1)盒子模型

          CSS盒子模型 又稱框模型 (Box Model) ,包含了元素內容(content)、內邊距(padding)、邊框(border)、外邊距(margin)幾個要素。如圖:

          舉一個圖文模塊的例子:圖(1)是設計師輸出的設計稿, 圖(2)是開發需要的標注信息(我們實際給到開發的標注)開發需要的查看的就是色塊的尺寸和色塊之間的間距。



          2)用框架化思維做設計稿

          了解完前端制作咱們效果圖的原理后,我們就要用這個盒子模型的概念,像是搭建房子的原理去制作效果圖,所有的組件之間都是有理有據的,那這個專業術語就叫做框架化ui。


          前端開發工程師通過一個個盒子填充來將我們的組件元素放入其中,最終形成前端展示的頁面。

          注意:標準的額框架化就像前面的盒子模型是一塊一塊制作的,考慮到開發同學開發階段組件的嵌套邏輯。


          3)開發者模式

          如果還是不太了解盒子模型具體是什么的同學可以在線上使用下圖的方法自己去查看。


          設計師在視覺校驗時使用瀏覽器就可以看到開發寫的盒子,了解盒子也可以方便我們走查時知道問題在哪。具體操作步驟:



          b.檢查自己的設計稿

          在給前端開發工程師的提供設計標注階段需要提前保證自己出的效果圖是有效的設計方案,符合基礎的視覺需求,都能保證模塊設計的可擴展性及規范化,避免定稿后在反復修改設計方案。


          比如;當我們設計產品中的搜索條件模塊時候,我們需要考慮在一行展示3個搜索條件,一行展示4個搜索條件或者一行展示6個搜索條件并且放不下的情況下,那效果的展示樣式都是應該是什么樣式的這列問題。

          再比如,我們設計完一個場景的設計稿之后,還要考慮不同屏幕尺寸下這套效果圖的布局是否能滿足產品需求,如果不滿足在那設計稿需要調整成什么樣式的設計稿。



          03.  做好標注文檔

          除了確保設計稿的可行性之外,還要做好設計稿的標準文檔。如果項目是小版本的迭代就只需要進行簡單的描述即可,如果是組件庫的升級,那就需要 給前端工程師的標注文檔,盡量是詳細的、準確的。


          包括設計稿、切圖(規范的切圖命名、壓縮好的圖片文件)標注、設計規范已級交互文檔(包含標字體標注)。


          a.描述到什么程度

          那細致描述到什么程度呢?這里我簡單的說幾個點,比如:
          ·側邊導航欄在正常模式下、縮緊模式下,導航欄的寬度是如何變化的,
          ·如有有圖片信息的上傳,是什么圖片比例是什么,是21:9‘16:9,4:3.1:1?
          ·如果出現文案超長的信息場景,不可展示的文案信息是什么樣子展示,是文案后面是省略號展示?還是鼠標滑上去有氣泡彈窗的展示樣式。


          b.圖標命名的規范

          隨著業務增多,團隊內對圖標的隨意命名的習慣也開始凸顯出弊端,這種不好的習慣會造成同一類功能的圖標會出現不同樣式尺寸,所以我們在搭建圖標規范時候,就可以把切片的命名規范好。


          在圖標規范中,圖標需要有著單獨的后綴,這樣可以讓公用圖標與業務圖標更方便的溯源。值得注意的是我svg格式的圖標可以不用寫切片的尺寸,而png的圖標我建議寫上切片的尺寸。

          有些公司習慣于去icon進行英文的格式命名,左側是我整理的比較高平使用的命名,文章末尾我會分享出來文字格式,供大家使用。


          c.圖標的上傳

          可以在開發前在與前端開發溝通達成共識、圖標制作完成確認后,將圖標上傳到阿里巴巴圖標庫中,更方便前端調用圖標大小和調整顏色。


          如果開發需要自己去找到相關圖標,也可以給予權限讓開發從藍湖上傳圖標(前提是得整理好圖標到藍湖上)。




          04.  和前端開發工程師的溝通

          在雖然很多時候項目的到發版本時間、驗收標準團隊內部都是由明確的規劃和標準,但是有些問題還需要特別分析、特別對待:這里我就列舉幾點我在項目由幾個比較重要的點。


          a.進行設計宣講

          設計宣講最大的意義就是加深他們的印象,提前大家心里都有一個預估,把一些規范標準類的問題暴露出來,把關鍵核心點,規則講清楚,為了后面減輕設計走查的工作量,開發也輕松一些。


          1)用認知對齊,目標一致

          如果團隊內部四個角色成員大家的認知都是一致的——提升用戶體驗是我們公共目標。


          如果不一致,那就要說服其中一個角色,最好是項目負責人,說明校驗影響發版時間,如果大家都按照規范去完成自己工作內容,可提高效率。確保大家理解一致:設計師要和開發、測試確認視覺表現層的驗收內容、確保內容大家理解一致。


          2)做有效的溝通

          認真是前提、尊重是法寶。


          在部分開發團隊中,設計師的也不能太過于教條的對待自己的設計標準,畢竟開發生氣請假不修改了,那就真的沒有人可以進行代碼的修改了,設計效果更是顯示不了了在開發之前,就要和開發溝通,目前這些界面的效果在技術層面上是否能實現,針對比較復雜的界面場景,實現出來的代價有多少,權和利弊后在確定是否按照效果圖進行開發。


          針對復雜的頁面需要把標注標記的更加詳細,并且明確告知他們,我的刪格在哪里說明,布局規范在哪里說明,在這個交涉過程中設計師就需要尊重他人工作成果,明確自己的需要做的事情,把問題描述清楚就好,不可要求開發同學100%還原設計稿、過多的干預別的開發團隊的開發步驟和內容。


          3)不必焦慮

          前端開發工程師找我們溝通他們的疑問點時候我們要積極回應他們,并且和他們一起處理問題,比如某些復雜的頁面,避免不了實現效果圖不好的情況出現,這時候不要一口咬定就是開發的原因,先溝通具體原因,然后找出解決辦法。


          不必焦慮、遺留問題下一版再解決:開發人員在修改的代碼的階段,開發人員的效率是有限的,而且大家都是身兼多條業務線,在這種開發的場景中可以在不影響正常發版日期的階段,把不太重要的視覺問題,放到下一個版本中在進行修改。


          4)規劃時間節點

          而且在工作項目中也要注意分配自己的精力,我建議用對需求等級進行劃分。

          把問題的界面自己標記優先級,定期(每天定時)跟程序員溝通,跟他一起制定解決方案和時間。如果時間允許可以慢一點修改,只要改對了就可以,畢竟完成比完美更加重要。



          對于設計校驗的工具就一個原則:你開心就好,工具的最大作用就是提升工作效率,只要你覺得能提升你工作效率,你喜歡用啥就用啥。


          如果還在迷茫用什么工具進行設計校驗的同學,我把我使用的工具主要分類兩類工具,第一類是發現開發問題和效果圖的不符合的工具;第二類是針對如果高效記錄、追蹤問題的工具。重要目的就是提高設計師在設計走查中的工作效率。


          01.  4款發現問題的工具

          我在工作中發現很多時候開發不愿意檢查自己代碼樣式的一個原因就是不知道以下四種工具,在很多公司里面前端開發工程師都是多條業務線并行開發的局面,沒有更多的工作時間自己做設計審查,覺得又繁瑣又麻煩,


          這是時候我們可以提供工具給予開發,幫助他們提高工作效率。設計師同學也可以借助以下4款工具進行校驗:

          前三款都是Google Chrome瀏覽器的具體操作步驟可以看下面的圖片,如果還有不懂的地方可以在評論區給我留言,我看到后會為大家一一解答。


          至于“他山石”這款軟件大家有興趣的話可以在晚上直接打名稱就會出來軟件信息。


          02.  記錄追蹤問題的工具

          介紹完發現問題的工具后,咱們再聊一聊記錄追蹤問題的工具,有的人會問了,你前面講了視覺校驗都要看哪里,有推薦了視覺校驗的工具來發現問題,我直接把需要修改的地方告訴前端開發工程師不就可以了嗎?為什么還要知道這個記錄追蹤問題的工具呢?


          a.進為什么要使用記錄追蹤問題的工具

          在一些設計團隊稍微成熟的公司里面由于項目的規模比較大,涉獵的模塊多,參與的人員相對也多。


          面對這種體量的項目如果不進行問題的記錄的話,這周做項目里面的1號模塊,下周做項目里面的2號模塊,大下周要對項目里面的1號模塊進行修改,然后自己就會發現1號模塊當初的修改問題是什么忘記了,更有甚者都忘記一起協同工作前端開發工程師的名字了。


          這時“記錄追蹤問題的工具”就顯的尤其重要了,因為這種工具的出現可以幫助我們回憶起當初具體的修改問題和修改的進度,從而降低上線安全性的風險度。



          b.TO DO LIST 思維模式

          to do list是一種實際走查階段使用的一種走查模式。


          在設計走查階段,主要由設計師發現問題、記錄匯總遞交到前端工程師這里進行修改和跟進,主要的優勢是在于協助走查可以順利的開展,不遺漏掉任何信息。


          在輸出的表格比較注重3點,問題需要逐條記錄、需要截問題圖片及描述修改正確內容、相關對接人員的名稱和處理進度。

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          文章來源:站酷   作者:斜杠7濕兄

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務



          日歷

          鏈接

          個人資料

          藍藍設計的小編 http://www.syprn.cn

          存檔

          亚洲va欧美va天堂v国产综合