編輯導語：作為一名設計師，開發前對產品的思索策劃與開發中的實現過程往往會存在一定的偏差。那麼，我們應該如何改進產品開發過程，減少自己和開發人員不必要的工作量，在產品開發中保證設計質量和體驗呢？
幾年前，我曾在一個大型公司的專案中工作，主要是為他們重新設計舊有的應用。這簡直是設計師一直夢寐以求的：有機會重塑全套 web 應用的未來使用者體驗，專案中釋出的第一款應用將為其他產品打下基礎。
我沒有浪費時間，立即開始研究使用者，瞭解現有軟體程式，與產品所有者（我們的客戶）和其他利益相關者合作，開始處理積壓的需求。
幾周後，我們對手頭的挑戰有了更好的理解，於是召集會議來討論設計新產品。與此同時，直到我們驗證了詳細的需求，並且至少有了一個粗略的線框圖之後，開發團隊就可以開始搭建必要的基礎架構。
幾個月過去了，我們從草圖到線框圖，為關鍵的使用者旅程勾勒出流程步驟，設計 UI 元件以及詳細的規範，甚至有原型來演示我們想要的產品實現方式。
我們已經去客戶那裡測試設計，收到了很好的反饋，一切似乎都朝著正確的方向發展。
只有一個問題：我們至此還沒有任何可以釋出的產品，而我們設計的產品和我們能做出來的產品之間相差了十萬八千里。
上述問題並不少見，我們一次又一次看到設計方案沒有實現，或者與預期的設計和體驗相去甚遠。
這對於探索或概念驗證一類的工作來說是很好的，但在快速發展的行業中，我們需要快速而頻繁的釋出產品，以保持在競爭中的領先地位。
在過去的幾年裡，為了改進產品開發過程，我調整了我的流程，並想分享一些關鍵的變化，希望這些變化也能幫助你和你的團隊。
一、MVP：不止是說說而已你可能聽過無數次“我們需要一個 MVP（Minimum Viable Product，最小可行性產品）”，但這不應該只是一個流行詞。
如果你完全理解如何實現一個可接受的 MVP，就可以幫助團隊把精力集中在釋出上。為了快速釋出，團隊必須願意釋出最基本的產品。
這對於客戶和利益相關者來說是非常困難的，因為他們往往為所有特性和功能做預算，並預期最終得到功能齊全的產品。但是先發布 MVP 的好處是顯而易見的。
你釋出的速度越快，就能把產品越快投向使用者，獲得有價值的反饋，並給你帶來意想不到的見解。而且，越早開始獲取使用者，你的使用者群就越快開始增長；在幾個月的使用者增長之後，你就會領先了。
你需要接受的是，MVP 可能沒有那麼快的競爭力，但也不需要立即進行大規模營銷。關鍵是儘快釋出，為持續的增量改進鋪平道路，從而為使用者提供不斷增長的價值。
Slack 是一個很好的例子，它依賴於使用者的反饋來幫助塑造產品。在沒有首席營銷官（CMO）和大眾營銷活動的情況下，他們透過傾聽使用者意見，逐步改進產品，贏得了使用者的心。
二、打破幻想作為設計創意人員個人，我們常常希望獨立工作，很少考慮我們無法控制的事情。
我們關心的是交付的成果，只要它們有效並且看起來很棒，我們就完成了工作。如果最終釋出的產品看起來或感覺不像我們的設計，那不是我們的錯，對吧？
事實上，人類是情感動物，視覺刺激更能說明問題。酷炫的介面更能讓客戶驚歎，並留下持久的印象。
作為創造者，我們也從別人的意見中得到反饋，從而在視覺方面做得更好。然而，如果忽略高保真的模型和原型，僅僅把釋出產品的實際使用效果歸功於設計，而不是一些令人驚歎的個人作品，我們還能做好這種設計工作嗎？
我並不是建議停止做那些美妙的，畫素完美的工作。我追求完美的強迫症源於 800 × 600 的顯示屏時代，在那個時候，最終產品就已經應該是完美的。
正如 Salesforce 設計團隊所說：
“以體貼優雅的工藝，表現對人們時間和注意力的尊重Demonstrate respect for people’s time and attention through thoughtful and elegant craftsmanship”
高保真的設計還可以讓我們測試一個真實的產品，驗證我們的假設，並確認可用性。但重要的是，我們不會浪費時間來建立一個能給客戶留下深刻印象，但卻不能實現的產品。
相反，關注一個現實的、可用的產品。
三、找到正確的節奏為了減少不必要的工作量，我們需要了解產品開發中發生的所有事情。
路線圖、待辦事項列表、下一步計劃開發的功能，以及開發人員在每個階段積極工作的內容。只是坐在外面，你就希望展現出團隊合作，以為你已經做完了，產品接著自然就會實現，這是沒有意義的。
對於一個產品團隊來說，將設計視為事後的考慮，或把它完全排除在外是很容易的，而且並不少見；作為設計師，我們希望創造性解決問題，利用我們的經驗和獲得的反饋來驗證正確的解決方案，我們不希望被告知“讓它好看就行”。
瞭解每一件正在發生的事情，並確保設計是產品開發和釋出週期中不可或缺的一部分，這不僅會幫助你的設計看到曙光，還會讓團隊的其他成員參與進來，這就引出了我的下一個觀點。
四、分享所有權如果你足夠幸運，能在產品剛推出的時候就參與進來，請確保你作為設計師的想法能讓每個人都瞭解。這將幫助團隊有歸屬感，並給他們提供貢獻的機會。
沒有人希望別人告訴你該做什麼，所以分享你的想法，並利用你的專業知識和經驗來推進貢獻。團隊會更希望交付一個集體的想法，這也將有助於每個人都保持一致。
你還會發現，當每個人都達成一致並向相同的目標努力時，團隊計程車氣會高漲。
五、關於程式碼工作多年來，設計人員是否應該編寫程式碼一直是一個熱門話題。
作為一個 UI 開發人員和 UI 設計人員，我可能有點偏見。我知道這是一種奢侈，學習如何編寫程式碼需要花費大量時間，但好處顯而易見。
對我來說，程式設計能力給了我在程式碼工作中表達想法的自由。
有時候不需要提交程式碼，或者程式碼水平粗糙而混亂，但這仍然鍛鍊了個人經驗，對產品實現邏輯有了深層理解，使後期減少對錯誤的解釋次數，以及由於不熟悉而試圖重新設計的時間。
如果設計人員不願意或者不能編寫程式碼，他們至少應該瞭解程式碼和平臺的基本原理。建築師在設計房子時，不會不考慮材料和周圍環境。
這對你最佳化工作什麼幫助？應該是顯而易見的。具備相關的程式碼能力將減少程式設計所需的工作。如果你瞭解開發產品的平臺或框架，就能夠在它們的約束下進行設計。
表單元件有按列過濾功能嗎？select 元件可以獲取資料嗎？還是所有選項都是預載入的？如果元件 X 與元件 Y 提供相同的使用者值，那麼哪個更容易實現？
一套可重用的元件可以節省大量時間，因此你對這些元件瞭解得越多，就越清楚如何定製它們來滿足需求。
你的設計離技術上可行的距離越遠，你就會浪費更多的精力來糾正它，開發人員也會浪費更多的精力來滿足你的設計要求和客戶的期望。
除此之外，在過去的幾年裡，我們設計和開發產品的方式發生了巨大的變化，動態設計規範、元件模式庫和新的設計工具使我們比以往任何時候都更有效率。
更好的技術知識，讓你現在可以真正提高團隊的操作效率，這是以前無法做到的，你還在等什麼？
六、總結總而言之，如果你想最佳化工作流程、想更有效的釋出產品，那麼遵循以下建議，你和你的開發人員都會減少不必要的工作量：
1. 理解向終端使用者交付產品價值所需要的最低限度（MVP）快速釋出、獲得反饋和驗證，持續少量更改比一次性發布大量未使用的功能要好。
2. 避免為了自己的利益而獨立工作，或者為了讓客戶和利益相關者“驚歎”如果你的工作不能轉化為真正的產品，或者不能幫助塑造真正的產品，那麼你的努力就白費了。你的目標是釋出一個可用的產品，而不僅僅是一個演示的片段。
3. 與產品開發團隊同步知道計劃了什麼，以及在每個階段將交付什麼，這樣就可以根據需要提供相應的工作成果。
4. 團隊合作讓每個人都參與到創意中來，用你的專業知識和經驗來指導和推動：大家會互相學習，每個人都會團結一致，專注於同一個目標。
5. 瞭解你設計的產品開發平臺和框架如果你不能編寫程式碼，那就儘可能地接近程式碼。最終產品和設計方案之間的差距越小，開發人員實現時，偏差就越少。
6. 與開發人員緊密合作建立或識別元件庫，並建立可重用的設計規範。這也將加強整個產品的一致性。
7. 擁抱先進的設計工具，最佳化你的工作流程原文作者：Billy D Stagg，UX/UI 設計師和開發人員，GROUP OF HUMANS 的設計合作伙伴
原文地址：https://uxdesign.cc/cutting-the-fat-from-product-design-5b01b28ff8ed
譯者：鵜小鶘，公眾號： 鵜鶘全面客戶體驗管理
本文由 @鵜小鶘 翻譯釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。