KEVIN在工作之餘， 也在學習關於產品的一些軟硬體技能。 讓自己時刻保持在一個不鬆懈的狀態， 作為各位產品朋友來說， 你們呢？會不會太忙， 沒時間學習啦？
資料包表與交互設計中的問題產品資料分析的一些特殊報表
一款產品的資料包表不少產品朋友用的是友盟或者自己家的平臺（BAT）， 這裡KEVIN主要分享一下關於資料包表中比較特殊的報表形式， 在平常大家常用的：直條圖、扇形圖等， 還有什麼？
特殊之一：桑基圖
桑基圖
主要是表現的每個頁面到達頁面的情況， 以流線的方式表明使用者在頁面之間的路徑。 可以看到使用者進入頁面主要的流動情況。
特殊之二：關於常見的折線圖
折線圖的數量多少問題也是困擾PM資料分析的一個難點，
採取大量PM經驗後， 每組資料建議最多不超過5個點；資料常表現趨勢， 波動。
在這個基礎下能夠良好的展現一些資料的情況， 並且可以結合漏斗圖進行優化。 對於漏斗圖是怎麼樣的？可以參考頁面優化案例（實戰）裡面可以針對如何利用資料進行漏斗設計來進行產品優化的案例。
交互設計的落地思考常識
昨天KEVIN分享了一篇關於交互設計的科普， 沒想到轉發的朋友量還是比較多。 可以知道目前大眾對產品經理與交互的工作內容分界還是比較模糊的。 那麼今天再分享一下關於交互的一些落地常識。
APP頁面的基本佈局
那麼對於一個交互設計， 需要通過在需求分享中獲取使用者的核心內容， 在整個內容區域裡面， 因為使用者是從左到右， 從上到下的關注度逐漸降低。 合適的將相應的核心內容或按鈕放在相應的關注度高的地方。 區分內容區的不同關注級別。
通訊產品中消息清單的產品設計常規
既然說一些產品經理工作的常規，
首先在通訊產品中， 最重要的是消息清單， 消息清單的設計原則到底有什麼基本的共同點？
即時性（快速獲取， 閱讀以及處理）避免產生騷擾（避免消息過於頻繁給使用者帶來騷擾）私密性（防止資訊洩露）另外在通訊產品， 更應該考慮的是：
有獨立消息主tab（使用軟體的核心流程）消息的獲取， 以即時性為最高要求， 越快越好消息組織類型為以通信物件為單位， 內部包含行為資訊（@， 紅包、語音、小視頻）系統通知消息優先順序低於使用者消息使用者敏感資訊進行保護處理產品工具中的卡頓常規知識
對於PM最常用的就是AXURE等工具， 那麼在AXURE工具中，如何避免在大量的原型完成後，出現卡頓的問題呢？這裡KEVIN收集了以下的解決辦法，可以有效的幫助解決卡頓問題
1. 在Axure 單個頁面內不要有太多的 Group，尤其是嵌套的 Group，有次設計師在 Axure7 中的一個頁面打開和操作都巨慢無比，打開檔要花5分鐘，操作就假死三分鐘，經過排查發現就是因為一個模組中適用的 Group 太多了，而且是嵌套 Group過多導致，耐著性子 Ungroup 後操作慢的問題得以解決。
2. Axure 中高清大圖不要太多，大圖太吃記憶體，尤其單個頁面不要太多，如果真的需要放很多高清大圖
建議一：建議二：3. Axure 中中繼器的使用注意複雜度，雖然它的功能是提升效率利器，但是單個頁面內太多且複雜的使用Repeat 功能，也會讓頁面變的很慢，容易出錯。
產品經理在文檔的常規知識文檔的分類
文檔分為：PRD、MRD、技術專業文檔
1、PRD
須瞭解各個產品的使用，很多時候PRD不僅僅是一個產品的文檔，更多的是一個更新項，或者一個模組、甚至最新的一個交互或UI效果，都是需要文檔來說明。
PRD的意義不僅僅是給予開發，還是PM用來作為留底，並且可以作為及時更新的功能模組，最後文檔也是用來時刻與開發作為驗證的證據。
很多時候，PM在除了版本更新以外，在其他模組或者小功能增加的時候沒有文檔，其實KEVIN的習慣是每次都有文檔的更新。
這樣的好處有3點：
需要出UI的話，UI能夠很快知道你的原型相關的描述。測試能夠通過文檔更快的瞭解具體的功能是什麼最後可以在開發後，發現沒有做到自己期望的樣子，可以說“我文檔是這麼寫的”2、MRD
其實MRD的形式有很多，有PPT、EXCEL、WORD，但KEVIN還是以公司的具體需求，比如這個MRD是用來給予客戶或者BOSS看的，那麼這個時候PPT的形式，會更有說服力。
如果這個MRD是用來給予對方審核或保底的，那麼EXCEL或WORD的形式會更加適合。
MRD在產品上線前是比較常用的，能夠讓公司的內部員工或者客戶或投資夥伴知道目前產品的定位和並且能夠知道相關的市場情況。
3、技術申請
以申請當地政府創新指標、或者申請國家技術創新獎等等，都需要文檔。那麼作為某一個產品負責的PM就需要來寫相關的文檔材料。這個因不同的獎項申請有不同的表格形式，因此這個KEVIN認為就是仁者見仁，智者見智了。
文檔中的一些小TIPS
在產品文檔中，KEVIN比較習慣的方式以WORD 標題1、標題2、標題3….等等來進行區分，將功能的方式，來進行梳理。當然有流程圖的，就不僅僅用文字了。
可以用以功能劃分大板塊，大板塊標題醒目；把大板塊簡單拆分，並用小標題區分；用小序號羅列觀點，不要寫成一大段。
統一關鍵字，注意那些是全域的、那些是局部的。全域的內容，KEVIN習慣是以單獨的標題或大綱來進行羅列，方便測試進行校對
某一項需求功能進行描述，描述清楚功能的使用者、使用場景、使用動作與步驟、使用結果。
如：登錄需求：該需求滿足了使用者在未登錄的情況下，觸發相關條件，輸入使用者id及密碼即可完成使用者登錄。
文檔中的交互效果，可以通過交互結果的形式來描寫。例如視頻上傳按鈕預設為橙色，滑鼠劃過時變為橙黃色，滑鼠點下時變為橙紅色；再或者搜索框預設顯示灰色文字“請輸入關鍵字”，獲取焦點後，提示文字消失，輸入的文字為黑色。
PRD文檔大綱
PRD的需求類型分類產品性能需求測試環境需求產品資料統計需求安全性需求產品相容性需求
其中，性能需求可以是指的是目前APP的相應速度、打開相應的按鈕的速度。
測試環境可以如詞意來表示ANDRIOD和IOS。
產品資料統計需求可以指的是埋點、PV、CPC等。
安全性需求指的是產品邏輯中是否有短信驗證，或短信驗證的方式是什麼？是語音提示還是什麼？
產品相容性需求指的是在安卓版本比較多，安卓的版本層次不齊在國內，因此需要支援多少的安卓版本，另外IOS是否要支持最新的IOS等等。
#專欄作家#
本文原創發佈于人人都是產品經理。未經許可，禁止轉載。
那麼在AXURE工具中，如何避免在大量的原型完成後，出現卡頓的問題呢？這裡KEVIN收集了以下的解決辦法，可以有效的幫助解決卡頓問題1. 在Axure 單個頁面內不要有太多的 Group，尤其是嵌套的 Group，有次設計師在 Axure7 中的一個頁面打開和操作都巨慢無比，打開檔要花5分鐘，操作就假死三分鐘，經過排查發現就是因為一個模組中適用的 Group 太多了，而且是嵌套 Group過多導致，耐著性子 Ungroup 後操作慢的問題得以解決。
2. Axure 中高清大圖不要太多，大圖太吃記憶體，尤其單個頁面不要太多，如果真的需要放很多高清大圖
建議一：建議二：3. Axure 中中繼器的使用注意複雜度，雖然它的功能是提升效率利器，但是單個頁面內太多且複雜的使用Repeat 功能，也會讓頁面變的很慢，容易出錯。
產品經理在文檔的常規知識文檔的分類
文檔分為：PRD、MRD、技術專業文檔
1、PRD
須瞭解各個產品的使用，很多時候PRD不僅僅是一個產品的文檔，更多的是一個更新項，或者一個模組、甚至最新的一個交互或UI效果，都是需要文檔來說明。
PRD的意義不僅僅是給予開發，還是PM用來作為留底，並且可以作為及時更新的功能模組，最後文檔也是用來時刻與開發作為驗證的證據。
很多時候，PM在除了版本更新以外，在其他模組或者小功能增加的時候沒有文檔，其實KEVIN的習慣是每次都有文檔的更新。
這樣的好處有3點：
需要出UI的話，UI能夠很快知道你的原型相關的描述。測試能夠通過文檔更快的瞭解具體的功能是什麼最後可以在開發後，發現沒有做到自己期望的樣子，可以說“我文檔是這麼寫的”2、MRD
其實MRD的形式有很多，有PPT、EXCEL、WORD，但KEVIN還是以公司的具體需求，比如這個MRD是用來給予客戶或者BOSS看的，那麼這個時候PPT的形式，會更有說服力。
如果這個MRD是用來給予對方審核或保底的，那麼EXCEL或WORD的形式會更加適合。
MRD在產品上線前是比較常用的，能夠讓公司的內部員工或者客戶或投資夥伴知道目前產品的定位和並且能夠知道相關的市場情況。
3、技術申請
以申請當地政府創新指標、或者申請國家技術創新獎等等，都需要文檔。那麼作為某一個產品負責的PM就需要來寫相關的文檔材料。這個因不同的獎項申請有不同的表格形式，因此這個KEVIN認為就是仁者見仁，智者見智了。
文檔中的一些小TIPS
在產品文檔中，KEVIN比較習慣的方式以WORD 標題1、標題2、標題3….等等來進行區分，將功能的方式，來進行梳理。當然有流程圖的，就不僅僅用文字了。
可以用以功能劃分大板塊，大板塊標題醒目；把大板塊簡單拆分，並用小標題區分；用小序號羅列觀點，不要寫成一大段。
統一關鍵字，注意那些是全域的、那些是局部的。全域的內容，KEVIN習慣是以單獨的標題或大綱來進行羅列，方便測試進行校對
某一項需求功能進行描述，描述清楚功能的使用者、使用場景、使用動作與步驟、使用結果。
如：登錄需求：該需求滿足了使用者在未登錄的情況下，觸發相關條件，輸入使用者id及密碼即可完成使用者登錄。
文檔中的交互效果，可以通過交互結果的形式來描寫。例如視頻上傳按鈕預設為橙色，滑鼠劃過時變為橙黃色，滑鼠點下時變為橙紅色；再或者搜索框預設顯示灰色文字“請輸入關鍵字”，獲取焦點後，提示文字消失，輸入的文字為黑色。
PRD文檔大綱
PRD的需求類型分類產品性能需求測試環境需求產品資料統計需求安全性需求產品相容性需求
其中，性能需求可以是指的是目前APP的相應速度、打開相應的按鈕的速度。
測試環境可以如詞意來表示ANDRIOD和IOS。
產品資料統計需求可以指的是埋點、PV、CPC等。
安全性需求指的是產品邏輯中是否有短信驗證，或短信驗證的方式是什麼？是語音提示還是什麼？
產品相容性需求指的是在安卓版本比較多，安卓的版本層次不齊在國內，因此需要支援多少的安卓版本，另外IOS是否要支持最新的IOS等等。
#專欄作家#
本文原創發佈于人人都是產品經理。未經許可，禁止轉載。