應用程序的概念，大家或多或少都有接觸過。最直觀的概念是就是應用程序是一個具有特定后綴的文件，比如常見的windows的exe文件、Android的apk文件、ios的ipa文件，不常見的sdk文件或者api函數(shù)。這些就是產(chǎn)品經(jīng)理和程序員們吭哧吭哧出來的最終成果“產(chǎn)品”。
產(chǎn)品包含“數(shù)據(jù)”(默認的用戶信息、圖片資料等)和“邏輯”(做什么事，完成什么任務等)。再回到名字上“應用程序”，這個程序必須還有大規(guī)模有人“應用”，也就是說它必須要有商業(yè)價值。
以上就是我理解的互聯(lián)網(wǎng)“產(chǎn)品 ”，包括但不限于APP。
私人的感悟：我會根據(jù)下面五句話做出一款產(chǎn)品
摸清需求、分不同模塊
寫角色卡、建立流程圖
拆解頁面、畫思維導圖
寫prd文檔、制交互原型
數(shù)據(jù)分析、反復迭代優(yōu)化
1、摸清需求、分成不同模塊
雖然偶爾有天馬行空的腦洞，想做出一款我心中的產(chǎn)品，但是大多數(shù)情況下是幫助別人做一款產(chǎn)品。我在《產(chǎn)品經(jīng)理如何對初步獲取的需求進行處理》一文中，寫過需求控制。大體模式相同，不同的是那篇文章主要講日常怎么控制需求，這次摸需求是摸老板的初次想法。
有以下幾點你需要注意：
用筆記下你老板的具體需求;
記錄他提出的需求背景，即他為什么要做這款產(chǎn)品看好什么場景;
幫助他理清他的產(chǎn)品模塊，比如核心用戶模塊、核心業(yè)務模塊、邏輯聯(lián)系模塊、公共模塊等。
2、寫角色卡、建立流程圖
記錄了明確的記錄需求后，我們可以根據(jù)需求描繪產(chǎn)品的用戶畫像。具體做法是制作角色卡，一般網(wǎng)上都有模板。具體做法可以采用4W1H法：什么人、什么場景下、什么目的、遇到什么困難、期望如何幫助。就是上面所說的數(shù)據(jù)，用戶信息、圖片資料等。
根據(jù)寫的多張角色卡，我們要建立流程圖。流程圖可能簡單可能復雜，具體要看實際情況了。有流程圖才可以保證在技術(shù)上是有可行性的，就是上面說的“邏輯”做什么事，完成什么任務等。
3、拆解頁面、畫思維導圖
如果你是合格的產(chǎn)品經(jīng)理，你至少玩過200款以上的產(chǎn)品，產(chǎn)品的基礎雛形在這個階段心中基本有數(shù)了(沒數(shù)就找競品借鑒借鑒唄)。主題頁面基本拆解在圖紙上了，不確定的或者有疑問的地方一般特別標注。為了防止你制作原型時思維混亂，這個時候你需要根據(jù)角色卡、流程圖和拆解的頁面畫一張思維導圖。思維導圖根據(jù)頁面層級和操作按鈕內(nèi)容兩個維度來畫，它非常有用。
4、寫prd文檔、制交互原型
上面的事情做完后，你可以寫prd文檔和制作交互原型了，廣泛的來說原型也是prd文檔的一種。原型的站點地圖一般是根據(jù)思維導圖來的，功能按鈕部分是按照圖來的部分是臨時畫的。這個時候建議使用“角色扮演法”，基于用戶的心智模型思考產(chǎn)品操作，爭取做到“Don’t make me think”。
畫完原型，可以讓人試用并指正，最終得到開發(fā)的依據(jù)原型。
5、數(shù)據(jù)分析、反復迭代優(yōu)化
雖然理想是好的，我們辛辛苦苦的做出了產(chǎn)品，但是有些功能用戶就是不喜歡。我們需要通過數(shù)據(jù)來驗證產(chǎn)品的設計，獲取數(shù)據(jù)的通俗辦法是埋點。第三方數(shù)據(jù)分析工具有：Google Analytics、騰訊Bugly、百度統(tǒng)計、友盟、GrowingIO、諸葛IO等。這些工具中最心水騰訊Bugly，不缺錢的推薦使用Google Analytics，免費的可以用諸葛IO(多嘴句，號稱無埋點的GrowingIO非常坑，3萬以下用戶6萬一年的使用費，小企業(yè)用不起嘞)。
我們通過埋點后，可以通過多維度了解用戶在使用產(chǎn)品的數(shù)據(jù)。根據(jù)數(shù)據(jù)，可以優(yōu)化迭代產(chǎn)品，優(yōu)化方案可以嘗試A/B測試，效果也還可以。
寫文章果然是理清自己思路的好辦法，總結(jié)下五句話做產(chǎn)品：
摸清需求、分成不同模塊
寫角色卡、建立流程圖
拆解頁面、畫思維導圖
撰寫prd文檔、制作交互原型
數(shù)據(jù)埋點分析、反復迭代優(yōu)化
亮照備案信息 |
建站熱線
甘公網(wǎng)安備 62080202000160
號