跟開發Battle，設計師該如何“料敵制勝”

編輯導語：在我們的日常工作中總會遇到一些溝通的問題，比如設計師的一些產品設計需求，開發可能會有一些別的意見，雙方就會產生碰撞；但是在一個團隊里，合作才能共贏，怎么平衡好雙方的關系比較重要；本文作者分享了關于設計師在工作中遇到的溝通問題，我們一起來看一下。

今天想跟大家聊聊設計師工作中的溝通問題。

相信各位設計師在平時工作中經常會遇到一種情況：我們出的方案，開發同學不愿意做。

在筆者進入職場的這三年里，經歷過根據產品需求進行設計，完成后與開發同學直接對接，逐圖逐字地走讀方案；也經歷過在進行產品創新時，與產品團隊和開發團隊共同制定產品方向，擬定產品需求，提出設計建議。

事實證明無論是哪種情況，我們的方案多少都會受到開發同學的質疑，甚至于“阻撓落地”；于是我們不得不跟開發同學們去battle，花了很長的時間去進行一輪輪的開會、討論、磨合。

周期長而效率低，明日復明日明日何其多。

首先需要說明，在團隊工作中產生分歧的原因一定不是單向的。一個完美的產品的誕生必然要吸收多方的觀點，經歷思想的碰撞和接納。

而今天筆者想跟大家聊的是，如何在溝通階段準確地、有效地表達設計方案的理由和優勢，以及如何更好地讓開發同學接受、信服。這也是為了日后能更好地掌握屬于設計師的話語權。

畢竟開發同學也是設計師需要面對的一大用戶群。所以我們要了解用戶需求，才能準確判斷“敵情”，采取相應的對策戰勝“敵人”，讓他們被我們說服，然后干就完了。

其實大部分情況下，開發同學們不愿意按照設計師的方案做，只有以下兩點理由：

1. 他們不理解你的設計方案
2. 方案要求的工作量“看起來”太大了

01 他們不理解你的設計方案

大家有沒有遇到過這種情況：講解方案時，開發同學們總有各種疑問。

• “為什么你這個界面要做成這樣，我覺得那樣做也可以啊”
• “你看我平時這個產品做的是這樣，用著挺好的，怎么不按照這個做呢？”
• …..

在這個階段，開發同學往往是以用戶的身份在看待設計方案。他們習慣于自己平時常用的產品邏輯，有自己的想法，所以在拋出一個新產品的設計方案時，他們一時不易接受，不太明白。

筆者常用的方式是，在介紹方案前羅列出競品分析結論。

開發同學們雖然也會觀察同類產品，但也許只是籠統地了解了一下界面跳轉邏輯，或是界面布局的大致框架。作為設計師，我們會對同類產品的競品了解得更多，也能從設計師的角度看到其他人沒有發現的細節。

與開發同學走讀競品分析報告一般步驟為：

1. 競品全局與結論總結——總工作量說明
2. 關鍵界面特性小結——各模塊關鍵工作說明
3. 整體設計框架——工作量復盤及人力安排

筆者曾經主導過一個關于多媒體編輯功能的需求，在那時完全是做一個從無到有的產品；所以對當時的我們來說，方案的說服力和可證性至關重要。

筆者團隊當時搜集了市面上大量的同類競品，最終選出了11款進行了分析。

根據產品需求，我們將所有的視頻剪輯相關的功能都做了羅列，并根據全局操作和單素材操作進行了歸類，并將結論提前展示在報告的前幾頁，同時也讓開發團隊大概了解了總工作量：

• 哪些功能是我們必須要做的；
• 競品主流的界面邏輯設計是怎樣的；
• 每一個界面需要放一些什么東西。

我們對關鍵界面的具體分析也做了展示。重點說明每一章的小結，比如此模塊的最關鍵功能是什么，有哪些功能還不能滿足用戶需求等。

這一步是為了讓開發同學們對競品界面的框架有一個總的認識，以及讓他們知道我們發現了什么問題，讓每一位開發同學理解，在后續的工作中他們各自負責的界面需要重點關注的是什么。

到最后一步，我們再闡述了自己的設計方向，向開發同學展示了全局的交互框架，讓他們了解之后該做哪些工作，人力該如何分配，在此之后我們再進行詳細的界面走讀和答疑。

