用「系統思維」指導產品設計
文章介紹系統思維的三個公式,希望他對你的產品設計工作有所幫助。
什么是系統思維?
系統思維和線性思維經常被一起討論、比較。線性思維比較容易理解,即:頭疼醫頭、腳疼醫腳。餓了就吃東西,渴了就喝水,困了就睡覺。而系統思維確是另一種大相徑庭的思維方式。
以下是百度百科對系統思維的定義:
系統思維是原則性與靈活性有機結合的基本思維方式。只有系統思維,才能抓住整體,抓住要害,才能不失原則地采取靈活有效的方法處置事務??陀^事物是多方面相互聯系、發展變化的有機整體。
系統思維,簡單來說就是對事情全面思考,不只就事論事。是把想要達到的結果、實現該結果的過程、過程優化以及對未來的影響等一系列問題作為一個整體系統進行研究。
所以系統思維的結果可能是“頭疼醫腳,腳疼醫頭”,因為人的身體是一個系統,而治療也要按照系統的角度來進行。 當我們進一步剖析系統思維時,我們可以發現如下三個公式:
- 公式一:系統=系統整體目標+元素+元素間關系
- 公式二:達成目標效率:共識目標>間接刺激>直接刺激
- 公式三:系統升級方法:正反饋&負反饋
當筆者發現這些公式后,便認為其可以指導產品經理們進行產品設計,以下嘗試舉例說明。
播放歷史的產品設計
公式一:系統=系統整體目標+元素+元素間關系
由公式一可知,當從系統思維考慮一個問題時,需要考慮三個問題,即:系統整體目標、元素及元素間關系。那下面以視頻客戶端的一個基礎功能“播放歷史”為例,來講解系統思維該如何應用。
首先,我們需要知道系統整體目標。針對某個問題,我們可以很概括的給出答案,比如“滿足用戶需求”、“滿足商業價值”等,當具體到某個問題時,更多的是關注某種體驗或者某個/些數據,而播放歷史最大的需求之一就是:將完整且準確的播放記錄在多端間及時同步(用了好幾個定語,建議再讀一次)。
現在我們看下用戶的一個比較常規且高頻的操作流程是:
這個大體流程可以描述為:用戶打開APP瀏覽劇集信息,當點擊播放時涉及到播放器模塊,同時涉及到賬戶模塊和播放歷史模塊,因為要檢查當前用戶是否觀看過當前被選擇劇集,如果涉及的話,便會請求數據庫(云端或者本地),而此時涉及到系統的網絡服務模。這中間省略了很多細節步驟,但是基本可以看出該系統所包含各個元素。舉例如下:
- 劇集信息展示模塊
- 播放器模塊
- 播放歷史模塊
- 賬戶模塊
- 網絡模塊
- 云端模塊
當把以上各個元素的狀態改變,這個元素與其他元素的關系就會改變,比如從支持元素變為阻礙元素,從無關元素變成有關元素,從上游元素變為下游元素,而這個改變就是在增加case,case越多,產品設計完整的概率越高。單個元素的狀態舉例如下:
- 劇集信息展示模塊:展示多少、如何分類、如何展示……
- 播放器模塊:什么時候獲取播放記錄、前置條件是什么、記錄/獲取播放歷史時機……
- 播放歷史模塊:記錄/傳輸播放歷史時機、與賬戶登錄狀態關系、有網無網處理機制……
- 賬戶模塊:如何與播放歷史數據關聯、如何與劇集信息展示模塊關聯……
- 網絡模塊:網絡類型切換(4G/WiFi)、有網無網弱網狀態……
- 云端模塊:播放歷史與賬戶關系、播放歷史存儲機制、播放歷史的多端記錄合并機制……
而元素狀態變化導致的元素間關系變化舉例如下:
- 沒有網絡時,用戶播放已下載視頻,播放歷史要如何存儲數據?而此時用戶是否登錄,對該流程是否有影響?
- 當用戶從未登錄變成已登錄,播放歷史該如何處理?
- 當云端收到同一個用戶來自iPad、iPhone的播放歷史數據,該按照什么標準如何處理?
- ……
所以當系統的目標已確定,通過梳理主流程找出系統元素,通過改變元素間的關系便基本上可以枚舉出各種case,然后針對不同case給出產品的設計方案,這就是在系統思維指導下的產品設計。
播放歷史的項目安排
當產品設計方案已經就位,下一步就是和大家過方案,然后確定各類資源排期,進入開發測試上線。但是這個過程不是所有產品都能走順的,有些產品在和大家一起討論方案的過程中,除了爭吵就是互懟,項目推進艱難,那么我們如何用系統思維來解決這個問題哪?此時就需要考慮公式二:
公式二:達成目標效率:共識目標>間接刺激>直接刺激
公式已經寫明在一個系統中,各個方法達成目標效率的高低,針對不同效率分別從產品經理的角度舉例說明,方便大家理解。
直接刺激:某開發,我要做個播放記錄的多端同步,需求都寫好了,你看下吧,這個別人家都做好了,我看挺簡單的,我都調研了,趕緊做吧。
間接刺激:某開發,最近某酷做了一個功能,挺好的,叫播放歷史多端同步,我用起來挺方便的,你看看我寫的這個需求文檔,評估下,有不行的隨時討論。對了,昨天我看App Store上還有用戶留言給這個功能好評,我們也得抓緊了。
共識目標:某開發,我最近想到一個場景,你看看你是不是也遇到過,比如說我在家用iPad看視頻,然后早上在地鐵上想繼續看,現在找上次看到那很麻煩,我們是不是可以記錄這個進度(此處需要確認過眼神),我現在看了下市面上的競品,還真有做的,但是我感覺我們能做的更好,你看啊,這個是我的方案,(此處需要再次確認過眼神),競品做的……我們可以……
如果你是那個開發,你聽了上面三個表述,那個更能激發你的開發欲望?是不是共識目標更好一些,因為這個時候大家是在一條船上的,我們的目標都是到達彼岸,所以我們需要共同努力,我們需要共同討論出更好的方案。而這方式在跨部門溝通時同樣有效,雖然各個部門目標不一致,但是公司的目標是一致的。
播放歷史的數據分析
產品設計永遠沒有最好,只有更好,那么如何用系統思維來讓自己的產品設計更好哪?這就涉及到我們的第三個公式:
公式三:系統升級方法:正反饋&負反饋
在我們產品上線后,最好的反饋除用戶在App Store上留言、APP內的反饋等,就是數據,尤其是APP的核心數據的變化。
我們繼續以播放歷史為例,該功能上線后,用戶對進度條的拖拽操作明顯減少了,這說明什么?說明用戶之前在選擇劇集后尋找進度的操作別你的功能給簡化了,所以減少(其他功能和性能不便的前提下)。這就是對該功能正向的反饋,證明用戶需要這個功能,我們應該在這個功能上繼續去探索如果做到更好。
如果上線后,因為通過云端同步播放歷史,而使得云端壓力變大,導致讀取數據很慢,或者嚴重一些的說,導致正常視頻播放變卡頓(這個概率很?。?,這個就是負反饋,證明我們這個方向上做的是有問題的。
在我們已經得到上問所述正反饋的情況下,這個負反饋指出產品方案設計有問題,所以我們應該考慮播放歷史的分頁加載,通過數據看下大多數用戶會在播放歷史中找多久前的播放記錄,同時考慮播放歷史的下發是否有條數的上限,很可能大部分用戶只看20條以內的播放記錄,同時99%的用戶都在60條以內的播放記錄中尋找并播放,那么我們可以一頁加載20條數據,最多加載三頁。那么這個請求量就能降低很多,從一定程度上解決慢和卡頓的問題。
正反饋告訴產品經理已經尋找到正確的方向,可以繼續前進;而負反饋是告訴產品經理這個方向可能有問題,需要去解決某些問題,或者放棄這個方向;只有在正反饋和負反饋都起作用的情況下,產品設計才能有迭代,才能有有效率的迭代,才能有快速且有效率的迭代。
綜述
以上先介紹系統思維的三個公式,然后分別舉例來說明系統思維在產品設計中的應用。公式告訴我們如何做好產品設計方案,公式二告訴我們如何推進產品設計方案,而公式三告訴我們如何持續的優化產品設計方案。一點總結,供大家參考。
#專欄作家#
代成龍,人人都是產品經理專欄作家,智能硬件創業公司產品狗,從視頻巨頭公司到玩智能硬件的公司,繼續產品設計工作。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
寫的很好,但是有錯別字,另外我個人覺得公式一沒有看明白,能否把元素再描述的具體一點,感謝您的分享
抱歉有錯別字啊,之后好好檢查下,哈哈。
關于元素的話,很多公司產品負責的都是業務線,所以業務線可以算作一個元素,而在各個業務線中,前端后端也可以所做不同的兩個元素,在不同的維度下,都可以按照不同維度拆分,而拆分后就存在元素,也就間接決定了元素間的關系。
希望描述清楚了,謝謝。