起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識原創分享：我的六大產品設計原則
原則一：不要讓用戶選擇
對于某一功能，首先考慮清楚設計的目標是什么：是想要讓用戶付費還是不付費？是想要用戶確認還是取消？是想要用戶前進還是返回？
當確定了這一流程的『理想化』走向時，就把產品本身或用戶所期待的那一個方向重點剝離出來，作為備用或與意愿違背的操作則盡量隱藏或弱化。
原則實例
某餐飲外賣第三方派送平臺，因為眾包的派送性質，現金支付使得資金難以管理，且安全性沒有保障，產品設計為只能接受在線支付（微信、支付寶等）?？紤]到可能會有很多用戶堅持或習慣使用現金支付，我在第一版本的設計時，給用戶端設置了兩個選項，分別是『立即支付』和『稍后支付』，前者對應的是無線支付，而后者則是指用戶在稍晚一些的時候再使用無線支付（當前可能支付不便），如果用戶選擇了『稍后支付』，則用戶在完成支付前無法進行新的下單和點餐。
但是仔細考慮之后就會發現，『稍后支付』完全是多余的一個操作，設計者只要給用戶留出『立即支付』的按鈕，而用戶由于各種原因無法支付時，只要關閉 App 或返回到其他頁面，就相當于是默認的『稍后支付』了。而當用戶想要進行新動作時，頁面又會回到這個支付頁面，提醒用戶完成之前未支付的訂單。
相似的設計還有嘀嘀、快的等打車產品，當當前網絡不佳或余額不足時，依然有很多司機允許乘客晚一些再進行付款。
原則二：在不造成新麻煩的前提下，解決任何一個小的舊麻煩，都是一種提升
想要解決一個用戶需求，往往有兩種手段，第一是從一個新角度完全創造一種新的流程和做法，第二則是對原有的模式進行優化更新。無論選擇哪一種，都應該明白，對原始模式的任何一點點提升，只要不造成新的麻煩，就都是可取的。
原則實例
某快遞刷卡簽單系統，采用員工或學生信息匹配，直接刷工卡來驗證身份，以替代原本手寫簽字的不穩定性和不方便性。
最初設計這個功能的時候，收到了很多反對和質疑的意見，包括工卡丟失怎么領取快遞、有人盜用他人工卡領取、增加了硬件和信息錄入的成本等。乍看一眼似乎這些都是潛在的問題，但是仔細考慮，和原始的手寫簽名相比，我們造成的便利更多，還是麻煩更多？
工卡丟失的情況下，依然可以使用手寫簽單的方式，這相當于回到原始做法；有人盜用他人工卡領取，反而可以根據攝像頭和刷卡信息確認盜領的時間和人員情況，相比原始模式下胡亂手寫、冒牌簽名等情況，反而更有利于管理；硬件成本可控，信息在獲取完全數據庫的前提下錄入并不復雜。
所有領過快遞的人都知道，簽單的時候自己寫下的字可能自己都不認得，冒領的風險不可避免。那么采用刷卡確認簽單的方式，也許是會存在一些問題，但是并沒有引入新的麻煩，同時又解決了想當多的問題，那么這種設計就是可取的。
原則三：盡可能地將面向用戶的流程精簡，采用相對煩瑣的技術或隱性流程來替代
最初設計產品的時候，總是會把整個流程給梳理出來，而這些流程往往又是混雜了用戶流程和產品自身流程——換言之，有很多東西用戶是不需要知道的。為了面向用戶的一側更加簡潔和可靠，更多的技術細節和流程都可以隱性地完成，或者使用技術復雜度來替代用戶流程復雜度，這都是劃算的。
原則實例
某社交產品，在進行發布狀態、評論狀態或點贊等動作時，無論當前網絡狀態是否通常，都可以直接反饋用戶已經完成或成功的信息，而不要拖累用戶陪系統一起等待數據傳輸或驗證等煩瑣的『產品自身流程』。這種做法可以極大低提升用戶體驗，給人一種快速、流暢的感覺，當然如果后續因為網絡等其他原因沒有操作成功，可以通過別的途徑再進行通知。
在我設計的第三方物流派送平臺中，任務發起者輸入訂單后，系統就將訂單推送給所有派送員進行搶單。如果此后發起者又輸入了某一個訂單，而這個訂單因為起始點接近，可以和另一個前續訂單進行合并，系統將會自動完成這個合并動作，并打包發送給派送員。這一系列的過程對于用戶來說，都是隱性的，但卻是方便和自然的。
原則四：快速上線、模式驗證、可用性測試都十分重要，不要立即花費大量的時間做開發與設計，而應該落腳到產品的根本
這是最近最大的一個收獲和心得。尤其對于產品經理來說，很多需求和模式可能在前期都無法得到百分百的確定，某一個產品的實際效果真的之后上線推廣測試之后才能有真實的反饋，再進行調整和迭代。對于這樣的情況，請使用所有傳統、粗劣、暴力的方式盡快將新模式或新功能推到線上測試，獲取模式驗證的反饋。與之相對的，不要在前期花費大量的時間去做開發和設計，一旦模式驗證不通過，這些工作很可能會白費。
原則實例
第三方眾包派送在國外已有成功案例，但是在國內或者某些特定的細分市場中（如 CBD 商圈或高校市場）卻不一定有現成的例子可供參考。對于這樣的新模式，光靠調研和論證很難得到確切的反饋。因此在產品設計初期，應當直接使用紙筆記錄、短信電話通知、雇傭全職派送人員等來模擬整個產品過程，以期獲取第一手的可用性測試資料。如果模式驗證可行性較高，再投入資源進行開發設計，反之則盡快調整產品方向。
倘若前期直接投入大量資源打造產品，希望憑借一個完成品去測試，成本真的過于高昂。
原則五：設計者本身往往不是典型用戶，不要對自己的認知和設計過份認同，也不要立即對別人的意見提出反對
我認為產品經理入門的第一個要點就是認清：自己不是典型用戶。你認為這是需求，這未必是真正的用戶需求；我認為不需要這個功能，也不代表沒有人需要這個功能。剛開始接觸產品的時候，喜歡固執己見，在聽到別人的創意時，第一時間都是去尋找各種各樣的反駁的理由。但是在有了一定的經驗和閱歷之后，我們常常發現自己的感覺往往是不準確的，而產品經理的一大職責，就是采用各種用研手段去論證這個需求是否真實存在。
原則實例
最初做物流集散中心項目時，我根據幾個盈利點分析，認為這個項目基本不可能盈利。但實際上當你壟斷了一個區域的所有快遞之后，就會有足夠多的之前沒有想到過的盈利點出現。如果現在世界上沒有『快遞』這個行業，讓我第一個去做，我依然可能會認為這種人工成本高昂的模式難以盈利，但事實早已證明了一切。
原則六：考慮所有極限情況，這包含在功能邏輯、視覺設計、交互設計的每一個環節
極限情況有助于完善產品的方方面面。無論是功能邏輯上（超高并發量、或初期零基礎用戶階段），還是視覺設計上（空白內容頁的展示、大量內容的處理），或是交互設計上（斷網、系統卡死反饋），都需要考慮每一個極限情況。
原則實例
某拼車產品，對于這樣多用戶協同的需求，基礎用戶數量就非常重要，試想如果前期只有零星的幾個用戶在使用產品，勢必難以在段時間內達成自己拼車的目標，同樣的情況海輝發生在論壇社區、二手市場等產品中。
對應的解決方案可以是發起落地活動，段時間內引入大量種子用戶，或者采取運營手段投放一些『托』用戶，以激活整個產品模式與流程。
本文系作者 @窒息紅Leon投稿發布，轉載請注明來源于人人都是產品經理，并保留本文鏈接 。
不錯