競品分析結論能讓開發同學方便地理解主流產品的設計邏輯以及普羅大眾的使用習慣，直觀地了解設計的根源性和合理性，也能讓他們對后續的工作量有一個大概的構想。

事實上，充分的前期分析工作不僅可以幫助設計師理清設計思路，抓到突破口；也能幫助我們應對從各方傳來的聲音，在與產品規劃團隊溝通方案時也同樣適用。

競品分析結論的展示，可以幫助我們證明：設計有來源，需求有根據，知己知彼才能百戰不殆。

02 方案要求的開發工作量“看起來”太大了

這種情況經常發生在有迭代需求時。

畢竟設計師的世界和工程師的世界是完全不一樣的，在設計師眼中，產品需求是控件、圖形和字符串；可在開發同學的眼中，產品需求是一行又一行的代碼；設計師修改方案當然不易，但我們換位思考一下，開發同學們改代碼可能眼睛和心靈更累。

開發同學會邊看新方案，邊本能地在腦海中將效果圖轉化為代碼，這時候他們的心理活動大致是這樣的：

• “這個界面的改動看起來很大啊，那我不又得花時間去找該改哪一行嗎？”
• “為啥這么小的點也要改啊，這不是和舊方案長得差不多嗎？”
• “誒這個界面B跟之前的界面A看起來長得差不多，要不拿界面A的代碼直接來用吧？”
• ……

于是他們就會有種種理由不愿改：

• “這幾個界面跳轉的邏輯太復雜了，我們開發壓力太大，你改改方案吧（?）”
• “我們評估下來這個需求的優先級不高，還是等我們先完成xx，你這個等一個月以后排人力吧（?）”
• “哎喲差不多就可以了，對用戶來說這一塊沒那么重要（?）”
• ……

實話實說，筆者這時候常用的兩種方式還是比較基礎的：

• 再次重點走讀競品分析
• 新舊方案對比走讀

方案需要迭代的原因主要有三點：

• 在開發初級階段沒按設計效果完全實現；
• 在測試階段，設計師檢視時發現有問題；
• 方案落地后，經過了一段時間的輿情收集，發現需要改進。

如果是第一個原因，我們就必須要再次向開發團隊說明良好的競品情況和還原本真方案的重要性，督促他們盡早按排人力處理問題；若是第二、三點原因，需要根據情況在設計團隊內部重新決策，再將新方案傳達給開發團隊。

我們在對開發同學進行新舊方案對比走讀時，比較基礎的方式（筆者目前會用的方式），大概就是將新舊兩張界面放在一起，向他們說明兩個界面的不同之處；但如果能利用開發同學熟悉的工作語言進行闡述，效果會有所提升。

筆者處理過一個“用戶總是不小心誤觸”的小問題，其根本原因在與文字熱區與圖片熱區范圍重疊，導致系統常常誤判，導致了用戶原本想要點擊圖片進入二級界面卻觸發了修改標題的情況。

因此在優化方案中，筆者不僅調整了界面效果，還劃出熱區的dp大小并設定了最寬范圍，在走讀時對接的開發同學也更容易看懂、理解。

之前在某次設計部分享會上，筆者從另一個團隊的同事那聽來一個好方法：他們在走讀優化方案的同時，幫開發同學將需要改的代碼挑出來了，告訴他們只需要改這兩行就可以了。

把開發同學當作用戶，利用用戶熟悉的語言讓他們理解要做什么事，這樣一來溝通成本大大降低了，也極大地提高了方案迭代的效率！

簡直妙哉，看來筆者也應該去學習一下代碼相關的知識了。

其實說實話，筆者是非常愿意跟有想法的開發同學們合作的。

會思考合理性、判斷產品邏輯的開發同學，在開發過程中會積極地跟設計師討論，還能從用戶的角度提提意見；另一方面，他們會根據經驗設想各種不同的使用情況，有時候也能幫助設計師發現一些沒有注意到的細節，幫助我們完善設計思路，說不定就有意想不到的效果。

就怕碰到那種啥想法沒有的開發同學，只會埋頭干，但又不完全按照設計方案干，溝通起來就更加困難嚕~

以上就是筆者對平時工作中的溝通問題的一些思考，希望對大家能有所幫助，也歡迎大家一起討論討論，在工作溝通中有沒有發生過什么有趣的事情呢~

 

作者：你柴；公眾號：你柴的aCupOfTea

本文由 @你柴 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議