假設用戶下載電影的情景,需要考慮:
1,下載有幾種狀態:下載中,下載成功,下載失敗,暫停中
2,下載隊列是一個還是多個
3,列表的排序規則是按添加時間倒序排,還是下載完成的排前面
4,用戶從WiFi切換到手機網絡時需要給予耗流量提示還是直接暫停
5,用戶斷網后是否需要斷點續傳,以便下次有網絡時繼續接著下載………
把邏輯和功能點理清以后,以為就沒了?圖樣圖森破,還有:
1,如何讓用戶的操作連貫順暢,提供具有明確引導性的啟示來指導用戶正確操作;
2,及時有效的給予用戶反饋:
2.1,操作反饋:對用戶的每一步操作給予及時的反饋,比如用戶添加了視頻進行下載,給予提示:添加成功,告知用戶成功做了某事
2.2,受范性反饋:要在界面對象的設計上給出視覺上能即時響應用戶操作行為的效果,比如一個按鈕,有四種狀態:
2.2.1 ,正常(normal),表示按鈕處于活動狀態,但是當前并未使用。
2.2.2 ,突出顯示(highlighted),表示按鈕正被按住或正被使用。
2.2.3 ,禁用(disabled),表示按鈕未啟用且無法使用;
2.2.4 ,已選中(selected),僅特定控件具有該狀態,表示控件當前已被選中。
2.3,系統狀態反饋:系統需要用戶等待或系統出現錯誤時,要及時讓用戶明白現狀,比如:“連接失敗,請檢查網絡是否連接”,“刷新中,請稍候”等
2.4,選擇合適的反饋形式,根據不同的情況,使用不同的反饋,比如大眾點評的商戶端,在收到付款時的提示是用語音播放的,是因為考慮到線下的
3,避免用戶犯錯或犯錯后可以重新開始
3.1,允許輕松的反向操作:提供撤銷功能,使用戶可以返回到上一步操作并重新進行選擇
3.2,避免用戶犯錯,使用合適的選擇控件(比如單選/多選/下拉列表等),提供最有代表性的默認選項,以及相應的輸入幫助,來方便用戶準確的輸入信息
3.3,提供校驗功能:對用戶的輸入和選擇等操作進行實時的判斷,幫助用戶及時更正錯誤。
3.4,當用戶犯錯時,要提供有用的恢復建議并指出錯誤所在,不能魯莽的打斷與關閉,比如:當網絡無法連接時,給予用戶提示:無法連接(刷新失敗),請檢查網絡是否連接
舉例,以下為注冊頁面,一共三個輸入框和兩個按鈕,涉及到以下細節:
1,賬號的格式要求,如果是手機號碼,前端是否需要驗證手機號碼的有效性;手機號碼為純數字,是否彈出純數字鍵盤方便用戶快速填寫及避免用戶來回切換
2,驗證碼的格式,是四/六位數字驗證碼,還是英文+數字驗證碼,英文是否區分大小寫
3,按鈕默認顯示狀態、用戶輸入信息后按鈕顏色變化效果
4,錯誤時的報錯提示文字是什么,提示格式是彈框、Toast、還是在當前頁面文字顯示?
4.1,Toast是沒有焦點的,而且Toast顯示的時間有限,過一定的時間就會自動消失。
4.2,彈框會阻斷用戶操作,需要手動點擊確認以后才會消失。
4.3,在當前頁面文字顯示的話,提示文字擺放的位置,頁面格式根據提示文字的變化,需要有怎樣的視覺效果
5,用戶點擊【注冊】以后,在網絡較慢的情況下,頁面和按鈕如何響應,是否要加鎖屏浮層+菊花緩沖提示語
6,異常提示:
6.1,點擊【獲取驗證碼】,會有手機號已被注冊,輸入框為空,手機號碼無效的情況,故需提示:
6.1.1,手機號已被注冊
6.1.2,手機號不能為空
6.1.3,手機號碼不正確
6.2,點擊【注冊】時,可能會有輸入框為空,驗證碼無效等情況,故需提示:
6.2.1,短信驗證碼不能為空
6.2.2,驗證碼已被使用
6.2.3,驗證碼已過期
6.2.4,驗證碼錯誤
6.2.5,驗證碼已達到最大嘗試次數
6.3,短信驗證碼一般通過第三方通道發送,一條四分錢左右,為了避免第三方通過工具惡意獲取短信驗證碼,除了在技術側做規避,還需要在產品規則上做一定限制,比如:每個用戶每天單個業務最多獲取10次驗證碼。
6.4,邀請碼的格式要求,邀請碼錯誤提示,填寫了邀請的用戶和沒填的用戶,在注冊成功后的區別,有邀請碼的用戶是否有獎勵之類的。
6.5,注冊成功后的提示、狀態變更及頁面跳轉
6.5.1,注冊成功后同時切換為登錄轉臺
6.5.2,給予注冊成功的提示并跳轉到相應頁面
6.5.3,比如之前是在需要token的頁面跳轉到注冊頁面的話,注冊成功后需自動跳轉回之前的頁面
3. 前端寫死與可配置
1,可配置的程序設計是為了解決面向對象的程序設計關于接口的局限性而提出來的一種程序設計方法,其優勢體現在開發人員可以使用配置文件來更改設置,而不必重新編譯應用程序,使得業務邏輯分離出來。
優點是靈活可變通,比如下圖中淘寶的滾動banner圖,在運營管理后臺隨時可以修改活動圖片及跳轉頁面,如果該模塊是寫死的話,每次變動都必須要修改代碼,并且重新提交AppStore審核通過,用戶更新APP版本后才可以看得到
缺點是圖片是服務器下發的,網絡狀態差的話加載會比較慢
可配置的模塊需要后臺程序進行開發,寫死的程序只需要前端工程師就可以完成。
2,程序寫死,是把程序中的變量變成不依賴于外部傳過來的數據,把它定義成常量。
優點是加載速度快,且開發速度快,無需后臺API接口即可完成。產品規劃過程中需要考慮哪些模塊后期可能會有變化及哪些模塊需要隨時編輯,這樣后期就不會有大的改動。
4. API接口
API應用程序接口,是系統所提供的功能接口,應用程序通過此接口,來調用系統提供的功能。
一般接口含以下四種內容:
1,接口URL地址
2,請求參數說明
3,返回參數說明
4,返回代碼說明
接口與需求息息相關,比如【添加銀行卡】的功能,我們需要告訴開發同學這個功能:
1,【添加銀行卡】需要填寫幾個字段,每個字段分別代表什么
2,字段長度是否做限制,是否有默認值
3,數據類型是什么
4,該字段是否是必填
5,異常情況的提示語是什么
5. 測試
需求提測以后產品同學需要進行功能測試,驗證開發提測的功能與邏輯是否與需求一致, 這是非常重要的一點,避免上線后發現問題。
除了功能測試以外,測試工程師收到提測版本以后,一般會進行的主要有以下四種測試:
1,UI測試:確保產品UI符合產品經理制定的原型圖與效果圖
2,功能測試:對產品的各功能進行驗證,根據功能測試用例,逐項測試,檢查產品是否達到用戶要求的功能。
3,兼容測試:確保軟件在主流機型上都能正常使用(用戶使用率已經低于5%以下可以不考慮)
4,性能測試:性能測試方面必須滿足硬件壓力條件下的測試需要
5,用戶行為統計測試:核對統計日志,確保各項操作所對應的頁面ID以及操作ID都是正確的
6. 數據分析
產品上線了,我們需要通過日常的指標數據及埋點來了解用戶的行為是否符合產品設計的預想,后期如何改進設計。
埋點統計指的是植入代碼追蹤用戶行為,統計關鍵功能的使用次數以及建立模型來量化用戶操作行為
日常指標數據有很多,其中主要的有:
本篇文章講的只是部分產品工作中包含的關注點,看完這篇文章,你覺得你們公司需要產品經理嗎?
文章來源:微信公共號kakurachen(ID:kakura1024)
文章作者:kakurachen
不設置產品經理崗位的公司是怎么想的??這樣的公司還有可待的價值嗎?? ?? ??
一線產品喵淺談日常產品工作關注點 | 人人都是產品經理 http://www.aharts.cn/pmd/235542.html
原作者已經在該網站發布過了。
對于入門狗很實用 ??
同意