對接開發(fā)的重要性
作為產(chǎn)品設計師，無論在什么公司什么崗位，都免不了與研發(fā)團隊進行溝通，如果不進行溝通就無法交付我們的設計稿，即便很成熟的團隊也會出現(xiàn)在溝通上的問題，在產(chǎn)品研發(fā)的過程中溝通是必要的流程，為了創(chuàng)造一致的用戶體驗，設計師需要與開發(fā)人員在視覺上、交互上達到一致的想法，但是講起來簡單，說起來難，在整個過程設計師和開發(fā)都是站在不同的角度去看待問題的，我們思考的如何達到美觀的界面、流暢的交互等問題，而開發(fā)關心的是做這件事我需要花費多長時間，實現(xiàn)難度如何等等，首先目標就不在同一個維度，那么必然會造成我們在對接的時候出現(xiàn)掰扯的問題，最后耽誤的都是雙方的時間，更嚴重點頁面最后的體驗也沒有達到一致。
任何團隊都會出現(xiàn)設計師與開發(fā)脫節(jié)的問題很常見，遇見什么問題解決什么問題，畢竟人與人的性格、溝通方式等都是不同的。
我們只需要在不同的流程里去做不同的事情就可以避免這些問題了，對于任何設計師基本都會適用，往下看～
1. 產(chǎn)品信息文檔確認
在接到一個需求的時候產(chǎn)品經(jīng)理會通知上下游進行需求的評審，這時候一般會是產(chǎn)品經(jīng)理、設計師、開發(fā)三個組進行需求的評估，具體的需求評審在本章就不細講，我們此次主要講設計師與開發(fā)相關的信息同步。
在評審過程中產(chǎn)品經(jīng)理會把需求背景、需求目標等相關信息同步給相關的人員，作為設計師這時候就要關注需求目標，這個目標不僅是產(chǎn)品經(jīng)理的目標，也是整個項目的目標，所以與每個人都相關，需求目標清晰后期推動開發(fā)的時候才會有依據(jù)。
評審會議結束后，產(chǎn)品經(jīng)理會同步期望上線時間，如果是常規(guī)需求，會當時就評估出設計時間、開發(fā)時時間，我們設計師這時候就要關注這些時間，因為我們通過上線時間就可以估算開發(fā)節(jié)奏，給我們后期的修改以及臨時添加的一些動效制作時間會留出充裕的時間。
設計評審流程細節(jié)本章不進行細節(jié)講解，本章重點講與開發(fā)對接。
近期我在公司做了一個商業(yè)化的直播項目需求，由于產(chǎn)品方?jīng)]有過多的產(chǎn)研經(jīng)驗（后面才知道），在項目前期雖然進行了評審，但是評審的參與人員沒有拉上我，等到需求給到我的時候，我順便問了一下才知道已經(jīng)評審完了，這對于我來講是沒辦法進行設計輸出的。
第一我不知道評審過程中開發(fā)的排期時間，以及測試時間，如果研發(fā)開始開發(fā)的時間與設計稿交付時間有沖突那么就是影響上線節(jié)奏。
第二涉及的交互操作產(chǎn)品經(jīng)理是不清楚的，有沒有哪些地方需要加復雜的交互產(chǎn)品也是同樣不清楚，那么開發(fā)就會默認這是常規(guī)的交互，如果過程中添加那將會影響開發(fā)進度。
第三流程上不符合要求，期間如果有關鍵性信息沒有達到共識，那將會釀成很嚴重的后果。
面對這種已經(jīng)發(fā)生的事情，如果重新拉個會評審一次會耽誤大家的時間，很多人是不愿意的，但是呢我也不能單聽產(chǎn)品一方面的溝通，因為很多細節(jié)他是不清楚的（產(chǎn)品經(jīng)驗較少），所以當時我的處理方法呢是我先通過產(chǎn)品給出的上線時間，然后與前端同學單獨確認一下，這樣至少保證上線時間是同步的，至于其他的細節(jié)我當時是利用設計評審的方式同步給開發(fā)交互邏輯、動效方式等。
此次這個需求呢本身不大是在舊版的基礎上優(yōu)化功能，理論上不需要走設計評審流程，但是因為當時沒有通知參加評審導致很多信息不同步，而我需要傳達給開發(fā)的東西也不能在后期在告訴他們，所以我利用設計評審流程把一些交互信息同步給開發(fā)。
2. 設計圖準備
在設計稿完成后，如果是小需求一般是直接交付給研發(fā)，如果是大需求一般會進行設計評審，主要評審維度是設計稿是否與產(chǎn)品文檔同步，設計目標是否符合產(chǎn)品目標等等，其次如果有復雜交互效果、設計細節(jié)、組件復用情況也需要與研發(fā)對齊。
若是直接交付研發(fā)，我們需要提前把設計稿內涉及的切圖、圖層間距、動效使用區(qū)域等關鍵信息提前準備好，避免在開發(fā)過程中臨時進行補充，影響開發(fā)節(jié)奏。
在設計稿內的切圖，我們要提前與研發(fā)溝通，切圖的范圍和形式，最后把設計稿傳入公司統(tǒng)一使用的協(xié)作網(wǎng)站，如藍湖、即時設計等平臺，大公司會有自己的協(xié)作平臺。
3. 確定設計規(guī)范組件
講個自己的踩坑案例，還是商業(yè)化的那個需求，由于為了商業(yè)化賦能，產(chǎn)品的需求文檔并沒有按照規(guī)范組件進行設計，但是由于產(chǎn)品文檔標注的不清楚，在設計過程中不斷與產(chǎn)品進行溝通，最后結果當然也是無法復用組件，當時我就把組件規(guī)范修改了，重點是研發(fā)不知道，我當時想的是研發(fā)通過產(chǎn)品文檔應該會了解到，事實確實我大意了，后面就導致組件方面我與研發(fā)進行了相愛相殺，通過自己的以身作則我勸大家不要忽略任何一個細節(jié)！
設計規(guī)范組件在設計前就需要進行確認，項目是否有存留的規(guī)范組件，如果有，需要在設計前以及設計中去確認哪些模塊是否可以調用，開發(fā)是否已經(jīng)將組件寫入代碼中，如果不了解這些情況貿(mào)然的設計，那在對接過程中會出現(xiàn)修改設計稿的風險。
如果是創(chuàng)新項目并且沒有相關的設計規(guī)范和組件，我們則需要在設計前就把規(guī)范組件的時間給算到需求內，一個產(chǎn)品的規(guī)范組件，決定著后續(xù)產(chǎn)品是否嚴謹、項目研發(fā)效率等等，因為規(guī)范組件不止是設計師的事情，還是團隊研發(fā)比較關注的事情，研發(fā)們在代碼里同樣需要進行規(guī)范的組件復用。
4. 輸出設計文檔
當在做一些在舊版的產(chǎn)品頁面上優(yōu)化的需求時，還需要輸出對應設計文檔，給前端和測試看，設計文檔需要寫清楚設計稿優(yōu)化的點，例如圖標的細節(jié)優(yōu)化、文字的字號優(yōu)化、色彩優(yōu)化、界面交互等等細節(jié)。
如果涉及到一些頁面的交互，我們在提供設計稿的同時需要把具象的交互文件單獨交給開發(fā)，不要奢望前端大佬們能腦補出頁面之間的交互，我們不及時提供的話，后期修改研發(fā)可能會直接拒絕，并且口吐芬芳～（最簡單的找到競品頁面演示給研發(fā)看）。
我的方法
前端在看我們設計稿時如果不是結構上的修改，他們不會去關注這些細節(jié)的點，而給測試看的目的是，有些公司測試會幫我們進行走查，如果不出設計文檔測試沒辦法進行對比（測試提 bug 比設計師提 bug 更具有一些權威性）。
這里看一下我工作中輸出的設計文檔，我會把需求的背景、目標在設計文檔上強調一下，再添加上設計目標，設計目標為了需求目標去賦能，這樣在文檔開始就與研發(fā)達成共識，讓研發(fā)是帶著共同完成目標的態(tài)度去看設計文檔，便于我們后續(xù)推動，其次放上頁面之間的說明。
5. 交付開發(fā)
最后總結一下，我們要交付給開發(fā)什么東西，首先是基本的設計稿，包括切圖、間距、動效文件，其次是設計文檔，包括需求背景、需求目標、設計目標、設計修改點說明。
1. 不要頻繁修改
在交付設計稿后（基本設計圖、設計文檔），我們就要避免頻繁修改，頻繁的修改會導致設計稿來回更新，對開發(fā)造成一種困惑，最后在測試的時候，開發(fā)同學容易寫亂，另一方面工作過的設計師都應該經(jīng)歷過，我們在開發(fā)的過程中修改設計稿，大部分的開發(fā)都會帶點情緒，甚至不給我們改，這其實是因為大多開發(fā)的代碼寫的是比較規(guī)范統(tǒng)一的，如果中途進行修改可能會影響開發(fā)同學的代碼規(guī)范，就像我們在完成一個設計稿的時候，產(chǎn)品經(jīng)理突然改變需求，我們也是擔心做好的設計稿因為修改而被打亂。
如果實在需要修改，一定要說明原因，而不是突然一個想法覺得這里設計不合適就進行修改（產(chǎn)品需求修改除外），我們要換位思考，具有同理心去工作，并且讓開發(fā)同學感受到我們是在幫助他們減少工作量，這樣在后續(xù)的一些需求中，我們的對接會很順暢。
2. 重要信息及時通知
上面說的是站在設計師的角度去修改，還有一種情況是研發(fā)在開發(fā)過程中，作為設計師的我們突然收到產(chǎn)品經(jīng)理的修改建議，這時候我們需要及時的同步給開發(fā)，或者給開發(fā)同事達成共識信息，因為很多時候，產(chǎn)品經(jīng)理讓我們修改的時候往往不會通知開發(fā)，因為對于產(chǎn)品經(jīng)理而言就是一個小的修改，例如改個位置、改個顏色等等，但不管是對我們還是對于開發(fā)其實都是比較重要的，不及時同步就會出現(xiàn)不好的結果，如果在測試階段沒有發(fā)現(xiàn)問題，上線后就會造成設計師背鍋的情況。
我曾經(jīng)在做一個頁面改版的時候，就遇到類似的問題，當時產(chǎn)品找到我說改一個地方的交互，并且我也覺得那個交互方式應該改，當時的我以為產(chǎn)品經(jīng)理會同時告訴開發(fā)修改的地方，但是直到項目上線后開發(fā)都沒修改那個地方的交互，本來這個修改點是個小事情，誰知剛好那一個版本被用戶吐槽那個頁面的交互，結果可想而知領導拉個會議開始復盤，為什么沒有改，索性大家沒有互相甩鍋的情況，產(chǎn)品經(jīng)理說沒有同步到開發(fā)，而我也是幫產(chǎn)品兜了一下說更新設計稿沒有告訴開發(fā)，這個事情原本是個很小的事情，只需要我順口同步給開發(fā)，就能夠避免的，就因為我沒有及時同步，造成用戶的反饋，影響了產(chǎn)品的體驗。
所以各位設計師工作中如果遇到類似的事情一定要及時同步！
3. 統(tǒng)一需求目標
開始講到過，在需求評審的時候要與開發(fā)對齊目標，為什么需要對齊目標，因為一個項目如果目標不對齊，那么每個人都會站在自己的角度去做這個需求，設計師思考的是通過設計的手段，去幫助產(chǎn)品完成目標，如果設計稿上的復雜效果較多的時候，開發(fā)則會考慮你為什么這么做，這么做開發(fā)成本非常高等等，這也是說為什么我們開始就講要輸出設計文檔，如果這一切都不存在的話就會導致開發(fā)是帶著疑問寫我們的頁面，如果過程中在修改需求什么的，那我們跟開發(fā)又要相愛相殺了。
我的設計方式是通常是在產(chǎn)品評審階段就與開發(fā)明確講清楚，我大概要做什么樣的效果，什么的交互形式，預計什么時候會交初步方案，中途也可能會有修改的點等等，提前讓開發(fā)有個心理預期，避免在開發(fā)過程中產(chǎn)生抵抗情緒。
我的經(jīng)驗
4. 輸出交互動畫
如果在前期沒有時間進行動效設計并沒有關系，研發(fā)在開發(fā)過程中可以在把動效方面給空出來后續(xù)寫，這里講的交互動畫分為兩種，一種是展示的動畫，一種是 ui 中的動效。
展示動畫
目的是為了告知開發(fā)頁面運動的軌跡，在 1-4 中講到我個人用的方法，大家如果是剛對接研發(fā)的話，建議還是輸出完整的交互動畫，這里推薦一些工具 AE、Principle、Pixso、Figma 等。
AE：大家就比較熟悉了，經(jīng)典的動效繪制軟件，什么樣的效果都能實現(xiàn)，但是使用成本比較高（不建議）
Principle：國外的一款交互軟件，制作頁面交互很方面，可以直接導入 figma 和 sketch，由于是國外軟件需要使用英文界面，但是國內也有漢化版。
Pixso：國產(chǎn)最新的設計軟件與 figma 類似，做交互的方式是使用多個頁面添加熱區(qū)進行使用，具體體驗如何還不清楚（可以用用）
Figma：設計軟件目前的天花板，流暢的體驗，支持頁面動畫設計，但是需要安裝插件才可以（建議使用）
動效文件
這個比較重要！我們一定要與研發(fā)同事溝通好，產(chǎn)品內使用什么樣格式的動效文件，統(tǒng)一后能提升后續(xù)的開發(fā)效率，動效格式使用亂套的話，后續(xù)我們做更新迭代時做替換會很麻煩，開發(fā)也同樣如此，這里推薦幾種動效格式文件，分別是 GIF、json、pag、svga 這 4 種。
GIF：傳統(tǒng)的動效文件格式，優(yōu)點是學習成本低，第一個缺點是內存大，圖片容易失真模糊，他的原理就是把每一幀的圖片融合在一起，最后形成動畫，圖片越多，內存越大，第二個缺點是占用產(chǎn)品資源，當內存過高時，在加載時會出現(xiàn)卡頓。
Json：該文件格式是通過 Lottie 實現(xiàn)的，是 Airbnb 開發(fā)的一款能夠為原生應用添加動畫效果的開源工具，它的優(yōu)點就是內存小、無需加載、動畫不會失真，缺點呢就是支持得動畫方式?jīng)]有 gif 那么全面，以及使用成本也比較高。
具體使用步驟是需要我們裝 ae 插件 bodymovin，通過插件導出 json，常遇見的問題就是在導出漸變動畫時，漸變效果會消失，這是因為我們 ae 安裝得都是中文版，而該插件更多的適配是英文版，不過沒關系這里可以把漸變效果的名字改為 gradient fill1 就可以了，如果多個漸變的話我們更改后面序列號就可以，比如 gradient fill1、gradient fill2、gradient fill3…，這里把漢化插件鏈接也給大家找到了。
網(wǎng)站鏈接：https://zdo.fun/?p=557
我的經(jīng)驗
Pag：pag 是騰訊研發(fā)的一種技術文件，最初主要用于游戲動畫和直播動畫，用來解決復雜的動畫效果，目前在 ui 頁面中運用也比較多，優(yōu)點是占比內存比 json 文件更小，支持的動畫方式也更豐富，運行時可編輯，缺點是適配原生有些問題，壓縮位圖時會出現(xiàn)不顯示，這個軟件目前還在完善階段，我曾經(jīng)也使用過，后來因為適配問題就放棄了，感興趣的大家可以通過下面鏈接下載。
網(wǎng)站鏈接：https://pag.io/docs/install.html
svga：該文件格式的強大之處在于可以完整的將位圖轉換成二進制代碼，并且內存占比較于 json 更小，播放資源占用更低，并且技術上相對穩(wěn)定（建議使用）
網(wǎng)站鏈接：https://svga.io/designer.html
我們看下 svg 實現(xiàn)的效果
最后，我們一定要統(tǒng)一產(chǎn)品內使用的動效文件格式，這樣既方便我們，也方便開發(fā)，讓開發(fā)看到我們設計師的嚴謹性，便于后續(xù)合作。
1. 跟進開發(fā)進度
作為設計師，我們需要實時了解開發(fā)的進度，這樣能夠保證我們在過程中掌握自己的設計節(jié)奏，什么時間交給開發(fā)動效文件，如果進行修改也可以不影響上線時間（當然不建議這樣做），那么具體需要怎么跟進呢，大概分為以下幾個維度。
時間進度跟進：
設計師可以時不時的問一嘴，是否能按照正常的計劃時間節(jié)點提測（正常需求提交后，開發(fā)會給出開發(fā)排期，盡量按照時間排期走，否則項目進度會變得很不可控）。
如果開發(fā)反饋時間會有延期風險，那設計師第一時間就要了解原因，以及預計延期多久，然后自身評估以下對設計上是否有影響。
需求變更跟進：
一般開發(fā)過程中，或多或少都會出現(xiàn)一些需求調整/變更的點，那么其中就會涉及設計上的改動，改動小的話產(chǎn)品經(jīng)理有時候會直接告訴我們，并不會告訴開發(fā)，這時候如果身為設計師的我們要及時通知開發(fā)，并說明原因（避免爭論）。
并且，需求變更后，需要和開發(fā)評估新的項目上線時間點，站在我們或者產(chǎn)品角度理解有時候我們認為的修改，對于開發(fā)來講是耗費時間較長的，需要我們注意是否會影響上線時間。
交互動效實現(xiàn)跟進：
在 2-4 中講到我們要輸出交互動畫，雖然我們輸出的動畫很直觀，以及動效文件也完整，但是避免不了認知上的偏差，有時候開發(fā)會按照技術難度以及自身理解去完整交互效果，我們中途要隨時跟進了解，避免開發(fā)在錯誤的路上越走越遠。
測試跟進：
及時了解該需求是否已經(jīng)提測、哪些還未提測，若到了提測時間的功能未進入測試，可以詢問產(chǎn)品或開發(fā)什么原因，這樣對項目或設計師都是負責的。
另外一點是我們設計師需要在提測階段介入 UI 走查，因為各個公司或者項目測試時間有長有短，所以我們要及時把 UI 走查工作介入進去，給開發(fā)預留出修改時間，有的小公司不重視 UI 走查流程，這里我們就可以自驅進行走查，主動找測試同學了解提測時間，及時走查，保證頁面還原度。
2. 設計走查
走查是 UI 工作中最為重要的工作，它決定著產(chǎn)品上線后能否完美的展現(xiàn)給用戶，下面我大致把走查的流程以及范圍給大家梳理下。
創(chuàng)建走查文檔
在 UI 走查階段，我們首先需要建立走查文檔便于開發(fā)瀏覽解決，走查文檔主要包含日期、版本、項目名稱、模塊、端口、問題描述、修改狀態(tài)、圖片標注，這樣一方面能夠讓問題更加詳細，體現(xiàn)設計師的專業(yè)度，一般我是使用在線表格去建立走查文檔，當然這個看每個公司所使用的協(xié)作平臺。
開通手機權限
一般在走查移動端產(chǎn)品時，安裝測試包需要開通賬號權限，這里可以找公司的開發(fā)或者測試同事給開通，避免影響走查效率。
走查范圍
分為基礎走查、細節(jié)走查、適配走查
基礎走查包含字體、顏色、圖標、間距、對齊方式等具體可根據(jù)產(chǎn)品形態(tài)進行延伸，其中間距走查比較費時間，需要我們通過測試機截圖后，按照倍數(shù)縮放到源文件內進行測量，測試機分辨率需要保證與設計稿一致，否則測量不準確，例如設計圖是 375*812，以 ios 為例測試機則需要使用與 375*812 分辨率相同的尺寸測試。
細節(jié)走查包含字體截字、按壓狀態(tài)、組件內容、交互狀態(tài)
適配走查包含關鍵信息是否超出屏幕、是否出現(xiàn)擠壓、是否出現(xiàn)重疊、識別度是否清晰
3. 避免添加復雜交互
在走查階段如果我們發(fā)現(xiàn)部分的交互效果不太理想，并未達到預期，我們可以與開發(fā)進行溝通是否可以修改，或者添加新的交互效果，因為在這個階段我們重新設計或者定義一個新的交互動效的話，會增加非常大的開發(fā)工作量，可能也會與開發(fā)產(chǎn)生爭吵，我們在這個時期盡量避免這個問題，如果實在沒有解決辦法的時候再去添加新的交互。
我在工作中，如果遇到這種事情，會分兩點考慮這個事情。
第一評估下當下這個交互效果是否會影響用戶體驗，如果影響用戶體驗我會要求開發(fā)必須 100%還原，當然我會講述清楚為什么改，避免讓開發(fā)產(chǎn)生情緒抵抗。
第二是如果不影響用戶體驗，但是還原度沒有達到預期，我同樣會先找開發(fā)進行溝通，例如按照交互稿還原會有什么困難，是時間上的困難還是技術上的困難，時間上如果困難我會溝通好下一期必須還原到位，技術上困難我一般會修改交互形式，盡量保證上線后給用戶展現(xiàn)的是完美的狀態(tài)。
4. 數(shù)據(jù)追蹤
作為設計師在需求上線后并不代表需求就結束了，我們還需要追蹤數(shù)據(jù)情況是好是壞，為什么我們設計師要去追蹤這個數(shù)據(jù)呢，追蹤數(shù)據(jù)是為了讓我們在工作中提升自己的設計價值，隨著現(xiàn)在互聯(lián)網(wǎng)發(fā)展逐漸飽和，那么企業(yè)對于各個崗位的要求也跟互聯(lián)網(wǎng)初期不一樣，以前我們只需要畫畫圖交付就可以了，但是現(xiàn)在的企業(yè)更看重的是綜合能力，說簡單點就是做 UI 的人很多，優(yōu)秀的 UI 一樣很多，那么我們就得被迫提升核心競爭力否則就是被淘汰。
而追蹤數(shù)據(jù)其實就是增加我們得核心競爭力，同時也是能夠體現(xiàn)自己設計能力的一項內容，設計最終是為商業(yè)而服務的，但我們不能嘴上說說，而是要拿出實際的行動，這個行動就是數(shù)據(jù)，我們的設計如何為數(shù)據(jù)賦能的，如何幫業(yè)務達到目標等等，數(shù)據(jù)如何分析是個很龐大的體系這里只講下我們身為設計師為什么需要追蹤數(shù)據(jù)。
簡單講下工作中數(shù)據(jù)解析的案例。
下面是我做的一個直播商業(yè)化改版需求，改版背景呢是直播業(yè)務由原先的為 c 端用戶賦能改為，為 b 端企業(yè)賦能，通過與企業(yè)合作而產(chǎn)生價值，那么基于這個直播形態(tài)肯定是需要變化的，需求目標由原先的「用戶收益」改為「企業(yè)收益」，新的目標具體為提升企業(yè)品牌曝光點擊、互動、預約人數(shù)、提升直播在企業(yè)客戶測的感知收益。
案例
基于這個目標，其實不難發(fā)現(xiàn)，目標已經(jīng)從用戶側改為大客戶，更多的是為企業(yè)去賦能，頁面的結構肯定需要進行變化的，左邊的圖呢是改版之前的，右邊的是改版之后的，那么我當時的思路呢其實就是基于數(shù)據(jù)方面去進行優(yōu)化。
整體：產(chǎn)品策略添加了二級浮窗用來承載更多內容。
直播介紹：首先舊版策略是直播介紹對于用戶而言并不重要，用戶只需要通過看到直播標題就能夠了解大致直播內容，更多是以引導形式存在，所以信息外漏較少，而新的策略是講企業(yè)介紹默認展示在二級浮窗內，用戶可選擇關閉，提升企業(yè)感知。
投遞簡歷：舊版策略是需要側重用戶投遞率，因此在預約界面就展示入口，而新的策略是需要給企業(yè)強化觀看人數(shù)、預約人數(shù)從而提升客戶價值，基于這一點，我當時是通過數(shù)據(jù)后臺看了下預約頁面的點擊數(shù)據(jù)，發(fā)現(xiàn)點擊率最最高的是「投遞簡歷」入口，而「預約直播」入口點擊率相對較低，因此把投遞簡歷入口調賬到浮窗 tab 區(qū)域，降低層級，讓預約直播成為視覺焦點，而上線后數(shù)據(jù)也是符合預期。
企業(yè)關注：將企業(yè)名稱與關注結合并且放大，提升關注量，強化企業(yè)品牌感知和數(shù)據(jù)感知，關注與預約直播兩者無論數(shù)據(jù)高低，都是符合企業(yè)目標，從而便于業(yè)務人員與企業(yè)進行合作溝通。
從我這個案例中我們能清楚看到，基本上任何需求都是可以通過數(shù)據(jù)的維度，進行優(yōu)化，并且通過量化指標提升設計價值，無論對公司還是個人都有很大收益，并且我們追蹤數(shù)據(jù)也便于后續(xù)我們與開發(fā)對接時，可以通過數(shù)據(jù)維度去促進我們設計上的修改、完善等工作，這也是為什么說我們需要對每個需求都要進行數(shù)據(jù)追蹤。
無論是對接前、對接中、對接后，在哪個階段都需要我們認真對待，熟知這些細節(jié)后，才能更好的與開發(fā)合作，進行項目推進，優(yōu)秀的設計師不僅是專業(yè)和技術上的成熟，還需要有協(xié)作上下游的能力，在很多團隊中設計師跟開發(fā)都會面臨不一樣的挑戰(zhàn)最終可能會因為某些問題發(fā)生沖突，我們需要減少這樣的沖突。
作者：愛吃貓的魚
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優(yōu)秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯(lián)系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯(lián)系，我們立即更正或刪除。
藍藍設計( www.bouu.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數(shù)據(jù)可視化設計公司、UI交互設計公司、高端網(wǎng)站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司
