避免沖突開發說這個設計實現不了「避免沖突開發說這個設計實現不了」 今天小豆培訓網學歷教育小編就來給大家簡單介紹一下。
編輯導語：作為產品設計師，除了處理日常的設計業務外，和其他業務人員進行對接、共同推動產品項目落地，也是必須完成的事情至于。那么在產品設計過程中，設計師要如何避免和開發或者其他人員之間的沖突，以推動產品的快速落地？不如來看看作者的經驗總結吧！
前段時間在進行面試的時候，問到很多候選人開發溝通上的問題上，大多人都回答的模糊不清，決定根據自己的過往經驗講一下在工作如何溝通協調項目。
本文分別以對接前準備、對接中避免摩擦、對接后追蹤三個時間段講解流程中應該注意什么。
任何團隊都會出現設計師與開發脫節的問題很常見，遇見什么問題解決什么問題，畢竟人與人的性格、溝通方式等都是不同的。
我們只需要在不同的流程里去做不同的事情就可以避免這些問題了，對于任何設計師基本都會適用，往下看～
二、對接前的準備1. 產品信息文檔確認在接到一個需求的時候產品經理會通知上下游進行需求的評審，這時候一般會是產品經理、設計師、開發三個組進行需求的評估，具體的需求評審在本章就不細講，我們此次主要講設計師與開發相關的信息同步。
在評審過程中產品經理會把需求背景、需求目標等相關信息同步給相關的人員，作為設計師這時候就要關注需求目標，這個目標不僅是產品經理的目標，也是整個項目的目標，所以與每個人都相關，需求目標清晰后期推動開發的時候才會有依據。
評審會議結束后，產品經理會同步期望上線時間，如果是常規需求，會當時就評估出設計時間、開發時時間，我們設計師這時候就要關注這些時間，因為我們通過上線時間就可以估算開發節奏，給我們后期的修改以及臨時添加的一些動效制作時間會留出充裕的時間。
設計評審流程細節本章不進行細節講解，本章重點講與開發對接。
在設計稿內的切圖，我們要提前與研發溝通，切圖的范圍和形式，最后把設計稿傳入公司統一使用的協作網站，如藍湖、即時設計等平臺，大公司會有自己的協作平臺。
3. 確定設計規范組件講個自己的踩坑案例，還是商業化的那個需求，由于為了商業化賦能，產品的需求文檔并沒有按照規范組件進行設計，但是由于產品文檔標注的不清楚，在設計過程中不斷與產品進行溝通，最后結果當然也是無法復用組件。
當時我就把組件規范修改了，重點是研發不知道，我當時想的是研發通過產品文檔應該會了解到，事實確實我大意了，后面就導致組件方面我與研發進行了相愛相殺，通過自己的以身作則我勸大家不要忽略任何一個細節！
設計規范組件在設計前就需要進行確認，項目是否有存留的規范組件，如果有，需要在設計前以及設計中去確認哪些模塊是否可以調用，開發是否已經將組件寫入代碼中，如果不了解這些情況貿然的設計，那在對接過程中會出現修改設計稿的風險。
4. 輸出設計文檔當在做一些在舊版的產品頁面上優化的需求時，還需要輸出對應設計文檔，給前端和測試看，設計文檔需要寫清楚設計稿優化的點，例如圖標的細節優化、文字的字號優化、色彩優化、界面交互等等細節。
前端在看我們設計稿時如果不是結構上的修改，他們不會去關注這些細節的點，而給測試看的目的是，有些公司測試會幫我們進行走查，如果不出設計文檔測試沒辦法進行對比（測試提bug比設計師提bug更具有一些權威性）。
這里看一下我工作中輸出的設計文檔，我會把需求的背景、目標在設計文檔上強調一下，再添加上設計目標，設計目標為了需求目標去賦能，這樣在文檔開始就與研發達成共識，讓研發是帶著共同完成目標的態度去看設計文檔，便于我們后續推動，其次放上頁面之間的說明。
5. 交付開發最后總結一下，我們要交付給開發什么東西，首先是基本的設計稿，包括切圖、間距、動效文件，其次是設計文檔，包括需求背景、需求目標、設計目標、設計修改點說明。
我曾經在做一個頁面改版的時候，就遇到類似的問題，當時產品找到我說改一個地方的交互，并且我也覺得那個交互方式應該改，當時的我以為產品經理會同時告訴開發修改的地方，但是直到項目上線后開發都沒修改那個地方的交互。
本來這個修改點是個小事情，誰知剛好那一個版本被用戶吐槽那個頁面的交互，結果可想而知領導拉個會議開始復盤，為什么沒有改，索性大家沒有互相甩鍋的情況，產品經理說沒有同步到開發，而我也是幫產品兜了一下說更新設計稿沒有告訴開發，這個事情原本是個很小的事情，只需要我順口同步給開發，就能夠避免的，就因為我沒有及時同步，造成用戶的反饋，影響了產品的體驗。
所以各位設計師工作中如果遇到類似的事情一定要及時同步！
3. 統一需求目標開始講到過，在需求評審的時候要與開發對齊目標，為什么需要對齊目標，因為一個項目如果目標不對齊，那么每個人都會站在自己的角度去做這個需求，設計師思考的是通過設計的手段，去幫助產品完成目標，如果設計稿上的復雜效果較多的時候，開發則會考慮你為什么這么做，這么做開發成本非常高等等。
這也是說為什么我們開始就講要輸出設計文檔，如果這一切都不存在的話就會導致開發是帶著疑問寫我們的頁面，如果過程中在修改需求什么的，那我們跟開發又要相愛相殺了。
我的設計方式是通常是在產品評審階段就與開發明確講清楚，我大概要做什么樣的效果，什么的交互形式，預計什么時候會交初步方案，中途也可能會有修改的點等等，提前讓開發有個心理預期，避免在開發過程中產生抵抗情緒。
我的經驗▼▼▼
Json：該文件格式是通過Lottie實現的，是 Airbnb 開發的一款能夠為原生應用添加動畫效果的開源工具，它的優點就是內存小、無需加載、動畫不會失真，缺點呢就是支持的動畫方式沒有gif那么全面，以及使用成本也比較高。
c）交互動效實現跟進
在2-4中講到我們要輸出交互動畫，雖然我們輸出的動畫很直觀，以及動效文件也完整，但是避免不了認知上的偏差，有時候開發會按照技術難度以及自身理解去完整交互效果，我們中途要隨時跟進了解，避免開發在錯誤的路上越走越遠。
d）測試跟進
及時了解該需求是否已經提測、哪些還未提測，若到了提測時間的功能未進入測試，可以詢問產品或開發什么原因，這樣對項目或設計師都是負責的。
另外一點是我們設計師需要在提測階段介入UI走查，因為各個公司或者項目測試時間有長有短，所以我們要及時把UI走查工作介入進去，給開發預留出修改時間，有的小公司不重視UI走查流程，這里我們就可以自驅進行走查，主動找測試同學了解提測時間，及時走查，保證頁面還原度。
2. 設計走查走查是UI工作中最為重要的工作，它決定著產品上線后能否完美的展現給用戶，下面我大致把走查的流程以及范圍給大家梳理下。
a）創建走查文檔
在UI走查階段，我們首先需要建立走查文檔便于開發瀏覽解決，走查文檔主要包含日期、版本、項目名稱、模塊、端口、問題描述、修改狀態、圖片標注，這樣一方面能夠讓問題更加詳細，體現設計師的專業度，一般我是使用在線表格去建立走查文檔，當然這個看每個公司所使用的協作平臺。
4. 數據追蹤作為設計師在需求上線后并不代表需求就結束了，我們還需要追蹤數據情況是好是壞，為什么我們設計師要去追蹤這個數據呢，追蹤數據是為了讓我們在工作中提升自己的設計價值，隨著現在互聯網發展逐漸飽和，那么企業對于各個崗位的要求也跟互聯網初期不一樣，以前我們只需要畫畫圖交付就可以了，但是現在的企業更看重的是綜合能力。
說簡單點就是做UI的人很多，優秀的UI一樣很多，那么我們就得被迫提升核心競爭力否則就是被淘汰。
而追蹤數據其實就是增加我們得核心競爭力，同時也是能夠體現自己設計能力的一項內容，設計最終是為商業而服務的，但我們不能嘴上說說，而是要拿出實際的行動，這個行動就是數據，我們的設計如何為數據賦能的，如何幫業務達到目標等等，數據如何分析是個很龐大的體系這里只講下我們身為設計師為什么需要追蹤數據。
簡單講下工作中數據解析的案例。
下面是我做的一個直播商業化改版需求，改版背景呢是直播業務由原先的為c端用戶賦能改為，為b端企業賦能，通過與企業合作而產生價值，那么基于這個直播形態肯定是需要變化的，需求目標由原先的【用戶收益】改為【企業收益】，新的目標具體為提升企業品牌曝光點擊、互動、預約人數、提升直播在企業客戶測的感知收益。
案例▼▼▼
基于這個目標，其實不難發現，目標已經從用戶側改為大客戶，更多的是為企業去賦能，頁面的結構肯定需要進行變化的，左邊的圖呢是改版之前的，右邊的是改版之后的，那么我當時的思路呢其實就是基于數據方面去進行優化。
整體：產品策略添加了二級浮窗用來承載更多內容。
直播介紹：首先舊版策略是直播介紹對于用戶而言并不重要，用戶只需要通過看到直播標題就能夠了解大致直播內容，更多是以引導形式存在，所以信息外漏較少，而新的策略是講企業介紹默認展示在二級浮窗內，用戶可選擇關閉，提升企業感知。
投遞簡歷：舊版策略是需要側重用戶投遞率，因此在預約界面就展示入口，而新的策略是需要給企業強化觀看人數、預約人數從而提升客戶價值，基于這一點，我當時是通過數據后臺看了下預約頁面的點擊數據，發現點擊率最最高的是【投遞簡歷】入口，而【預約直播】入口點擊率相對較低，因此把投遞簡歷入口調賬到浮窗tab區域，降低層級，讓預約直播成為視覺焦點，而上線后數據也是符合預期。
企業關注：將企業名稱與關注結合并且放大，提升關注量，強化企業品牌感知和數據感知，關注與預約直播兩者無論數據高低，都是符合企業目標，從而便于業務人員與企業進行合作溝通。
從我這個案例中我們能清楚看到，基本上任何需求都是可以通過數據的維度，進行優化，并且通過量化指標提升設計價值，無論對公司還是個人都有很大收益，并且我們追蹤數據也便于后續我們與開發對接時，可以通過數據維度去促進我們設計上的修改、完善等工作，這也是為什么說我們需要對每個需求都要進行數據追蹤。
五、總結無論是對接前、對接中、對接后，在哪個階段都需要我們認真對待，熟知這些細節后，才能更好的與開發合作，進行項目推進，優秀的設計師不僅是專業和技術上的成熟，還需要有協作上下游的能力，在很多團隊中設計師跟開發都會面臨不一樣的挑戰最終可能會因為某些問題發生沖突，我們需要減少這樣的沖突。
作者：愛吃貓的魚；公眾號：防脫發藥水
本文由 @愛吃貓的魚 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
1、動畫設計工程師大學學什？
動漫專業，是高端技術，你可以了解下所涉及到的課程。認證方面，有3D認證，After Effects 認證，MAYA認證等。2、沖突管理的原則與方法有哪些？
沖突管理的原則要遵循三個方面方面如下原則：
1.要分清沖突的性質。建設性沖突適當鼓勵，破壞性沖突則盡量避免。
2.要針對不同類型的沖突采取不同措施。個人與個人之間、個人與團隊之間、個人與組織之間、團隊與組織之間都可能產生沖突，要分別采用不同的管理對策。
3.充滿沖突的團隊猶如一座火山，沒有任何沖突的團隊等于一潭死水，因此既要預防團隊之間的沖突也要激發團隊之間的沖突。
沖突管理的方法可以歸納6種方法如下：
1.問題解決。問題解決就是沖突各方一起積極地定義問題、收集問題的信息制定解決方案，最后直到選擇一個最合適的方案來解決沖突，此時為雙贏或多贏。但在這個過程中需要公開地協商，這是沖突管理最理想一種方法。
2.合作。集合多方觀點和意見，得出一個多數人接受和承諾的沖突解決方案。
3.強制。就是以犧牲其它各方觀點為代價，強制采納一方觀點。一般只適用于贏和輸這樣的游戲情景里。
4.妥協。就是沖突各方協商并尋找一種能夠使沖突各方都有一定程度滿意，但沖突各方沒有任何一方完全滿意，是一種都做一些讓步的沖突解決方法。
5.求同存異。求同存異的方法就是沖突各方都關注他們一致的一面，而淡化不一致的一面。一般求同存異要求保持一種友好氣氛，但是回避了解決沖突的根源。也就是讓大家都冷靜下來，先把工作做完。
6.撤退。就是把眼前的潛在沖突擱置起來，從沖突沖撤退。
