產品設計的質量和體驗的好壞直接影響工業(yè)設計公司的發(fā)展

我們從草圖到線框圖，為關鍵的用戶旅程勾勒出流程步驟，設計 UI 組件以及詳細的規(guī)范，甚至有原型來演示我們想要的

產品實現(xiàn)方式。

我們已經(jīng)去客戶那里測試設計，收到了很好的反饋，一切似乎都朝著正確的方向發(fā)展。

只有一個問題：我們至此還沒有任何可以發(fā)布的產品，而我們設計的產品和我們能做出來的產品之間相差了十萬八千里。

上述問題并不少見，我們一次又一次看到設計方案沒有實現(xiàn)，或者與預期的設計和體驗相去甚遠。

這對于探索或概念驗證一類的工作來說是很好的，但在快速發(fā)展的行業(yè)中，我們需要快速而頻繁的發(fā)布產品，以保持在

競爭中的領先地位。

在過去的幾年里，為了改進產品開發(fā)過程，我調整了我的流程，并想分享一些關鍵的變化，希望這些變化也能幫助你和

你的團隊。

一、MVP：不止是說說而已

你可能聽過無數(shù)次“我們需要一個 MVP（Minimum Viable Product，最小可行性產品）”，但這不應該只是一個流行

詞。

如果你完全理解如何實現(xiàn)一個可接受的 MVP，就可以幫助團隊把精力集中在發(fā)布上。為了快速發(fā)布，團隊必須愿意發(fā)布

最基本的產品。

這對于客戶和利益相關者來說是非常困難的，因為他們往往為所有特性和功能做預算，并預期最終得到功能齊全的產品。

但是先發(fā)布 MVP 的好處是顯而易見的。

你發(fā)布的速度越快，就能把產品越快投向用戶，獲得有價值的反饋，并給你帶來意想不到的見解。而且，越早開始獲取

用戶，你的用戶群就越快開始增長；在幾個月的用戶增長之后，你就會領先了。

你需要接受的是，MVP 可能沒有那么快的競爭力，但也不需要立即進行大規(guī)模營銷。關鍵是盡快發(fā)布，為持續(xù)的增量改

進鋪平道路，從而為用戶提供不斷增長的價值。

Slack 是一個很好的例子，它依賴于用戶的反饋來幫助塑造產品。在沒有首席營銷官（CMO）和大眾營銷活動的情況

下，他們通過傾聽用戶意見，逐步改進產品，贏得了用戶的心。

二、打破幻想

作為設計創(chuàng)意人員個人，我們常常希望獨立工作，很少考慮我們無法控制的事情。

我們關心的是交付的成果，只要它們有效并且看起來很棒，我們就完成了工作。如果最終發(fā)布的產品看起來或感覺不像

我們的設計，那不是我們的錯，對吧？

事實上，人類是情感動物，視覺刺激更能說明問題?？犰诺慕缑娓茏尶蛻趔@嘆，并留下持久的印象。

作為創(chuàng)造者，我們也從別人的意見中得到反饋，從而在視覺方面做得更好。然而，如果忽略高保真的模型和原型，僅僅

把發(fā)布產品的實際使用效果歸功于設計，而不是一些令人驚嘆的個人作品，我們還能做好這種設計工作嗎？

我并不是建議停止做那些美妙的，像素完美的工作。我追求完美的強迫癥源于 800 × 600 的顯示屏時代，在那個時候，

最終產品就已經(jīng)應該是完美的。

正如 Salesforce 設計團隊所說：

“以體貼優(yōu)雅的工藝，表現(xiàn)對人們時間和注意力的尊重

高保真的設計還可以讓我們測試一個真實的產品，驗證我們的假設，并確認可用性。但重要的是，我們不會浪費時間來

創(chuàng)建一個能給客戶留下深刻印象，但卻不能實現(xiàn)的產品。

相反，關注一個現(xiàn)實的、可用的產品。

三、找到正確的節(jié)奏

為了減少不必要的工作量，我們需要了解產品開發(fā)中發(fā)生的所有事情。

路線圖、待辦事項列表、下一步計劃開發(fā)的功能，以及開發(fā)人員在每個階段積極工作的內容。只是坐在外面，你就希望

展現(xiàn)出團隊合作，以為你已經(jīng)做完了，產品接著自然就會實現(xiàn)，這是沒有意義的。

對于一個產品團隊來說，將設計視為事后的考慮，或把它完全排除在外是很容易的，而且并不少見；作為設計師，我們

