一線產(chǎn)品喵淺談日常產(chǎn)品工作關(guān)注點
![](http://image.woshipm.com/wp-files/img/108.jpg)
之前有國內(nèi)一位Top級的CTO一直吐槽產(chǎn)品經(jīng)理,對產(chǎn)品經(jīng)理不以為然,覺得這個職位非常多余。最近突然在微信上對我說:“趕緊推薦我?guī)讉€產(chǎn)品經(jīng)理,沒有產(chǎn)品經(jīng)理真不行。
作為一個一線產(chǎn)品經(jīng)理,我覺得產(chǎn)品是一個非常專業(yè)的崗位,除一般的需求分析和設(shè)計外,還有很多需要考慮的東西。從抽象的需求落實到具體的界面并不是一件簡單的事
產(chǎn)品框架
一個產(chǎn)品或者說一個功能點,從抽象到具體,經(jīng)過了產(chǎn)品目標(biāo)-內(nèi)容需求-信息架構(gòu)-交互設(shè)計-界面設(shè)計-感知設(shè)計等一系列過程。
比如大眾點評,作為一個生活信息及交易平臺,主要有用戶與商戶的關(guān)系,鈔票流入與流出的關(guān)系,其中用戶與商戶的關(guān)系又分為線上和線下。
了解了產(chǎn)品目標(biāo)和用戶需求以后,就可以確定需求的大概流程,比如:
1用戶在線上找到商戶→2付款→3用戶在線下獲取服務(wù)
關(guān)于1,用戶在找商品時可能有會有三種特征:
- 用戶對選擇哪個商戶比較模糊
- 用戶完全不知道自己想要什么
- 用戶知道自己想要什么,目標(biāo)很明確
這三種特征有:曝光,分類,搜索,推薦四種手段可以滿足。確定了1的四種形式以后,根據(jù)這個形式再形成表現(xiàn)層。
需求無論大小,要考慮全面,邏輯清晰
假設(shè)用戶下載電影的情景,需要考慮:
- 下載有幾種狀態(tài):下載中,下載成功,下載失敗,暫停中
- 下載隊列是一個還是多個
- 列表的排序規(guī)則是按添加時間倒序排,還是下載完成的排前面
- 用戶從WiFi切換到手機網(wǎng)絡(luò)時需要給予耗流量提示還是直接暫停
- 用戶斷網(wǎng)后是否需要斷點續(xù)傳,以便下次有網(wǎng)絡(luò)時繼續(xù)接著下載
………
把邏輯和功能點理清以后,以為就沒了?圖樣圖森破,還有:
1,如何讓用戶的操作連貫順暢,提供具有明確引導(dǎo)性的啟示來指導(dǎo)用戶正確操作;
2,及時有效的給予用戶反饋:
2.1,操作反饋:對用戶的每一步操作給予及時的反饋,比如用戶添加了視頻進行下載,給予提示:添加成功,告知用戶成功做了某事
2.2,受范性反饋:要在界面對象的設(shè)計上給出視覺上能即時響應(yīng)用戶操作行為的效果,比如一個按鈕,有四種狀態(tài):
- 正常(normal),表示按鈕處于活動狀態(tài),但是當(dāng)前并未使用。
- 突出顯示(highlighted),表示按鈕正被按住或正被使用。
- 禁用(disabled),表示按鈕未啟用且無法使用;
- 已選中(selected),僅特定控件具有該狀態(tài),表示控件當(dāng)前已被選中。
2.3,系統(tǒng)狀態(tài)反饋:系統(tǒng)需要用戶等待或系統(tǒng)出現(xiàn)錯誤時,要及時讓用戶明白現(xiàn)狀,比如:“連接失敗,請檢查網(wǎng)絡(luò)是否連接”,“刷新中,請稍候”等
2.4,選擇合適的反饋形式,根據(jù)不同的情況,使用不同的反饋,比如大眾點評的商戶端,在收到付款時的提示是用語音播放的,是因為考慮到線下的商戶環(huán)境人流較多,服務(wù)員所處環(huán)境比較嘈雜及無法時刻查看手機等各種元素,才選擇了提示性比較強的語音自動播放。
3,避免用戶犯錯或犯錯后可以重新開始
3.1,允許輕松的反向操作:提供撤銷功能,使用戶可以返回到上一步操作并重新進行選擇
3.2,避免用戶犯錯,使用合適的選擇控件(比如單選/多選/下拉列表等),提供最有代表性的默認選項,以及相應(yīng)的輸入幫助,來方便用戶準(zhǔn)確的輸入信息
3.3,提供校驗功能:對用戶的輸入和選擇等操作進行實時的判斷,幫助用戶及時更正錯誤。
3.4,當(dāng)用戶犯錯時,要提供有用的恢復(fù)建議并指出錯誤所在,不能魯莽的打斷與關(guān)閉,比如:當(dāng)網(wǎng)絡(luò)無法連接時,給予用戶提示:無法連接(刷新失?。?,請檢查網(wǎng)絡(luò)是否連接
舉例,以下為注冊頁面,一共三個輸入框和兩個按鈕,涉及到以下細節(jié):
1,賬號的格式要求,如果是手機號碼,前端是否需要驗證手機號碼的有效性;手機號碼為純數(shù)字,是否彈出純數(shù)字鍵盤方便用戶快速填寫及避免用戶來回切換
2,驗證碼的格式,是四/六位數(shù)字驗證碼,還是英文+數(shù)字驗證碼,英文是否區(qū)分大小寫
3,按鈕默認顯示狀態(tài)、用戶輸入信息后按鈕顏色變化效果
4,錯誤時的報錯提示文字是什么,提示格式是彈框、Toast、還是在當(dāng)前頁面文字顯示?
4.1,Toast是沒有焦點的,而且Toast顯示的時間有限,過一定的時間就會自動消失。
4.2,彈框會阻斷用戶操作,需要手動點擊確認以后才會消失。
4.3,在當(dāng)前頁面文字顯示的話,提示文字擺放的位置,頁面格式根據(jù)提示文字的變化,需要有怎樣的視覺效果
5,用戶點擊【注冊】以后,在網(wǎng)絡(luò)較慢的情況下,頁面和按鈕如何響應(yīng),是否要加鎖屏浮層+菊花緩沖提示語
6,異常提示:
6.1,點擊【獲取驗證碼】,會有手機號已被注冊,輸入框為空,手機號碼無效的情況,故需提示:
- 手機號已被注冊
- 手機號不能為空
- 手機號碼不正確
6.2,點擊【注冊】時,可能會有輸入框為空,驗證碼無效等情況,故需提示:
- 短信驗證碼不能為空
- 驗證碼已被使用
- 驗證碼已過期
- 驗證碼錯誤
- 驗證碼已達到最大嘗試次數(shù)
6.3,短信驗證碼一般通過第三方通道發(fā)送,一條四分錢左右,為了避免第三方通過工具惡意獲取短信驗證碼,除了在技術(shù)側(cè)做規(guī)避,還需要在產(chǎn)品規(guī)則上做一定限制,比如:每個用戶每天單個業(yè)務(wù)最多獲取10次驗證碼。
6.4,邀請碼的格式要求,邀請碼錯誤提示,填寫了邀請的用戶和沒填的用戶,在注冊成功后的區(qū)別,有邀請碼的用戶是否有獎勵之類的。
6.5,注冊成功后的提示、狀態(tài)變更及頁面跳轉(zhuǎn)
- 注冊成功后同時切換為登錄轉(zhuǎn)臺
- 給予注冊成功的提示并跳轉(zhuǎn)到相應(yīng)頁面
- 比如之前是在需要token的頁面跳轉(zhuǎn)到注冊頁面的話,注冊成功后需自動跳轉(zhuǎn)回之前的頁面
前端寫死與可配置
1,可配置的程序設(shè)計是為了解決面向?qū)ο蟮某绦蛟O(shè)計關(guān)于接口的局限性而提出來的一種程序設(shè)計方法,其優(yōu)勢體現(xiàn)在開發(fā)人員可以使用配置文件來更改設(shè)置,而不必重新編譯應(yīng)用程序,使得業(yè)務(wù)邏輯分離出來。
優(yōu)點是靈活可變通,比如下圖中淘寶的滾動banner圖,在運營管理后臺隨時可以修改活動圖片及跳轉(zhuǎn)頁面,如果該模塊是寫死的話,每次變動都必須要修改代碼,并且重新提交AppStore審核通過,用戶更新APP版本后才可以看得到。
缺點是圖片是服務(wù)器下發(fā)的,網(wǎng)絡(luò)狀態(tài)差的話加載會比較慢
可配置的模塊需要后臺程序進行開發(fā),寫死的程序只需要前端工程師就可以完成。
2,程序?qū)懰溃前殉绦蛑械淖兞孔兂刹灰蕾囉谕獠總鬟^來的數(shù)據(jù),把它定義成常量。
優(yōu)點是加載速度快,且開發(fā)速度快,無需后臺API接口即可完成。產(chǎn)品規(guī)劃過程中需要考慮哪些模塊后期可能會有變化及哪些模塊需要隨時編輯,這樣后期就不會有大的改動。
API接口
API應(yīng)用程序接口,是系統(tǒng)所提供的功能接口,應(yīng)用程序通過此接口,來調(diào)用系統(tǒng)提供的功能。
一般接口含以下四種內(nèi)容:
- 接口URL地址
- 請求參數(shù)說明
- 返回參數(shù)說明
- 返回代碼說明
接口與需求息息相關(guān),比如【添加銀行卡】的功能,我們需要告訴開發(fā)同學(xué)這個功能:
- 【添加銀行卡】需要填寫幾個字段,每個字段分別代表什么
- 字段長度是否做限制,是否有默認值
- 數(shù)據(jù)類型是什么
- 該字段是否是必填
- 異常情況的提示語是什么
測試
需求提測以后產(chǎn)品同學(xué)需要進行功能測試,驗證開發(fā)提測的功能與邏輯是否與需求一致, 這是非常重要的一點,避免上線后發(fā)現(xiàn)問題。
除了功能測試以外,測試工程師收到提測版本以后,一般會進行的主要有以下四種測試:
- UI測試:確保產(chǎn)品UI符合產(chǎn)品經(jīng)理制定的原型圖與效果圖
- 功能測試:對產(chǎn)品的各功能進行驗證,根據(jù)功能測試用例,逐項測試,檢查產(chǎn)品是否達到用戶要求的功能。
- 兼容測試:確保軟件在主流機型上都能正常使用(用戶使用率已經(jīng)低于5%以下可以不考慮)
- 性能測試:性能測試方面必須滿足硬件壓力條件下的測試需要
- 用戶行為統(tǒng)計測試:核對統(tǒng)計日志,確保各項操作所對應(yīng)的頁面ID以及操作ID都是正確的
數(shù)據(jù)分析
產(chǎn)品上線了,我們需要通過日常的指標(biāo)數(shù)據(jù)及埋點來了解用戶的行為是否符合產(chǎn)品設(shè)計的預(yù)想,后期如何改進設(shè)計。
埋點統(tǒng)計指的是植入代碼追蹤用戶行為,統(tǒng)計關(guān)鍵功能的使用次數(shù)以及建立模型來量化用戶操作行為
日常指標(biāo)數(shù)據(jù)有很多,其中主要的有:
本篇文章講的只是部分產(chǎn)品工作中包含的關(guān)注點,看完這篇文章,你覺得你們公司需要產(chǎn)品經(jīng)理嗎?
本文由 @kakurachen (微信公眾賬號kakurachen)原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?,未經(jīng)許可,禁止轉(zhuǎn)載。
謝謝分享
能問一下 移動產(chǎn)品的頁面埋點,我能了解友盟數(shù)據(jù)SDK的數(shù)據(jù),但是我想要某個頁面的用戶行為分析,能給個指導(dǎo)么?
想問問為什么拿點評舉例?
我還拿過QQ、微信、小紅書、迅雷舉例….
?? 覺得還不錯
謝謝,歡迎關(guān)注(微信公眾賬號kakurachen)
有總結(jié)沒有升華,其實就是尼爾森交互設(shè)計的十大原則
嗯哈~謝謝建議~~ ??
希望筆者有時間 可以陸續(xù)分享 廣大小白3Q
之前編輯審核的時候不小心把我微信公眾賬號刪啦~現(xiàn)在加上了~歡迎關(guān)注(微信公眾賬號kakurachen),里面有一些之前的文章
?? 第一次覺得是干貨的文 感謝
?? 謝謝~歡迎關(guān)注(微信公眾賬號kakurachen)
贊,已經(jīng)關(guān)注作者
順便把(微信公眾賬號kakurachen)也關(guān)注一下唄 ??
優(yōu)秀產(chǎn)品也應(yīng)該略懂編程技術(shù),至少要具有編程思維,在需求提出和溝通上都可以做的更好。另,前段寫死和可配置可以一同存在嗎?即日常時間是寫死,但特殊時間可配置?通過if來判斷。還是說可配置但不常換的模塊都是通過緩存來實現(xiàn),以提高每次顯示的速度?
這里說的寫死和可配置是指native和web的區(qū)別吧,如果是native的,要更改那就是客戶端的更改,得提交新版本。
了解 ?? 又get到一項!
其實我文科出身耶,都是在實際工作中鍛煉出來的。最后安利一下,關(guān)注下(微信公眾賬號kakurachen)唄。。 ??
?? 很有用
?? 謝謝,關(guān)注下(微信公眾賬號kakurachen)唄
寫的不錯哦,還是比較全面的
?? 謝謝,(微信公眾賬號kakurachen),我會不定期發(fā)文章哦,還有之前的文章
感謝分享~很有用
?? 感謝肯定,安利下我的公眾號哈(微信公眾賬號kakurachen)
贊一個
謝謝, 不枉我辛苦寫出來哈哈,關(guān)注下(微信公眾賬號kakurachen)唄
寫的很好,謝謝分享
?? 之前也有分享哦,微信公眾賬號里有(微信公眾賬號kakurachen)
前端寫死與可配置—-這個,第一次開發(fā)app的人表示快被這個坑死了,沒考慮好真的是好難處理,只能等審核等更新,花都謝了
最近我司正在著手通過服務(wù)器下發(fā)lua腳本,動態(tài)改變程序代碼。主要用于修復(fù)bug。。這樣就不用強制用戶更新了。也不需要可配置。【對了,關(guān)注一下我的微信公眾賬號唄(微信公眾賬號kakurachen)】
覺得已經(jīng)寫的很好了啊,很具體的工作了。文章中只是舉例說明了作者工作一部分啦,樓上的都那么較真呢
?? 謝謝~~歡迎關(guān)注(微信公眾賬號kakurachen),我會繼續(xù)努力噠
非常有幫助? 另外API接口文檔一般是由產(chǎn)品來寫嗎?
我們公司api接口是技術(shù)來寫的
接口文檔是架構(gòu)師來寫的哈~我們要做的是幫助架構(gòu)師更快更清晰的了解需求~
用戶調(diào)研、需求分析、需求落地、原型設(shè)計(交互+視覺)、開發(fā)-測試、產(chǎn)品運營、數(shù)據(jù)分析-用戶調(diào)研,論一個產(chǎn)品生命周期的閉環(huán),題主請繼續(xù)補充啊~
?? 好噠 關(guān)注(微信公眾賬號kakurachen)一下唄
手動點贊
謝謝~歡迎關(guān)注(微信公眾賬號kakurachen)