產(chǎn)品設(shè)計實用思考工具8問
本文主要內(nèi)容是關(guān)于互聯(lián)網(wǎng)產(chǎn)品策劃過程中的設(shè)計方法總結(jié),是我這幾年實戰(zhàn)留下了的些許心得,通過問答的形式,來說明產(chǎn)品設(shè)計和項目過程中需注意的問題,可作為自檢思考工具。
包括內(nèi)容:需求分析、文檔輸出、體驗細節(jié)優(yōu)化、異常防錯處理等。
第 1 問:需求優(yōu)先級應(yīng)該如何排布?接下來應(yīng)該優(yōu)先啟動哪個需求
根據(jù)美國哈佛大學(xué)教授雷蒙德·弗農(nóng)(Raymond Vernon)的《產(chǎn)品生命周》理論,產(chǎn)品周期可分為:導(dǎo)入期–成長期–成熟期–衰退期?;ヂ?lián)網(wǎng)產(chǎn)品在這個四個階段,對應(yīng)的產(chǎn)品規(guī)劃重點:拉新、活躍留存、付費、自傳播優(yōu)先級比重也不同。
啟動需求之前,先問自己,你所負責的產(chǎn)品,當前處在哪個生命周期階段,當季度、當月的項目重點是什么?你可以根據(jù)產(chǎn)品當前的周期,來選定需求的優(yōu)先級,一般可將需求分為4類:P0.重要且緊急,P1.重要不緊急,P0-P1.緊急不重要(性價比高的可提至P0),P2.不緊急且不重要。跟進產(chǎn)品當前重點需要解決的問題,來確定產(chǎn)品研發(fā)方向,以及當前需啟動的需求。
第 2 問:如何做需求過濾,形成需求池?
大部分關(guān)于產(chǎn)品經(jīng)理的文章,都在寫此部分內(nèi)容,一般都會問:用戶是誰,需求目的是什么,滿足用戶哪方面訴求或心理需求,比如:懶得、虛榮、貪婪等……最常引用的是《馬斯洛五大需求理論》,但大部分都說的比較虛。
我個人認為,一個產(chǎn)品面向的用戶群是相對固定的時候,不需要花太多時間在問用戶是誰,用戶有什么特性。這一點上,我挺認同張小龍的理論(雖然他不一定說過),一個真正好的產(chǎn)品,無論用戶是誰,都會用的順手,都覺得好用。在產(chǎn)品設(shè)計過程中,特別是APP類的設(shè)計,功能的簡潔,大氣,操作普適性,我會比較認同。當然,在界面設(shè)計上做的有個性不能說是錯,但個性不等于花哨,也不等于流程隱晦繁瑣。
在過濾需求時,除了問需求目的之外,結(jié)合階段目標,研發(fā)性價比也是非常重要的。來自用戶反饋的過于具體的需求,需要多思考有沒有更好的路徑來達到用戶訴求。例如,游戲公會會長,想在游戲過程中,也可以及時審批會員申請,因此提出希望游戲過程中,可暫時返回到管理頁面進行操作。這個需求看似合理,但其實經(jīng)過簡單評估后,會發(fā)現(xiàn),研發(fā)成本非常高,且會長離開游戲房間后,需考慮一系列如自動操作、超時托管等處理,且若會長長時間不回來,是否會對一起游戲的對手造成不好的體驗等等,都是需要考慮的點。因此,需要發(fā)散考慮是否有更好的辦法來實現(xiàn)會長的這個訴求,比如說,可以增加副會長來協(xié)助會長管理,或在游戲中增加快捷操作入口,都是可以考慮的方案。滿足需求的方式不止一種,要權(quán)衡性價比和功能可能造成的后果,來決策。
有時候,因為競品做了某些功能,無論是團隊抑或是boss都會有想要快速跟上競品的想法,最終需求會落到產(chǎn)品經(jīng)理手上。對于此類需求,我個人比較不建議照搬競品功能。原因有2:
1、你與競品的用戶群屬性、產(chǎn)品周期、運營模式必定有差異,照搬很大可能會水土不服;
2、每一個產(chǎn)品、功能肯定都有做的好的地方和做的不好的的地方,學(xué)其精華去其糟粕才是王道。習(xí)慣于抄襲,不是什么好事。產(chǎn)品需要有自己的調(diào)性,哪怕只是微創(chuàng)新。
第 3 問:產(chǎn)品規(guī)劃怎么做?大需求如何進行版本拆解?要小步快跑嗎?
對于產(chǎn)品規(guī)劃來說,有一個清晰的階段目標以及明確的deline非常重要,這樣整個團隊的士氣才能被鼓舞起來。有了目標之后,版本拆解也很重要,2到3周是一個比較合適的迭代周期。需求文檔需在研發(fā)前2-4周確定好,并進入美術(shù)設(shè)計階段。
研發(fā)層面,一個迭代一周開發(fā),一周聯(lián)調(diào)并進入測試,在測試階段,可開始下個迭代需求評審,評審之后,需要預(yù)留一個方案調(diào)整的時間。尤其是對于技術(shù)實力不夠強大的團隊,產(chǎn)品在某些時候,需要更多的考慮技術(shù)實現(xiàn)成本問題。當然,哪些東西可調(diào)整,哪些要堅持原則,這個點本文后面會詳細講解。
每個版本內(nèi)容包括:新功能+基礎(chǔ)功能+小優(yōu)化點+BUG修復(fù)(緊急BUG會獨立安排人力及時解決,不會排入常規(guī)迭代),這樣來保證產(chǎn)品整體迭代的均衡,不至于每天都在救火。
第 4 問:如何提升團隊效率?如何把更多時間花在產(chǎn)品設(shè)計上而不是跟進執(zhí)行上?
在給建議之前,我想說一下自己的一個研發(fā)團隊。我的上一任產(chǎn)品在交接時,跟我說,恭喜你,要入坑了。確實,用坑來形容,不為過。市場同事的評價很中肯:功能做完上線,完全不是我們想要的功能,用戶不會用,還把其他功能搞出一大堆BUG,然后又花了幾天回退。搞了兩個月,啥都沒搞成。確實,我接手后的第一感覺就是:亂。無論是產(chǎn)品邏輯、還是團隊管理,都非常亂。在爆BUG前,沒有人知道風(fēng)險點,也沒有提前預(yù)防;整個研發(fā)團隊每個人每天都忙于應(yīng)付線上不斷復(fù)發(fā)的BUG,像熱鍋上的螞蟻,但研發(fā)效率極低,且質(zhì)量不穩(wěn)定。
我們通過一個季度的不斷嘗試和總結(jié),摸索到幾個比較有效的辦法,讓整個產(chǎn)品、研發(fā)團隊的效率和質(zhì)量得到提升:
1、信息高效互通,對應(yīng)負責人及時反饋:采用石墨共享《需求收集表》、《BUG反饋表》、《版本規(guī)劃表》。表格作為整個團隊信息互通的橋梁,包括:市場、運營、產(chǎn)品、研發(fā)等都可以隨時查看,每個人清楚我們當前還有多少BUG要解決,有多少需求待開發(fā),市場的聲音怎么樣,每個需求的優(yōu)先級,以及后續(xù)需求規(guī)劃。
《需求收集表》、《BUG反饋表》:所有人均可在需求收集表、BUG跟進表表格中填寫自己的需求,和發(fā)現(xiàn)的BUG或體驗問題,產(chǎn)品經(jīng)理需每天查看表格,并備注每項需求、BUG的處理意見和進度。研發(fā)同事在保證完成自己分內(nèi)工作后,可自行認領(lǐng)想挑戰(zhàn)解決的陳年BUG(重要不緊急),并計入績效貢獻?!栋姹疽?guī)劃表》則由產(chǎn)品負責人來按周更新,我們一般要求產(chǎn)品負責人提前兩個月以上做好品規(guī)劃,拆解成季度、月度、周的計劃。在每個月最后一周,集中收集并確定下個月版本研發(fā)內(nèi)容,并事先同步給全員。所有團隊成員可直接查看最近一個月至一季度的需求規(guī)劃情況,可提前準備或預(yù)研。
2、強化開發(fā)者的全局思考能力,無論是團隊成員自發(fā)組織體驗產(chǎn)品,還是嚴格要求技術(shù)評審時每人都需要提問,都讓研發(fā)人員更熟悉產(chǎn)品需求。讓研發(fā)團隊的每個人都了解到產(chǎn)品全局的設(shè)計框架,也多了解其他人做的模塊,同時整個團隊對階段目標、產(chǎn)品現(xiàn)有全局功能邏輯有透徹了解。逐步提升研發(fā)人員的全局框架思維能力和產(chǎn)品思維能力。做到提前預(yù)防,而不是出了BUG再來救火,也避免很多低能的BUG出現(xiàn)。
3、提高每個團隊成員的owner心態(tài),并配合及時獎勵機。每周研發(fā)組周會每人發(fā)言自己所發(fā)現(xiàn)的問題,簡單輕松,無所不談,同時設(shè)置月度研發(fā)標兵獎勵,對于有貢獻的同事進行及時鼓勵。事實證明,簡單的獎勵效果明顯,團隊上進心不斷被激發(fā),甩鍋心態(tài)也漸漸被消除。
第 5 問:如何減少方案返工,提高方案合理性?
首先,在開始輸出需求方案之前,一定要先回答3個問題:
1、需求方提出這個需求的目的是什么,也就是這個需求為了達到什么效果,你們是否對需求出發(fā)點、需求目的、預(yù)期效果達成共識?你能否預(yù)估需求上線后的數(shù)據(jù)效果?
2、是否有競品已經(jīng)實現(xiàn)了此功能,至少看3個以上競品,且每個競品實現(xiàn)的細節(jié)差異點是什么樣的,他們?yōu)槭裁磿龀刹煌?或相同的樣子?你是否了解競品功能的市場反饋或數(shù)據(jù)?
3、核心流程是否有技術(shù)難點,是否需要提前對可行性進行評估或預(yù)研?核心邏輯選定,需與研發(fā)快速確定可行行、選定最高性價比核心方案,事先全局思考,切忌邊做邊改,做到一半,發(fā)現(xiàn)方案行不通,或者技術(shù)成本過大而放棄。
在方案輸出過程中,建議先做好競品分析,同時提前咨詢研發(fā)人員關(guān)于方案核心流程的可行性以及研發(fā)難度,這樣可以很好的幫助你判斷需求是否拆分版本,如何拆分版本,避免等到需求全部輸出后,在評審會上被徹底推翻。因此,事前溝通非常重要,它能幫助你獲取更多信息,并結(jié)合研發(fā)成本、時間規(guī)劃做出最合理方案。
第 6 問:如何提升方案可用性,易用性?
核心邏輯確定之后,方案的方向和主干基本確定,接下來就是細化方案,輸出文檔。在細化方案的過程中,主要會涉及到功能流程框架,頁面交互設(shè)計、細節(jié)處理等。下面總結(jié)幾個很重要的點,來提升易用性和用戶體驗:
1、把用戶假設(shè)成一個聰明但是很忙的人,不要指望讓用戶記住任何操作流程,而是隨時提供清晰的指引和盡可能自由的頁面跳轉(zhuǎn)入口。
2、用戶的高頻操作,應(yīng)盡量減少操作步驟,而低頻操作,則無需刻意關(guān)注步驟數(shù),更應(yīng)該關(guān)注的是每一步的操作難度和界面信息是否易于理解。應(yīng)盡量降低選擇難度,別讓用戶花時間去理解。
3、一個頁面只突出一個重點,用大小,顏色,形狀來做分類,讓用戶一眼可分辨到重要信息。
4、扁平化和漸進披露相結(jié)合,視場景而定,而不是機械化執(zhí)行扁平化。流程扁平化的好處是,可以讓用戶提前感知流程,頁面跳轉(zhuǎn)的成本也比較低,但是比較考驗對頁面信息的整合處理,漸進披露是預(yù)先把次要信息隱藏,當用戶觸發(fā)了對應(yīng)操作,進入對應(yīng)流程,才給出相應(yīng)反饋或指引,好處是讓用戶更專注,減少理解成本。
5、頁面一致性也是這個道理,就我理解,一致性的是為了讓用戶形成習(xí)慣,進而減少理解成本。比如,確定操作永遠在右側(cè),選中狀態(tài)永遠高亮,紅色代表嚴重警告等等。當用戶已經(jīng)形成統(tǒng)一認知,則會大大降低每一次操作的理解成本。但有時候設(shè)計師會過于信仰一致性,導(dǎo)致失去個性,我建議在不影響習(xí)慣的前提下,可適時打破所謂一致性的束縛,讓設(shè)計更加出彩。
6、讓用戶有反悔機會。誤操作后,可恢復(fù),且重要操作需二次確認,并強化感知嚴重性。
7、避免依賴文字說明,多用圖形化的方式讓用戶直接感知,而不是通過理解文字來感知。且文案使用的格式、主語建議統(tǒng)一,這有助于營造整體調(diào)性。另外一點,即按鈕文案的使用,建議明確告訴用戶該頁面的目的和功能,同時引導(dǎo)行為,而不是陳述性文案。用動詞+賓語的格式來引導(dǎo)用戶操作,如:“去購買”比“商城”更清楚,“去玩牌”比“游戲”更清楚。
8、需同時考慮多平臺的用戶操作習(xí)慣,如ios系統(tǒng)上的應(yīng)用,頁面需提供返回按鈕,而安卓上的應(yīng)用,按鈕應(yīng)避免過于靠近手機底部操作欄,以防誤操作。
第 7 問:如何讓策劃文檔更清晰易讀?
1、在開始描述詳細功能點之前,先說明該功能的核心功能邏輯,讓讀者先了解整個文檔核心。可借助腦圖(xmind)、表格(excle)、邏輯圖來輔助描述;
2、交互流程圖(axure):將每個關(guān)鍵流程統(tǒng)一展示在一張交互圖上,并注解重點交互細節(jié)及規(guī)則,這樣讀者可以直觀感知頁面跳轉(zhuǎn)邏輯以及判斷邏輯,可以極大提升評審效率;
3、描述功能時,分模塊來劃分文檔會是比較好的做法,可避免重復(fù)。
第 8 問:需求文檔中,除了功能流程外,還需要考慮哪些內(nèi)容?
需考慮極限情況和異常情況處理:
1、列表為空情況處理,網(wǎng)絡(luò)異常拉取失敗處理,進行中強退考慮斷線重連、進行中強退后如何處理玩家進度;
2、數(shù)據(jù)超上限規(guī)則:保存數(shù)量上限、保存周期上限、分頁條數(shù)數(shù)量;
3、完整的編輯權(quán)限需具備:增、刪、改、查;
4、重連次數(shù)以及如何觸發(fā)重連:若進行3次重連嘗試依然失敗后,顯示重連按鈕,讓玩家手動觸發(fā)刷新;后臺推送失敗如獎勵發(fā)放,推送失敗,需讓玩家可以手動觸發(fā)領(lǐng)獎的地方;
5、加載頻率考慮:是否需要預(yù)加載,或者進入頁面時才加載,會影響到切換速度;
6、切后臺、斷網(wǎng)、玩家頻繁切到微信的場景,會造成APP短暫收不到正常數(shù)據(jù)推送。要考慮頁面數(shù)據(jù)是否會延遲,是否需真實刷新,或自動觸發(fā)刷新。
7、發(fā)放獎勵需考慮防刷機制,要做到即使出現(xiàn)功能BUG,系統(tǒng)也會在達到閾值時,自動預(yù)警或直接熔斷。防刷規(guī)則可簡單分為:
- 周期內(nèi)(每天、每小時、每分鐘、每秒)發(fā)放次數(shù)、額度上限閾值限制;
- 周期內(nèi)(每天、每小時、每分鐘、每秒)用戶行為(注冊、獲獎)頻率上限閾值限制。
8、完整的需求文檔,需配備配置后臺以及數(shù)據(jù)埋點需求,在功能上線后,可持續(xù)監(jiān)控跟蹤數(shù)據(jù)表現(xiàn),進而分析效果以及迭代優(yōu)化方向。
總結(jié)
1、明確需求目的:拉新、活躍、留存、付費、體驗、逼格調(diào)性……開始需求輸出前,需提煉,過濾需求,避免機械照搬競品功能;
2、明確核心邏輯并先與研發(fā)商定可行性、性價比,若性價比過低,需快速調(diào)整方案,同時,輸出完整方案時,需完善考慮異常處理、防錯設(shè)計等細節(jié),做到“帶腦子”做事;
3、確保研發(fā)人員對需求理解透徹,且能從全局角度設(shè)計技術(shù)方案,需求描述越清晰,越細致,研發(fā)效率越高;
4、大功能分迭代,分版本做,第一步先實現(xiàn)核心功能閉環(huán),上線驗證并收集反饋,再啟動附加功能開發(fā)。
本文由 @Ada冰 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)
- 目前還沒評論,等你發(fā)揮!