希望創(chuàng)造性解決問題，利用我們的經(jīng)驗和獲得的反饋來驗證正確的解決方案，我們不希望被告知“讓它好看就行”。

了解每一件正在發(fā)生的事情，并確保設計是產品開發(fā)和發(fā)布周期中不可或缺的一部分，這不僅會幫助你的設計看到曙

光，還會讓團隊的其他成員參與進來，這就引出了我的下一個觀點。

四、分享所有權

如果你足夠幸運，能在產品剛推出的時候就參與進來，請確保你作為設計師的想法能讓每個人都了解。這將幫助團隊

有歸屬感，并給他們提供貢獻的機會。

沒有人希望別人告訴你該做什么，所以分享你的想法，并利用你的專業(yè)知識和經(jīng)驗來推進貢獻。團隊會更希望交付一

個集體的想法，這也將有助于每個人都保持一致。

你還會發(fā)現(xiàn)，當每個人都達成一致并向相同的目標努力時，團隊的士氣會高漲。

五、關于代碼工作

多年來，設計人員是否應該編寫代碼一直是一個熱門話題。

作為一個 UI 開發(fā)人員和 UI 設計人員，我可能有點偏見。我知道這是一種奢侈，學習如何編寫代碼需要花費大量時間，

但好處顯而易見。

對我來說，編程能力給了我在代碼工作中表達想法的自由。

有時候不需要提交代碼，或者代碼水平粗糙而混亂，但這仍然鍛煉了個人經(jīng)驗，對產品實現(xiàn)邏輯有了深層理解，使后期

減少對錯誤的解釋次數(shù)，以及由于不熟悉而試圖重新設計的時間。

如果設計人員不愿意或者不能編寫代碼，他們至少應該了解代碼和平臺的基本原理。建筑師在設計房子時，不會不考慮

材料和周圍環(huán)境。

這對你優(yōu)化工作什么幫助？應該是顯而易見的。具備相關的代碼能力將減少編程所需的工作。如果你了解開發(fā)產品的平

臺或框架，就能夠在它們的約束下進行設計。

表單組件有按列過濾功能嗎？select 組件可以獲取數(shù)據(jù)嗎？還是所有選項都是預加載的？如果組件 X 與組件 Y 提供相

同的用戶值，那么哪個更容易實現(xiàn)？

一套可重用的組件可以節(jié)省大量時間，因此你對這些組件了解得越多，就越清楚如何定制它們來滿足需求。

你的設計離技術上可行的距離越遠，你就會浪費更多的精力來糾正它，開發(fā)人員也會浪費更多的精力來滿足你的設計要

求和客戶的期望。

除此之外，在過去的幾年里，我們設計和開發(fā)產品的方式發(fā)生了巨大的變化，動態(tài)設計規(guī)范、組件模式庫和新的設計工

具使我們比以往任何時候都更有效率。

更好的技術知識，讓你現(xiàn)在可以真正提高團隊的操作效率，這是以前無法做到的，你還在等什么？

六、總結

總而言之，如果你想優(yōu)化工作流程、想更有效的發(fā)布產品，那么遵循以下建議，你和你的開發(fā)人員都會減少不必要的工

作量：

1. 理解向最終用戶交付產品價值所需要的最低限度（MVP）

快速發(fā)布、獲得反饋和驗證，持續(xù)少量更改比一次性發(fā)布大量未使用的功能要好。

2. 避免為了自己的利益而獨立工作，或者為了讓客戶和利益相關者“驚嘆”

如果你的工作不能轉化為真正的產品，或者不能幫助塑造真正的產品，那么你的努力就白費了。你的目標是發(fā)布一個可

用的產品，而不僅僅是一個演示的片段。

3. 與產品開發(fā)團隊同步

知道計劃了什么，以及在每個階段將交付什么，這樣就可以根據(jù)需要提供相應的工作成果。

4. 團隊合作

讓每個人都參與到創(chuàng)意中來，用你的專業(yè)知識和經(jīng)驗來指導和推動：大家會互相學習，每個人都會團結一致，專注于同

一個目標。

5. 了解你設計的產品開發(fā)平臺和框架

如果你不能編寫代碼，那就盡可能地接近代碼。最終產品和設計方案之間的差距越小，開發(fā)人員實現(xiàn)時，偏差就越少。

6. 與開發(fā)人員緊密合作

建立或識別組件庫，并創(chuàng)建可重用的設計規(guī)范。這也將加強整個產品的一致性。

7. 擁抱先進的設計工具，優(yōu)化你的工作流程