之前有國(guó)內(nèi)一位Top級(jí)的CTO一直吐槽產(chǎn)品經(jīng)理，對(duì)產(chǎn)品經(jīng)理不以為然，覺(jué)得這個(gè)職位非常多余。最近突然在微信上對(duì)我說(shuō)：“趕緊推薦我?guī)讉€(gè)產(chǎn)品經(jīng)理，沒(méi)有產(chǎn)品經(jīng)理真不行。

作為一個(gè)一線產(chǎn)品經(jīng)理，我覺(jué)得產(chǎn)品是一個(gè)非常專業(yè)的崗位，除一般的需求分析和設(shè)計(jì)外，還有很多需要考慮的東西。從抽象的需求落實(shí)到具體的界面并不是一件簡(jiǎn)單的事

產(chǎn)品框架

一個(gè)產(chǎn)品或者說(shuō)一個(gè)功能點(diǎn)，從抽象到具體，經(jīng)過(guò)了產(chǎn)品目標(biāo)-內(nèi)容需求-信息架構(gòu)-交互設(shè)計(jì)-界面設(shè)計(jì)-感知設(shè)計(jì)等一系列過(guò)程。

比如大眾點(diǎn)評(píng)，作為一個(gè)生活信息及交易平臺(tái)，主要有用戶與商戶的關(guān)系，鈔票流入與流出的關(guān)系，其中用戶與商戶的關(guān)系又分為線上和線下。

了解了產(chǎn)品目標(biāo)和用戶需求以后，就可以確定需求的大概流程，比如：

1用戶在線上找到商戶→2付款→3用戶在線下獲取服務(wù)

關(guān)于1，用戶在找商品時(shí)可能有會(huì)有三種特征：

• 用戶對(duì)選擇哪個(gè)商戶比較模糊
• 用戶完全不知道自己想要什么
• 用戶知道自己想要什么，目標(biāo)很明確

這三種特征有：曝光，分類，搜索，推薦四種手段可以滿足。確定了1的四種形式以后，根據(jù)這個(gè)形式再形成表現(xiàn)層。

需求無(wú)論大小，要考慮全面，邏輯清晰

假設(shè)用戶下載電影的情景，需要考慮：

1. 下載有幾種狀態(tài)：下載中，下載成功，下載失敗，暫停中
2. 下載隊(duì)列是一個(gè)還是多個(gè)
3. 列表的排序規(guī)則是按添加時(shí)間倒序排，還是下載完成的排前面
4. 用戶從WiFi切換到手機(jī)網(wǎng)絡(luò)時(shí)需要給予耗流量提示還是直接暫停
5. 用戶斷網(wǎng)后是否需要斷點(diǎn)續(xù)傳，以便下次有網(wǎng)絡(luò)時(shí)繼續(xù)接著下載

………

把邏輯和功能點(diǎn)理清以后，以為就沒(méi)了？圖樣圖森破，還有：

1，如何讓用戶的操作連貫順暢，提供具有明確引導(dǎo)性的啟示來(lái)指導(dǎo)用戶正確操作；

2，及時(shí)有效的給予用戶反饋：

2.1，操作反饋：對(duì)用戶的每一步操作給予及時(shí)的反饋，比如用戶添加了視頻進(jìn)行下載，給予提示：添加成功，告知用戶成功做了某事

2.2，受范性反饋：要在界面對(duì)象的設(shè)計(jì)上給出視覺(jué)上能即時(shí)響應(yīng)用戶操作行為的效果，比如一個(gè)按鈕，有四種狀態(tài)：

• 正常（normal），表示按鈕處于活動(dòng)狀態(tài)，但是當(dāng)前并未使用。
• 突出顯示（highlighted），表示按鈕正被按住或正被使用。
• 禁用（disabled），表示按鈕未啟用且無(wú)法使用；
• 已選中（selected），僅特定控件具有該狀態(tài)，表示控件當(dāng)前已被選中。

2.3，系統(tǒng)狀態(tài)反饋：系統(tǒng)需要用戶等待或系統(tǒng)出現(xiàn)錯(cuò)誤時(shí)，要及時(shí)讓用戶明白現(xiàn)狀，比如：“連接失敗，請(qǐng)檢查網(wǎng)絡(luò)是否連接”，“刷新中，請(qǐng)稍候”等

2.4，選擇合適的反饋形式，根據(jù)不同的情況，使用不同的反饋，比如大眾點(diǎn)評(píng)的商戶端，在收到付款時(shí)的提示是用語(yǔ)音播放的，是因?yàn)榭紤]到線下的商戶環(huán)境人流較多，服務(wù)員所處環(huán)境比較嘈雜及無(wú)法時(shí)刻查看手機(jī)等各種元素，才選擇了提示性比較強(qiáng)的語(yǔ)音自動(dòng)播放。

3，避免用戶犯錯(cuò)或犯錯(cuò)后可以重新開(kāi)始

3.1，允許輕松的反向操作：提供撤銷功能，使用戶可以返回到上一步操作并重新進(jìn)行選擇

