資 訊
產品設計的質量和體驗的好壞直接影響工業設計公司的發展 | FROM ZERO TO ONE
- 來 源:深圳工業設計公司網
- 發 表 于:2020-10-21
- 作 者:101工業設計
- 人 氣:13004
產品設計的質量和體驗的好壞直接影響工業設計公司的發展
我們從草圖到線框圖,為關鍵的用戶旅程勾勒出流程步驟,設計 UI 組件以及詳細的規范,甚至有原型來演示我們想要的
產品實現方式。
我們已經去客戶那里測試設計,收到了很好的反饋,一切似乎都朝著正確的方向發展。
只有一個問題:我們至此還沒有任何可以發布的產品,而我們設計的產品和我們能做出來的產品之間相差了十萬八千里。
上述問題并不少見,我們一次又一次看到設計方案沒有實現,或者與預期的設計和體驗相去甚遠。
這對于探索或概念驗證一類的工作來說是很好的,但在快速發展的行業中,我們需要快速而頻繁的發布產品,以保持在
競爭中的領先地位。
在過去的幾年里,為了改進產品開發過程,我調整了我的流程,并想分享一些關鍵的變化,希望這些變化也能幫助你和
你的團隊。
一、MVP:不止是說說而已
你可能聽過無數次“我們需要一個 MVP(Minimum Viable Product,最小可行性產品)”,但這不應該只是一個流行
詞。
如果你完全理解如何實現一個可接受的 MVP,就可以幫助團隊把精力集中在發布上。為了快速發布,團隊必須愿意發布
最基本的產品。
這對于客戶和利益相關者來說是非常困難的,因為他們往往為所有特性和功能做預算,并預期最終得到功能齊全的產品。
但是先發布 MVP 的好處是顯而易見的。
你發布的速度越快,就能把產品越快投向用戶,獲得有價值的反饋,并給你帶來意想不到的見解。而且,越早開始獲取
用戶,你的用戶群就越快開始增長;在幾個月的用戶增長之后,你就會領先了。
你需要接受的是,MVP 可能沒有那么快的競爭力,但也不需要立即進行大規模營銷。關鍵是盡快發布,為持續的增量改
進鋪平道路,從而為用戶提供不斷增長的價值。
Slack 是一個很好的例子,它依賴于用戶的反饋來幫助塑造產品。在沒有首席營銷官(CMO)和大眾營銷活動的情況
下,他們通過傾聽用戶意見,逐步改進產品,贏得了用戶的心。
二、打破幻想
作為設計創意人員個人,我們常常希望獨立工作,很少考慮我們無法控制的事情。
我們關心的是交付的成果,只要它們有效并且看起來很棒,我們就完成了工作。如果最終發布的產品看起來或感覺不像
我們的設計,那不是我們的錯,對吧?
事實上,人類是情感動物,視覺刺激更能說明問題。酷炫的界面更能讓客戶驚嘆,并留下持久的印象。
作為創造者,我們也從別人的意見中得到反饋,從而在視覺方面做得更好。然而,如果忽略高保真的模型和原型,僅僅
把發布產品的實際使用效果歸功于設計,而不是一些令人驚嘆的個人作品,我們還能做好這種設計工作嗎?
我并不是建議停止做那些美妙的,像素完美的工作。我追求完美的強迫癥源于 800 × 600 的顯示屏時代,在那個時候,
最終產品就已經應該是完美的。
正如 Salesforce 設計團隊所說:
“以體貼優雅的工藝,表現對人們時間和注意力的尊重
高保真的設計還可以讓我們測試一個真實的產品,驗證我們的假設,并確認可用性。但重要的是,我們不會浪費時間來
創建一個能給客戶留下深刻印象,但卻不能實現的產品。
相反,關注一個現實的、可用的產品。
三、找到正確的節奏
為了減少不必要的工作量,我們需要了解產品開發中發生的所有事情。
路線圖、待辦事項列表、下一步計劃開發的功能,以及開發人員在每個階段積極工作的內容。只是坐在外面,你就希望
展現出團隊合作,以為你已經做完了,產品接著自然就會實現,這是沒有意義的。
對于一個產品團隊來說,將設計視為事后的考慮,或把它完全排除在外是很容易的,而且并不少見;作為設計師,我們
希望創造性解決問題,利用我們的經驗和獲得的反饋來驗證正確的解決方案,我們不希望被告知“讓它好看就行”。
了解每一件正在發生的事情,并確保設計是產品開發和發布周期中不可或缺的一部分,這不僅會幫助你的設計看到曙
光,還會讓團隊的其他成員參與進來,這就引出了我的下一個觀點。
四、分享所有權
如果你足夠幸運,能在產品剛推出的時候就參與進來,請確保你作為設計師的想法能讓每個人都了解。這將幫助團隊
有歸屬感,并給他們提供貢獻的機會。
沒有人希望別人告訴你該做什么,所以分享你的想法,并利用你的專業知識和經驗來推進貢獻。團隊會更希望交付一
個集體的想法,這也將有助于每個人都保持一致。
你還會發現,當每個人都達成一致并向相同的目標努力時,團隊的士氣會高漲。
五、關于代碼工作
多年來,設計人員是否應該編寫代碼一直是一個熱門話題。
作為一個 UI 開發人員和 UI 設計人員,我可能有點偏見。我知道這是一種奢侈,學習如何編寫代碼需要花費大量時間,
但好處顯而易見。
對我來說,編程能力給了我在代碼工作中表達想法的自由。
有時候不需要提交代碼,或者代碼水平粗糙而混亂,但這仍然鍛煉了個人經驗,對產品實現邏輯有了深層理解,使后期
減少對錯誤的解釋次數,以及由于不熟悉而試圖重新設計的時間。
如果設計人員不愿意或者不能編寫代碼,他們至少應該了解代碼和平臺的基本原理。建筑師在設計房子時,不會不考慮
材料和周圍環境。
這對你優化工作什么幫助?應該是顯而易見的。具備相關的代碼能力將減少編程所需的工作。如果你了解開發產品的平
臺或框架,就能夠在它們的約束下進行設計。
表單組件有按列過濾功能嗎?select 組件可以獲取數據嗎?還是所有選項都是預加載的?如果組件 X 與組件 Y 提供相
同的用戶值,那么哪個更容易實現?
一套可重用的組件可以節省大量時間,因此你對這些組件了解得越多,就越清楚如何定制它們來滿足需求。
你的設計離技術上可行的距離越遠,你就會浪費更多的精力來糾正它,開發人員也會浪費更多的精力來滿足你的設計要
求和客戶的期望。
除此之外,在過去的幾年里,我們設計和開發產品的方式發生了巨大的變化,動態設計規范、組件模式庫和新的設計工
具使我們比以往任何時候都更有效率。
更好的技術知識,讓你現在可以真正提高團隊的操作效率,這是以前無法做到的,你還在等什么?
六、總結
總而言之,如果你想優化工作流程、想更有效的發布產品,那么遵循以下建議,你和你的開發人員都會減少不必要的工
作量:
1. 理解向最終用戶交付產品價值所需要的最低限度(MVP)
快速發布、獲得反饋和驗證,持續少量更改比一次性發布大量未使用的功能要好。
2. 避免為了自己的利益而獨立工作,或者為了讓客戶和利益相關者“驚嘆”
如果你的工作不能轉化為真正的產品,或者不能幫助塑造真正的產品,那么你的努力就白費了。你的目標是發布一個可
用的產品,而不僅僅是一個演示的片段。
3. 與產品開發團隊同步
知道計劃了什么,以及在每個階段將交付什么,這樣就可以根據需要提供相應的工作成果。
4. 團隊合作
讓每個人都參與到創意中來,用你的專業知識和經驗來指導和推動:大家會互相學習,每個人都會團結一致,專注于同
一個目標。
5. 了解你設計的產品開發平臺和框架
如果你不能編寫代碼,那就盡可能地接近代碼。最終產品和設計方案之間的差距越小,開發人員實現時,偏差就越少。
6. 與開發人員緊密合作
建立或識別組件庫,并創建可重用的設計規范。這也將加強整個產品的一致性。
7. 擁抱先進的設計工具,優化你的工作流程