產品設計實戰經驗貼:產品項目設計中的關鍵點
前面做了一個基于案例定制的在線客服咨詢的項目,總結出產品項目設計中的關鍵點,希望能夠在后續的產品設計中多思考,在先前的經驗上更加高效地打造出一款產品。
一、場景的分析
1、重要性:
用戶的場景化思維,不是一種方法,更多的是一種思維。假想自己是產品的某一用戶,在具體的場景中,帶著具體的目的,來使用產品,你希望看到、用到一個什么樣的產品。你希望流程是怎么樣的,才能達到自己的目的。
所以場景化思維,決定了你這個產品能不能用,好不好用。
2、分析過程:以定制案列在線客服咨詢為例:
(1)首先,要根據用戶場景,整理出符合用戶心智模型的信息架構。
對于咨詢用戶來說,他需要在能夠找到“我要定制咨詢”的入口,并且這個入口的設置符合他的心智模型。比如說自己心中有一個具體的案列,他只需要在一個核心的入口咨詢即可。如果是看到了具體的案列想要定制,則這時在具體案列旁邊也需要一個咨詢入口。
對于客服來說,能夠接收到用戶的消息,并且這個入口也應在合理的結構之下。
(2)要對功能所處的應用場景進行詳細分析,了解場景的限制條件。
以下列舉兩個場景的思考:
場景一:連接
1)登錄用戶—-在線客服
這是最核心的場景,登錄的用戶和在線客服進行聊天。這時需要注意的就是客服的分配規則,客服都在線應該如何根據用戶的情況,或是根據客服的情況去分配?具體的分配規則根據業務情況設計。
2)登錄用戶—-離線客服。
如果由于公司資源和業務量的需求,客服并非24小時在線。非工作時間時,用戶能不能和離線客服進行聊天?我們這里采用的是留言的形式,在客服上線后進行處理。同時需要及時給用戶反饋,告知現在是非工作時間,不能收到及時的答復,但是可以留言。
3)匿名用戶—-在線客服/離線客服。
匿名用戶跟登錄用戶最大的不同就是匿名用戶的uid是臨時的,有時效性的。所以跟登錄用戶的不同就在于匿名用戶有一定的期限限制。為了使客服能夠及時的回復,我們這里還啟用了微信通知來通知客服。
場景二:對話:
1)剛開始聊天時,用戶看到一個好的案列,隨手就會問客服這個怎么做或是可不可以定制?因為咨詢入口就在這個案例的旁邊,所以用戶不可能會把這個案例的名稱給客服發一次,為了溝通的順暢,客服需要知道這個用戶指代的是哪個案例。所以在聊天的過程中,就需要把案例名稱自動一起發給客服。
2)聊天的過程,用戶可能由于其他原因關閉了聊天窗口,那么這個時候應該給客服以提示,用戶暫時已經離線,告知客服不會收到用戶的及時反饋。同時,如果客服已經給用戶發了消息,那么也是需要在用戶端做相應的提示的。
所以對于場景的分析一定要盡可能細,每種場景下的情況都需要一一列舉,哪些是核心,哪些可以舍棄?只有了解大局,研發才能確定整體的架構設計。否則在做的過程中發現一個場景漏掉了,后續就會加需求,這個需求很可能就會影響整個技術框架的設計,導致項目延遲上線。
?(3)對各種場景下的功能需求和問題,提出合適的解決方案
基于前面的場景分析,提出對應的方案也就比較容易了。在提出方案的過程中,還需要產品經理要有同理心,站在用戶的角度去考慮,在這個場景下用戶會遇到什么樣的問題?要如何避免用戶犯錯?用戶犯錯了之后應該如何補救?用戶希望收到怎么樣的反饋?
同時這些解決方案需要和技術一起協商,有時候技術實現不了的,可以換一種形式去實現。
3、如何訓練自己的場景思維?
1、要有同理心,先看別人怎么做,然后自己跟著做,模仿的過程就是體驗的過程,體驗場景中的喜怒哀樂,用體驗到的情緒指導自己的行動。
2、多接觸用戶,多與其交流,多聽聽他們的吐槽和反饋,多去體驗。
3、訓練自己的想象力,把看到的場景自主構建、補全細節在腦海中展示出來。想象力越好,構建的細節越豐富、真實,就越能從中感受到用戶的情緒。
二、PRD相關文檔:
經過前面的需求的分析,完整的輸出流程圖是對前面場景的概括。技術將會按照這個邏輯去進行開發。流程圖畫好后,需要連同產品原型進行需求評審。
產品原型決定了你的產品長什么樣,而prd文檔決定了你的產品規則邏輯。產品的流程圖,一定要畫。
產品流程圖,一般用visio畫:
產品原型:
一些小tips:
PRD文檔每個公司的要求不同,有些采用word的形式,有些直接采用在原型旁邊標注的形式。適合自己項目組,方便組員溝通的就是好的文檔。
無論是何種形式,PRD文檔的書寫要細心,產品規則要說清楚,同時交互形式也要寫清楚。盡量要多考慮產品的邊界值,以輸入框為例:
輸什么樣的值對應返回什么樣的結果?返回結果的規則是怎么樣的?當沒有結果可返回的時候怎么處理?
輸入框的輸入字符格式限制,輸入框的長度限制以及錯誤提示。
三、寫在最后:
以上就是一個產品前期設計中的最關鍵步驟,進行有效地需求分析是項目能夠順利進行的前提,后續工作才會溝通更加順暢。同時經過嚴謹的分析后,后續變動會比較少,有利于增強團隊之間的信任感。
產品雖然要廣泛聽取各方的意見,但是不能人云亦云,要有自己的原則和判斷的標準,只有這樣,做出來的東西才不會漏洞百出。
本文由 @陌上路上 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自unsplash,基于CC0協議
不錯,很有參考價值,謝謝分享!