3.2，避免用戶犯錯(cuò)，使用合適的選擇控件（比如單選/多選/下拉列表等），提供最有代表性的默認(rèn)選項(xiàng)，以及相應(yīng)的輸入幫助，來(lái)方便用戶準(zhǔn)確的輸入信息

3.3，提供校驗(yàn)功能：對(duì)用戶的輸入和選擇等操作進(jìn)行實(shí)時(shí)的判斷，幫助用戶及時(shí)更正錯(cuò)誤。

3.4，當(dāng)用戶犯錯(cuò)時(shí)，要提供有用的恢復(fù)建議并指出錯(cuò)誤所在，不能魯莽的打斷與關(guān)閉，比如：當(dāng)網(wǎng)絡(luò)無(wú)法連接時(shí)，給予用戶提示：無(wú)法連接（刷新失敗），請(qǐng)檢查網(wǎng)絡(luò)是否連接

舉例，以下為注冊(cè)頁(yè)面，一共三個(gè)輸入框和兩個(gè)按鈕，涉及到以下細(xì)節(jié)：

1，賬號(hào)的格式要求，如果是手機(jī)號(hào)碼，前端是否需要驗(yàn)證手機(jī)號(hào)碼的有效性；手機(jī)號(hào)碼為純數(shù)字，是否彈出純數(shù)字鍵盤(pán)方便用戶快速填寫(xiě)及避免用戶來(lái)回切換

2，驗(yàn)證碼的格式，是四/六位數(shù)字驗(yàn)證碼，還是英文+數(shù)字驗(yàn)證碼，英文是否區(qū)分大小寫(xiě)

3，按鈕默認(rèn)顯示狀態(tài)、用戶輸入信息后按鈕顏色變化效果

4，錯(cuò)誤時(shí)的報(bào)錯(cuò)提示文字是什么，提示格式是彈框、Toast、還是在當(dāng)前頁(yè)面文字顯示？

4.1，Toast是沒(méi)有焦點(diǎn)的，而且Toast顯示的時(shí)間有限，過(guò)一定的時(shí)間就會(huì)自動(dòng)消失。

4.2，彈框會(huì)阻斷用戶操作，需要手動(dòng)點(diǎn)擊確認(rèn)以后才會(huì)消失。

4.3，在當(dāng)前頁(yè)面文字顯示的話，提示文字?jǐn)[放的位置，頁(yè)面格式根據(jù)提示文字的變化，需要有怎樣的視覺(jué)效果

5，用戶點(diǎn)擊【注冊(cè)】以后，在網(wǎng)絡(luò)較慢的情況下，頁(yè)面和按鈕如何響應(yīng)，是否要加鎖屏浮層+菊花緩沖提示語(yǔ)

6，異常提示：

6.1，點(diǎn)擊【獲取驗(yàn)證碼】，會(huì)有手機(jī)號(hào)已被注冊(cè)，輸入框?yàn)榭眨謾C(jī)號(hào)碼無(wú)效的情況，故需提示：

• 手機(jī)號(hào)已被注冊(cè)
• 手機(jī)號(hào)不能為空
• 手機(jī)號(hào)碼不正確

6.2，點(diǎn)擊【注冊(cè)】時(shí)，可能會(huì)有輸入框?yàn)榭眨?yàn)證碼無(wú)效等情況，故需提示：

• 短信驗(yàn)證碼不能為空
• 驗(yàn)證碼已被使用
• 驗(yàn)證碼已過(guò)期
• 驗(yàn)證碼錯(cuò)誤
• 驗(yàn)證碼已達(dá)到最大嘗試次數(shù)

6.3，短信驗(yàn)證碼一般通過(guò)第三方通道發(fā)送，一條四分錢(qián)左右，為了避免第三方通過(guò)工具惡意獲取短信驗(yàn)證碼，除了在技術(shù)側(cè)做規(guī)避，還需要在產(chǎn)品規(guī)則上做一定限制，比如：每個(gè)用戶每天單個(gè)業(yè)務(wù)最多獲取10次驗(yàn)證碼。

6.4，邀請(qǐng)碼的格式要求，邀請(qǐng)碼錯(cuò)誤提示，填寫(xiě)了邀請(qǐng)的用戶和沒(méi)填的用戶，在注冊(cè)成功后的區(qū)別，有邀請(qǐng)碼的用戶是否有獎(jiǎng)勵(lì)之類的。

6.5，注冊(cè)成功后的提示、狀態(tài)變更及頁(yè)面跳轉(zhuǎn)

• 注冊(cè)成功后同時(shí)切換為登錄轉(zhuǎn)臺(tái)
• 給予注冊(cè)成功的提示并跳轉(zhuǎn)到相應(yīng)頁(yè)面
• 比如之前是在需要token的頁(yè)面跳轉(zhuǎn)到注冊(cè)頁(yè)面的話，注冊(cè)成功后需自動(dòng)跳轉(zhuǎn)回之前的頁(yè)面

前端寫(xiě)死與可配置

