準備交接！如何確定開發支援？
編輯導語：設計交接是產品設計落地流程中的一個重要環節，它關係到產品的最終落地效果，也關係到最終的使用者使用體驗。那麼在這一環節中，團隊人員應該如何協作，以保證最終的方案實現？本文作者針對該問題做了解答，一起來看一下。
設計交接可能是產品開發過程中最關鍵但又令人沮喪的環節之一。此時，長時間的研究、設計和再製作工作已經結束，您的設計和高保真原型已準備好供工程師實施。
與任何其他流程一樣，設計工作流程也有其缺陷。設計師有時會在發現和開發階段的中間環節工作。因此，當設計交接發生時，完美設計稿的設計背景和設計意圖對於開發團隊來說通常是模糊的。
為了確保創意和創意願景被準確轉化為一種功能或產品，設計師最好在整個專案中與跨職能團隊密切合作。
與所有垂直團隊的溝通和協作是將風險和錯誤降至最低的關鍵。
每個團隊成員都必須同步瞭解該功能或產品的外觀、感覺和工作方式。
說來容易做來難。設計交接是貫穿整個設計過程的合作。它需要大量的時間、資源和迭代才能正確實現，以便在團隊中建立跨職能協作文化。
現在，讓我們深入探討設計師——開發人員交接期間的一些最常見的陷阱，並回顧一些策略，您可以採用這些策略來確定這一階段的開發支援。
一、這不是交接，這是協作
交接是一個棘手的詞，它意味著單向通訊。在專案團隊中，它經常被誤用為“擺脫”，在我們的案例中，這很重要，因為它意味著
剝離責任
。
當設計被移交給開發人員後，就認為他們就有責任將產品實現的這種想法是錯誤的。作為設計師，我們需要投身於產品開發，並確保在交接後不會產生丟失或誤解上下文和設計意圖等問題。這種疏忽可能導致功能或產品不能完全達到預期目的，這是每個設計師的噩夢。
最好的情況是，設計和開發團隊在開發過程中的每一步都密切合作和協作。有時，這意味著頻繁的創意會議，需要和工程師坐在設計臺前就設計理念提供指導和反饋。
無論您選擇哪種方法，這種雙邊協作對兩個團隊都是有利的。設計師將更好地瞭解產品技術細節，並評估其設計的哪些部分可以被實施。另一方面，開發團隊也能瞭解到正在進行的工作以及需要哪些準備才能正確執行任務。
儘管設計和開發團隊不同，但可以將其視為同一硬幣的兩面。兩個部門有著相同的最終目標：建立一個儘可能為使用者服務的產品。最終，
產品的外觀和感覺，與其功能和效能同等重要。
開發產品是一項團隊運動。它需要多學科團隊中所有專家的能力來激發創意並持續前進。設計-開發合作是雙向的，交接後應繼續進行。
兩個部門需要了解彼此的內部機制，以建立健康的工作動力。
畢竟，三個臭皮匠頂一個諸葛亮。
技巧
在構思階段召開設計評審會議。與您的團隊一起決定開會頻率。通常每週1到2次就夠了。
在與隊友合作時，鼓勵分享想法和開放溝通。
確定您和您的隊友在協作時將使用的工具和軟體。每個人都需要資訊對齊，並對他們將要使用的工具感到舒適。
保持開放心態。事情並不總能按計劃進行，限制總在拐角處等待著。準備好使用你所擁有的，並充分利用。
準備好妥協——不是消極的意思。在產品開發中，每個團隊成員在談話中都可能輸出有效觀點，因此，固執己見不會給產品帶來任何好處。在出現分歧時，請確保您是在為使用者辯護，並確保他們的體驗不會被忽視。
當涉及到工作和協作流程時——試錯是必經之路。嘗試和試驗不同方法和框架，直到找到最適合您和團隊的那一個。
請別孤軍奮戰——您需要有人來幫助您。
二、工程師們想看什麼？有意義的可交付物
當涉及到可交付成果及其演示時，一個好的做法是提前考慮您的受眾。想想誰將使用您正在建立的交付物，以及哪些內容對他們來說是重要的。設計師的一個常見問題是，把大量時間和精力花在跨功能團隊中沒人使用的交付物上。如果問自己”為什麼”，您得到的最直接答案是——因為它沒用。那麼，該如何讓它有用呢？
讓我們退一步，想想設計交接會議是怎樣進行的。通常，設計師會展示設計/原型的最終版本，然後解釋整體願景、功能和設計選擇。之後，輪到開發團隊提出澄清性問題，有時這些問題會變成一整套不確定因素，如：
這個返回按鈕會跳到哪裡？
如果使用者沒有管理員許可權會怎麼樣？他們能看到這個選項嗎？
如果我們將來引入更多選單選項會怎麼樣？我們如何在 UI 中相容它？
這樣您就明白了，有用的設計交付物的關鍵，是覆蓋
整個使用者/客戶體驗。
但是，我們如何確保設計涵蓋一切？說實話，您可能不會覆蓋所有用例，尤其是邊緣用例，只要弄弄清楚主流程即可。
開發團隊是分析型結構。他們依賴資訊和事實，對於他們來說，擁有無需解釋的可交付物至關重要。為了清楚地理解設計交付物背後的設計理念和基本原理，它需要具體且切中要害。
1. 端到端使用者故事
您需要弄清楚的第一件事，是
端到端使用者故事
或設計計劃。端到端使用者故事的範圍比 Jira 的發展故事更廣，後者通常針對較大流程中的特定功能或小型任務。它透過為特定使用者角色遵循的用例、邊緣案例和分步場景提供線索，從而提供整個使用者體驗的檢視。這意味著
UX 包含在早期產品概念定義階段
，並確保作品中的功能/產品能夠使使用者實現其目標。
2. 快樂和不快樂的道路
工程師們正在尋找的另一件事是
快樂和不快樂的道路。
作為需求收集和 IA 階段的一部分，在專案開始時就規劃可交付物是有好處的。快樂路徑可以用作檢查表，以檢視設計中是否涵蓋了所有用例。而不快樂路徑透過提供錯誤狀態和替代或恢復行程，來幫助開發產品的錯誤處理策略。
不用擔心，這並不意味著您需要對映設計中的每一個錯誤狀態，只需確保精確定位影響使用者任務完成的關鍵路徑即可。
3. 資產和元件
設計交接的另一個重要部分是
資產和元件規範。
現在，可以透過像 Figma 這樣的端到端設計平臺來輕鬆管理。
允許您使用同一工具進行資產交付、線框圖和原型設計。元件和資產易於管理，工程師可以直接從設計檔案/庫中下載。
不要忘記列出元件度量、填充、大小、狀態和使用規則，以便開發團隊能夠明確說明如何開發它們。FigmaTokens 是一個有用的外掛，它可以顯示邊框半徑、顏色、間距單位等，並且可以動態更新您的設計。
4. 原型和動畫
最後但並非最不重要的是，不要忘記
原型和動畫
（如果有的話）。
在模擬功能或產品開發後的行為時，原型非常有用。這也是測試您的假設和設計假設的好方法。一個好的方法是透過為每個功能製作動態流程，使原型基於功能。您還可以提供有關使用者及其角色、假設和場景的一些上下文。這樣，您將確保涵蓋所有使用者用例，並且您已經提前回答了工程師的大部分問題。
5. 技巧
儘量不留任何解釋——為使用您設計交付物的受眾提供足夠多的上下文和明確的指導。
可以向您的團隊詢問有關可交付物的反饋，並找出哪些最有用，集中精力提供這些。
瞭解您的產品。作為產品設計師，您有時需要身兼數職併兼顧各種責任。您擁有的跨職能部門的背景越多，您就可以做出更好、更明智的決策。
出具需要提供給團隊的設計交付品清單，同時製作一些模板，這樣，您就可以重複使用並保持一致。
明確區分已準備好開發的設計和正在進行的工作。在您使用的設計工具中放置一些狀態和資訊豐富的縮圖就可以。
三、總結
設計交接不僅僅是敏捷工作流程中的一次性儀式，這是一個協作的過程。設計和開發之間應建立良好的溝通方式，以減少誤解和錯誤。儘管兩個團隊不同，但他們有共同的目標——那就是有一個有效且有意義的產品。產品目標是透過所有垂直團隊的協作努力來實現的。請記住，
工作團隊就是工作產品。
為實現這一目標，工程師應參與設計流程，設計師應跟進其設計的開發實現，並協助工程團隊為開發過程中可能出現的問題建立有意義的解決方案。
原文連結：https：//medium。com/vmwaredesign/prepare-for-hand-off-how-to-nail-that-development-support-4317a69e0010
本文由 @HitomiBot 翻譯釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議。
