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