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