起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識指導設計師與開發人員合作的5項原則
規范性的指南在指導設計與開發的交接時很容易遵循與修改，但是這些具體的操作指南是否能跟得上未來新工具的更迭？
人們都喜歡步驟型的教學內容。我作為設計刊物的編輯，經常會見到許多類似于“10步完美與開發人員對接”或是“整理設計文件時的禁忌”，他們會吸引許多在執行日常工作前需要尋找指導的設計師。這些指南大多數都是一些策略性的小技巧，例如標注設計文件、整理文件夾，或是同類文件整理的最佳案例，這些小技巧被證明可以應用到工作中的各個方面。
規范性的指南在指導設計與開發的交接時很容易遵循與修改，但是這些具體的操作指南是否能跟得上未來新工具的更迭？
事實上有許多種方法可以整理文件，命名文件夾或是多版本管理。如果只是提供一種方法，那么設計者就沒有考慮到每個團隊的需求與執行方式都是不同的。
我們使用的工具會經常變化。設計師們處于各行各業，設計類型與所處團隊規模都有差異，而且每家公司都有自己的組織影響設計師的工作流程，工具使用與執行。甚至在同一個團隊中，由于時間與合作人數的變化，設計的具體流程也會發生較大的變化。
好的合作方式是提供原則指導，而不是具體策略
我工作了15年，見過許多迭代版本的設計師與開發人員的交接流程。甚至在我剛開始從事設計工作時，我們將設計文件存儲在本地然后直接扔給開發人員，他們帶入自己的主觀審美將設計稿轉化為代碼實現。
經過多年來的發展，設計師與開發者的合作方式已經經歷了許多變化。一些方法已經通過實踐驗證效果較好—但是在不同的項目中，也許某種方法很適合與這個項目，但是對另一個項目而言使用起來卻很糟糕。如果我要撰寫具體的合作指南，那可能我每隔一段時間都要重新撰寫——所以我選擇了聚焦于設計原則。原則不僅可以經歷時間的磨礪，適用的設計師類型以及團隊規模也更廣。
下面的列表列出了我個人提出的合作原則，作為一名設計師，我每天至少花三分之一的時間與產品經理和實現設計的開發人員一起工作。雖然多年來具體的方法和技術已經發生了很大的變化，但這些原則仍然能夠抵抗時間的挑戰。
1. 開發人員是您的用戶
如果我們像關注用戶一樣關注開發人員如何使用我們的設計（和設計文檔）呢？
作為設計師，我們在思考產品帶給用戶的體驗時，總是考慮用戶的需求和痛點。除非你自己開發，否則最終用戶永遠不會與我們的設計互動，他們將與開發人員基于我們的設計文檔構建的最終產品進行交互。這意味著我們在項目的這個階段所交付給的真正用戶是開發人員。
一旦我們將這個概念融入到我們的實踐中，關于我們工作流程的每一個決定都是以開發人員為中心開始的。與我們對最終用戶進行研究的方式類似，我們可以在項目開始時與工程團隊進行面談，以了解他們的偏好、過程和痛點，并提出滿足他們需求的工作模型。
- 開發人員希望如何接收文檔？多長時間？通過什么渠道？
- 細節越多越好？書面文檔和可視化文檔之間的正確平衡是什么？
- 對于特定的開發人員來說，如何使用系統里怎么去工作的非可視規則的最有效方法是什么？這如何與產品的其他部分和組織內的其他組織相結合?
團隊可能為了方便協作會為項目建立一個維基百科文檔；也許這個維基文檔只是一個每周兩次的會議記錄，其功能更多的是作為記載會議的問答對話而無法形成具體的規范。有一些團隊習慣在整理好所有設計文件后才會著手開發；還有一些團隊比較靈活，會在開發迭代和實驗中不斷的完善規范。
既然我們在設計過程中要根據用戶的需求調整我們的設計解決方案，同理我們也應該調整我們的設計工作流程，以適應我們的開發合作伙伴的需求。
2.?唯一能確定的是：改變始終存在
設計師需要靈活處理項目，我們不僅要調整我們的流程以適應不同的團隊配置，而且還要隨著項目的展開調整我們的工作流。
除了極少數案例外，我們每次啟動新項目時都必須調整文檔和工作流。隨著經驗的積累，我們總結形成了自己撰寫文檔的模版，這種模版在特定的環境下可能會很好用，但不一定在所有環境下都完全適用。一個模版不是處理每個團隊的設計文檔和協作的好方法。
其次每個開發人員的習慣不同，有些開發人員喜歡和設計師面對面交流處理具體問題，還有一些開發人員可能更喜歡通過線上消息溝通或是投票表決來解決問題。
不是所有的事情都可以在設計師的掌控中，設計師唯一確定的是：每個項目都會存在變話。
有時候一些客觀的因素會影響你的工作，例如新同事加入團隊，發布日期的突然調整，不可預見的平臺或網絡技術的約束。學習識別團隊中無形的協作機制并讓自己做好快速調整工作流程的準備，這也許不能在短期內避免挫折，但是會讓你變得更好。
3. 設計永遠不會終結
當我們完成一個項目的設計時，其實我們只完成了一半的工作。
特別是在瀑布式開發的項目中，或是敏捷性開發的初級階段，有一種常見的誤解：即設計師的工作就是將所有屏幕顯示需要的圖繪制出來就完成了所有工作，例如設計產品模型或原型，會讓人誤以為設計師的職責僅僅是滿足開發要求設計師做的每個網頁圖片。但實際上設計師應該不僅應該考慮屏幕上顯示的頁面圖片，還需要分析背后的功能。
真正的挑戰開始于開發人員開始四處尋找關于我們設計的問題以及測試人員分析出設計師沒能預見的用例。添加的限制和規則越多，我們就越難在這些條條框框容納新的需求，并同時保持體驗的簡潔與明晰。那就是關鍵時刻：大多數團隊能畫出合格與優秀設計師之間的那條線。
我見過太多設計師推卸責任——這絕不是一件好事。如果最終的體驗沒有按照我們的設想實現，那么這就是包括我們設計師在內所有人的責任。我們的角色是創造易于使用的體驗方案，而不是看上去漂亮的界面。這意味著我們需要為團隊實現的最終產品負責。
4. 少一點，但更好
當產品經理砍掉產品某些功能來得到一個最小可行性產品時，設計師并不會感到沮喪，而是將它變為提升已有功能集合內體驗的機會。
富有遠見的德國設計師Dieter Rams時二十世紀最受認可和最具影響力的設計師之一。作為功能主義的堅定信仰者，他對設計的理性認識可以概括為他的著名短語：“少一點，但更好?！彪m然他當時顯然是針對工業設計，但這一概念對于我們當今創造的數字產品和服務仍然適用。
隨著設計的發展，產品經理開始優先考慮功能，這時設計師會發現他們的許多工作都被縮水為最小可行性產品，包括他們對產品的最初設想和經驗，這會令人感到沮喪。而我所知道的最優秀的設計師會將這種沮喪轉變為機會，他們知道提供更少的功能是完全可以的，只要能提升體驗即可。
對于我們設計師而言，需要設計的功能變少意味著：
- 我們能將更多的時間花在更少的設計方案上使其更好：例如過場，狀態，動畫，復制。
- 我們能更緊密地和開發人員合作以保證我們正確傳達了初始設想。
5.?激情具有感染力
在一些公司中，開發人員不參與早期的構思、設計探索和產品經理的戰略層次討論。我們如何才能幫助他們理解和領會，從而真正了解正在開發的功能?
設計師代表了團隊中用戶的聲音。我們常常理所當然地認為，我們有能力設身處地為用戶著想，而忘記了我們可以在團隊中傳播這種觀點和看法?？梢允俏覀冊谘芯窟^程中從用戶那里聽到的一個小故事；或者是某個人的個人故事，因為我們所創造的產品改變了他的生活方式。
我們的同理心，對用戶的關注以及我們的熱情—這些都是寶貴的資源，我們可以用來啟發開發人員，幫助他們理解某個特定功能應該如何工作，并且了解它將如何影響人們的生活。
設計是一項團隊活動
（謝天謝地）“搖滾明星設計師”的舊模式正在消失。隨著數字團隊的增長與項目變得更加復雜，設計師因其協作技能和團隊支持而受到重視，而不是僅僅繪制具體的交付物。定義團隊之間的合作原則才是我們執行具體工作的第一步。
原文地址：https://uxdesign.cc/5-principles-for-better-designer-developer-collaboration-36b4094887db
本文由 @喵吉斯蒂 翻譯發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
