樸素產品法(上)
編輯導語:在做產品設計規劃時,你是否會有所疑惑:某個功能是應該保留還是去除,要如何才能給用戶更準確、高效地傳遞信息,提升用戶的產品使用體驗?本篇文章里,作者介紹了“樸素產品法”,也許能為你解決困惑。
樸素產品,只做現階段需要的內容,能少則省,只傳達有效信息,不附帶干擾。
產品設計規劃時經常會面臨諸如“功能完整與拆分迭代,縮短路徑與加層跳轉,簡潔排布與充分利用”之間的矛盾,而這系列矛盾也不是簡單的非此即彼,相互關聯而又相互制衡。
- 拆分迭代更有利于產品驗證,而產品的最終目標還是演化至趨于完整,只是階段不同,追求完整還不算是一個最主要的內容;
- 減少操作次數,縮短行為路徑是一個至關重要的設計理念,但也需要兼顧頁面內容元素,一個頁面只傳遞一個核心信息,一個頁面只有一個視覺焦點,在秉承這一核心要求的前提下,有時增多層級跳轉反而是一個更合理的選擇;
- 頁面簡潔不等于簡單、元素少,而是傳遞信息的直接有效,更需要考慮的是用戶在頁面所保留的注意力,在保持有高注意力的頁面一次性展示更多內容,更有利于增強產品可用性,提高使用效率。
產品設計規劃時常就是一個進退兩難,不斷抉擇的復雜過程,需要時刻秉承著追求“樸素”的心態,適可而止,效用為先。
樸素功能選型
“如無必要,勿增實體”,簡單有效原理。
大多數情況下我們也都知道要注意保持簡單易用,而經常遇到的是一開始就已經將問題復雜化,容易只從充分性的角度來考慮,導致忽略了需求的必要性,也就很可能導致需求蔓延和鍍金需求的增多。過于追求“細枝末節”,過于執著“用戶體驗”,有時更需要保持“有限理性”,適可而止。
確定階段性功能,定義功能方向及階段系統邊界,形成階段性聚焦,適當放棄部分現階段暫時還無需關注的內容。
1. 定義最需解決問題
用戶所面臨的問題大多數情況下都是多方面的,期待的解決方案也可能是最理想化的,此時需要尋找出最需解決的問題,集中力量資源解決核心問題,更高效精準地取得用戶滿意。如果解決了這個問題,用戶的處境就會有最大程度的改變,這就是用戶現階段最需解決的問題。
同時考慮哪些限制條件會影響到用戶的流程環節過渡,是否存在可保留的舊體驗,從而確定當前版本的系統功能邊界。拆分出終級效果和階段性目標,可降低問題處理復雜度。
案例:對于線下門店優惠券派發線上化,目的是想通過電子化更便捷地派發,分析衡量出不同優惠券的具體效果,更科學地實現降本增效。
面對這一目標我們很容易一開始就陷入如何精準地做出效果評估,“推送-曝光-查看-使用”等環節的流程轉化,通過費效比分析得出哪種券類型、券組合表現更優,但這在一定程度上只是彌補了線下記錄操作繁瑣,數據記錄不全的的缺陷,是在維持原有或改變不大的派發效果基礎上進行的分析,側重于事后的后見性分析。
容易忽視了推送的前一步,優惠券以及推送機制的設計,而線上化帶來的用戶精細行為數據采集更有利于該方面內容的驗證,發掘不同優惠券形式對用戶觸達和轉化的影響,哪些元素更有利于拉新促活,這是在全局推送前需要率先驗證的問題,包括配圖呈現,文案擬定,產品亮點,推送時機等等。
精準的流量以及承接該批流量的產品觸發點,面對降本增效這一整體目標,在初始階段,提高整體發放消息的點擊轉化率更能達到增效的目的,而不是在原本還未達到“最優”中強行擇優,需要同時兼顧事前事中事后的全環節管理流程。
2. 尋找最簡解決方案
在明確了現階段最需解決的問題之后,依然會面臨諸多不確定因素,需實行最小可行產品形態推進驗證,尋找最簡解決方案,減少投入成本的沉沒流失,加快產品的落地使用、市場占有。
簡化產品方案思考框架
- 不做這一步會有什么后果?
- 如果不這么做都是怎么做?
- 別人沒按照你的意思去做,反而采用了其他方式,會有什么效果?
- 如果按照所說的去做了,效果不好,大概率是哪個環節出了問題?
(借用自《得到品控手冊7.0》得到主編采訪課程專欄老師完善內容質量的問題技巧框架)
案例:對于線上商超便利店平臺初期推廣階段,重點在于驗證平臺是否能擁有預期用戶流量,需快速招攬店家入駐完成驗證。商品上架作為線上開店不可或缺的功能,涉及掃碼識別、規格價格設置、商品分類管理、商品描述等多個方面,且不同子模塊間相互關聯難以精減,如果初期壓根就沒有商品上架功能呢?
1)不做這一步會有什么后果?
店家不可手動自主上架商品,全部調用平臺商品庫商品,店家僅可售賣常見商品,非常見非標商品暫不支持售賣。店家上架自家特有商品是為能體現出自家商品種類齊全,與周邊商家的差異化,提供配送上門服務更好服務于周邊客戶。
① 對于前期階段,一定區域內不會出現太多的試點店家,商品的差異化競爭因素可暫不考慮。
② 盡管商品沒有上架完全,但對于以服務老客為主的零售便利店而言(主要推廣方式以客戶到店后再向其介紹線上訂單服務),前期客戶如有其它需求,可在訂單中進行備注說明,盡管會造成銷售庫存數據不同步,但小需求商品可先由人工校對調整。
2)如果不這么做都是怎么做?
平臺商品庫商品需要足夠常見,適用于大多數店鋪,在挑選種子樣板店時需考慮經營業態、在售商品相似度較大的店鋪,使能夠涵蓋店家的大多數商品,對于銷量不大的長尾商品進行適當壓縮,對于存在太多需要計量的非標商品店家可暫不考慮。
3)別人沒按照你的意思去做,反而采用了其他方式,會有什么效果?
新平臺初期為吸引店家,基本都是免費邀請或補貼入駐,而對商家而言是獲得了一個新的訂單來源途徑,有勝于無。
重點在于不能有太大的入駐門檻,店家不愿意為一個不確定的銷售渠道投入太多精力資源。上架商品對店家而言就是一個繁瑣的大工程,除非對平臺有足夠的引流信任,否則不會輕易就有商品上架意愿。在前期平臺還無法取得店家信任時,降低門檻就變得至關重要,從這一方面來看直接商品庫上架反而更有利于推廣。
4)如果按照所說的去做了,效果不好,大概率是哪個環節出了問題?
假設按照以上做法推進,也可能因為該方案引出一些新的問題導致引流轉化效果不理想、流量驗證不準確。例如商品品類不夠豐富、商品描述不準確、采用全平臺統一但同一商品在不同店家間會存在質量差別等,需要有預留地進行調研驗證。
小結
尋找最簡解決方案目的在于以最低成本盡快測試想法,關鍵是驗證需求是否有普遍性,能否引起用戶共鳴,需要驗證的風險是“用戶會來我們平臺上下單嗎”而不是“我們如何做出一個線上下單平臺”。明確哪些舊體驗可以在初代版本中保留,哪些流程操作可以先由人工替代,采用專人接待式服務模式等。
追求簡單的另一方面還在于避免因為某一功能的投入而引發出了其他新的關聯需求。做不做一個功能,除了考慮現在所需花費的成本資源,還需要考慮可能激發出來的新需求,避免打開“潘多拉魔盒”必須持續投入資源不停增加。
3. 兼顧拓展遷移成本
早期系統除了考慮簡化產品解決方案外,還需要兼顧后續拓展可能性,可拓展一方面是保持系統底層結構的可復用,避免重構,另一方面是避免由于拓展造成過大的遷移成本導致用戶流失。
案例:針對客戶標簽體系,前期就需要能夠對標簽數量級有一個預估,是否需要一開始就支持創建標簽組,前期系統剛投入使用,不支持分組管理對用戶不會有太大影響。
但到了后期隨著標簽數量的增多,標簽管理、查找就會變得繁瑣,此時就會要求對標簽進行分組。
如果前期未能考慮到該擴展的可能性,此時再增加分組功能,就會導致整個標簽的數據表結構發生較大變動,用戶已創建的標簽需手動遷移至新創建分組內,額外操作的工作量太大會讓用戶產生抗拒心理,即使很清楚分組后后續使用會更加方便,但過大的操作壓力可能會導致用戶猶豫不決,最終選擇放棄使用系統。
4. 分支下鉆延伸迭代
完成核心驗證,明晰了產品大體方向,后續演化迭代就是一個又一個“構建-衡量-學習”循環的過程。迭代重點在于只聚焦于核心模塊的下鉆延伸,不致于產品邊界過于模糊擴散導致功能越積越多,但對產品價值沒有太多實質性的提升。
爬山算法,增加高度/值方向上的連續移動,以找到山峰或最佳解決方案的方法。這一模型多運用于算法工程,但也同樣適用于產品的迭代思路,分支下鉆、精益求精,而不是去創建更多的分支。
通過一點點改變某個變量,改動之后如果得到更好的解決方案,就再從這一新方案中再選擇一個變量進行小幅改變,不斷反復,直到解決方案無法進一步優化為止。
優化一個指標獲得的成效越來越小,就意味著達到了一個基準點,再去優化下一個重要指標。
案例:假設消息推送是某APP訂單轉化的重要來源方式,現通過驗證已經得出某一時間點是一天中的最佳推送時機,push點擊率達到最高。接下來除了調整消息推送時間外,還需要進步驗證該時間段內高點擊率消息內容是否具有一定的相似性,內容類型是否有改善的空間;點擊用戶是否具有獨特的人群化特性或具有相似的用戶行為,激活了非活躍用戶還是持續觸活了活躍用戶等等。
持續提升改善現有的已證明重要的訂單來源方式轉化效果,而不是嘗試拓展具有高不確定性的新訂單產生途徑,提高做對事情的概率。
5. 小結
不只是產品從0到1要秉承最小可行原則,追求樸素,在任何時期的迭代落地都要遵從該理念,如無必要,勿增實體,保持有限理性,在一個更小、更容易觸及的目標市場、特定場景中持續培養更多具有黏性的高活躍用戶。
作者:完結,游走B端嘗試toC產品人;尋找復雜問題簡單化處理思路方式;“數據人創作者聯盟”成員。
本文由@一個數據人的自留地 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議。
- 目前還沒評論,等你發揮!