人們都喜歡步驟型的教學內容。我作爲設計刊物的編輯，經常會見到許多類似於“10步完美與開發人員對接”或是“整理設計文件時的禁忌”，他們會吸引許多在執行日常工作前需要尋找指導的設計師。這些指南大多數都是一些策略性的小技巧，例如標註設計文件、整理文件夾，或是同類文件整理的最佳案例，這些小技巧被證明可以應用到工作中的各個方面。

規範性的指南在指導設計與開發的交接時很容易遵循與修改，但是這些具體的操作指南是否能跟得上未來新工具的更迭？

事實上有許多種方法可以整理文件，命名文件夾或是多版本管理。如果只是提供一種方法，那麼設計者就沒有考慮到每個團隊的需求與執行方式都是不同的。

我們使用的工具會經常變化。設計師們處於各行各業，設計類型與所處團隊規模都有差異，而且每家公司都有自己的組織影響設計師的工作流程，工具使用與執行。甚至在同一個團隊中，由於時間與合作人數的變化，設計的具體流程也會發生較大的變化。

好的合作方式是提供原則指導，而不是具體策略

我工作了15年，見過許多迭代版本的設計師與開發人員的交接流程。甚至在我剛開始從事設計工作時，我們將設計文件存儲在本地然後直接扔給開發人員，他們帶入自己的主觀審美將設計稿轉化爲代碼實現。

經過多年來的發展，設計師與開發者的合作方式已經經歷了許多變化。一些方法已經通過實踐驗證效果較好—但是在不同的項目中，也許某種方法很適合與這個項目，但是對另一個項目而言使用起來卻很糟糕。如果我要撰寫具體的合作指南，那可能我每隔一段時間都要重新撰寫——所以我選擇了聚焦於設計原則。原則不僅可以經歷時間的磨礪，適用的設計師類型以及團隊規模也更廣。

下面的列表列出了我個人提出的合作原則，作爲一名設計師，我每天至少花三分之一的時間與產品經理和實現設計的開發人員一起工作。雖然多年來具體的方法和技術已經發生了很大的變化，但這些原則仍然能夠抵抗時間的挑戰。

作爲設計師，我們在思考產品帶給用戶的體驗時，總是考慮用戶的需求和痛點。除非你自己開發，否則最終用戶永遠不會與我們的設計互動，他們將與開發人員基於我們的設計文檔構建的最終產品進行交互。這意味着我們在項目的這個階段所交付給的真正用戶是開發人員。

一旦我們將這個概念融入到我們的實踐中，關於我們工作流程的每一個決定都是以開發人員爲中心開始的。與我們對最終用戶進行研究的方式類似，我們可以在項目開始時與工程團隊進行面談，以瞭解他們的偏好、過程和痛點，並提出滿足他們需求的工作模型。

• 開發人員希望如何接收文檔？多長時間？通過什麼渠道？
• 細節越多越好？書面文檔和可視化文檔之間的正確平衡是什麼？
• 對於特定的開發人員來說，如何使用系統裏怎麼去工作的非可視規則的最有效方法是什麼？這如何與產品的其他部分和組織內的其他組織相結合?

團隊可能爲了方便協作會爲項目建立一個維基百科文檔；也許這個維基文檔只是一個每週兩次的會議記錄，其功能更多的是作爲記載會議的問答對話而無法形成具體的規範。有一些團隊習慣在整理好所有設計文件後纔會着手開發；還有一些團隊比較靈活，會在開發迭代和實驗中不斷的完善規範。

既然我們在設計過程中要根據用戶的需求調整我們的設計解決方案，同理我們也應該調整我們的設計工作流程，以適應我們的開發合作伙伴的需求。

除了極少數案例外，我們每次啓動新項目時都必須調整文檔和工作流。隨着經驗的積累，我們總結形成了自己撰寫文檔的模版，這種模版在特定的環境下可能會很好用，但不一定在所有環境下都完全適用。一個模版不是處理每個團隊的設計文檔和協作的好方法。

其次每個開發人員的習慣不同，有些開發人員喜歡和設計師面對面交流處理具體問題，還有一些開發人員可能更喜歡通過線上消息溝通或是投票表決來解決問題。

不是所有的事情都可以在設計師的掌控中，設計師唯一確定的是：每個項目都會存在變話。

有時候一些客觀的因素會影響你的工作，例如新同事加入團隊，發佈日期的突然調整，不可預見的平臺或網絡技術的約束。學習識別團隊中無形的協作機制並讓自己做好快速調整工作流程的準備，這也許不能在短期內避免挫折，但是會讓你變得更好。

特別是在瀑布式開發的項目中，或是敏捷性開發的初級階段，有一種常見的誤解：即設計師的工作就是將所有屏幕顯示需要的圖繪製出來就完成了所有工作，例如設計產品模型或原型，會讓人誤以爲設計師的職責僅僅是滿足開發要求設計師做的每個網頁圖片。但實際上設計師應該不僅應該考慮屏幕上顯示的頁面圖片，還需要分析背後的功能。

真正的挑戰開始於開發人員開始四處尋找關於我們設計的問題以及測試人員分析出設計師沒能預見的用例。添加的限制和規則越多，我們就越難在這些條條框框容納新的需求，並同時保持體驗的簡潔與明晰。那就是關鍵時刻：大多數團隊能畫出合格與優秀設計師之間的那條線。

我見過太多設計師推卸責任——這絕不是一件好事。如果最終的體驗沒有按照我們的設想實現，那麼這就是包括我們設計師在內所有人的責任。我們的角色是創造易於使用的體驗方案，而不是看上去漂亮的界面。這意味着我們需要爲團隊實現的最終產品負責。

富有遠見的德國設計師Dieter Rams時二十世紀最受認可和最具影響力的設計師之一。作爲功能主義的堅定信仰者，他對設計的理性認識可以概括爲他的著名短語：“少一點，但更好。”雖然他當時顯然是針對工業設計，但這一概念對於我們當今創造的數字產品和服務仍然適用。

隨着設計的發展，產品經理開始優先考慮功能，這時設計師會發現他們的許多工作都被縮水爲最小可行性產品，包括他們對產品的最初設想和經驗，這會令人感到沮喪。而我所知道的最優秀的設計師會將這種沮喪轉變爲機會，他們知道提供更少的功能是完全可以的，只要能提升體驗即可。

對於我們設計師而言，需要設計的功能變少意味着：

• 我們能將更多的時間花在更少的設計方案上使其更好：例如過場，狀態，動畫，複製。
• 我們能更緊密地和開發人員合作以保證我們正確傳達了初始設想。

設計師代表了團隊中用戶的聲音。我們常常理所當然地認爲，我們有能力設身處地爲用戶着想，而忘記了我們可以在團隊中傳播這種觀點和看法。可以是我們在研究過程中從用戶那裏聽到的一個小故事；或者是某個人的個人故事，因爲我們所創造的產品改變了他的生活方式。

我們的同理心，對用戶的關注以及我們的熱情—這些都是寶貴的資源，我們可以用來啓發開發人員，幫助他們理解某個特定功能應該如何工作，並且瞭解它將如何影響人們的生活。

設計是一項團隊活動

（謝天謝地）“搖滾明星設計師”的舊模式正在消失。隨着數字團隊的增長與項目變得更加複雜，設計師因其協作技能和團隊支持而受到重視，而不是僅僅繪製具體的交付物。定義團隊之間的合作原則纔是我們執行具體工作的第一步。

原文地址：https://uxdesign.cc/5-principles-for-better-designer-developer-collaboration-36b4094887db

本文由 @喵吉斯蒂 翻譯發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議