1，可配置的程序設(shè)計(jì)是為了解決面向?qū)ο蟮某绦蛟O(shè)計(jì)關(guān)于接口的局限性而提出來(lái)的一種程序設(shè)計(jì)方法,其優(yōu)勢(shì)體現(xiàn)在開(kāi)發(fā)人員可以使用配置文件來(lái)更改設(shè)置,而不必重新編譯應(yīng)用程序，使得業(yè)務(wù)邏輯分離出來(lái)。

優(yōu)點(diǎn)是靈活可變通，比如下圖中淘寶的滾動(dòng)banner圖，在運(yùn)營(yíng)管理后臺(tái)隨時(shí)可以修改活動(dòng)圖片及跳轉(zhuǎn)頁(yè)面，如果該模塊是寫(xiě)死的話，每次變動(dòng)都必須要修改代碼，并且重新提交AppStore審核通過(guò)，用戶更新APP版本后才可以看得到。

缺點(diǎn)是圖片是服務(wù)器下發(fā)的，網(wǎng)絡(luò)狀態(tài)差的話加載會(huì)比較慢

可配置的模塊需要后臺(tái)程序進(jìn)行開(kāi)發(fā)，寫(xiě)死的程序只需要前端工程師就可以完成。

2，程序?qū)懰?，是把程序中的變量變成不依賴于外部傳過(guò)來(lái)的數(shù)據(jù)，把它定義成常量。

優(yōu)點(diǎn)是加載速度快，且開(kāi)發(fā)速度快，無(wú)需后臺(tái)API接口即可完成。產(chǎn)品規(guī)劃過(guò)程中需要考慮哪些模塊后期可能會(huì)有變化及哪些模塊需要隨時(shí)編輯，這樣后期就不會(huì)有大的改動(dòng)。

API接口

API應(yīng)用程序接口，是系統(tǒng)所提供的功能接口，應(yīng)用程序通過(guò)此接口，來(lái)調(diào)用系統(tǒng)提供的功能。

一般接口含以下四種內(nèi)容：

1. 接口URL地址
2. 請(qǐng)求參數(shù)說(shuō)明
3. 返回參數(shù)說(shuō)明
4. 返回代碼說(shuō)明

接口與需求息息相關(guān)，比如【添加銀行卡】的功能，我們需要告訴開(kāi)發(fā)同學(xué)這個(gè)功能：

1. 【添加銀行卡】需要填寫(xiě)幾個(gè)字段，每個(gè)字段分別代表什么
2. 字段長(zhǎng)度是否做限制，是否有默認(rèn)值
3. 數(shù)據(jù)類型是什么
4. 該字段是否是必填
5. 異常情況的提示語(yǔ)是什么

測(cè)試

需求提測(cè)以后產(chǎn)品同學(xué)需要進(jìn)行功能測(cè)試，驗(yàn)證開(kāi)發(fā)提測(cè)的功能與邏輯是否與需求一致， 這是非常重要的一點(diǎn)，避免上線后發(fā)現(xiàn)問(wèn)題。

除了功能測(cè)試以外，測(cè)試工程師收到提測(cè)版本以后，一般會(huì)進(jìn)行的主要有以下四種測(cè)試：

• UI測(cè)試：確保產(chǎn)品UI符合產(chǎn)品經(jīng)理制定的原型圖與效果圖
• 功能測(cè)試：對(duì)產(chǎn)品的各功能進(jìn)行驗(yàn)證，根據(jù)功能測(cè)試用例，逐項(xiàng)測(cè)試，檢查產(chǎn)品是否達(dá)到用戶要求的功能。
• 兼容測(cè)試：確保軟件在主流機(jī)型上都能正常使用（用戶使用率已經(jīng)低于5%以下可以不考慮）
• 性能測(cè)試：性能測(cè)試方面必須滿足硬件壓力條件下的測(cè)試需要
• 用戶行為統(tǒng)計(jì)測(cè)試：核對(duì)統(tǒng)計(jì)日志，確保各項(xiàng)操作所對(duì)應(yīng)的頁(yè)面ID以及操作ID都是正確的

數(shù)據(jù)分析

產(chǎn)品上線了，我們需要通過(guò)日常的指標(biāo)數(shù)據(jù)及埋點(diǎn)來(lái)了解用戶的行為是否符合產(chǎn)品設(shè)計(jì)的預(yù)想，后期如何改進(jìn)設(shè)計(jì)。

埋點(diǎn)統(tǒng)計(jì)指的是植入代碼追蹤用戶行為，統(tǒng)計(jì)關(guān)鍵功能的使用次數(shù)以及建立模型來(lái)量化用戶操作行為

日常指標(biāo)數(shù)據(jù)有很多，其中主要的有：

本篇文章講的只是部分產(chǎn)品工作中包含的關(guān)注點(diǎn)，看完這篇文章，你覺(jué)得你們公司需要產(chǎn)品經(jīng)理嗎？

本文由 @kakurachen (微信公眾賬號(hào)kakurachen)原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。