'App產品原型背後要交代的細節和要理解的原則（一）'
"筆者從產品經理設計需求的角度，分享了APP產品原型設計背後需要的注意的細節和原則，供大家參考與學習。
筆者從產品經理設計需求的角度，分享了APP產品原型設計背後需要的注意的細節和原則，供大家參考與學習。
移動App的產品設計往往都是所見即所有，沒有太深奧的邏輯要交代的，比葫蘆畫瓢即可。
產品經理常常很快就把原型畫出完了，但是在設計UI的時候或開發的時候就常常被拉去澄清細節，原因就是對設計的細節交代不清楚，或者瞭解的不甚深入，缺少對邊界或排他項的界定。
筆者近期從事社交App的需求，本文就移動端App產品的日常總結，從產品經理設計需求的角度，分享一些注意事項和細節如下，歡迎批評探討。
一、明確App的按鈕類型
從定義需求的角度來說，產品經理只要交代了哪裡是按鈕就可以了，可以通篇一律使用同一個按鈕線框表達。但是這隻能是個初稿，在落實之前，產品經理或交互設計師需要確定按鈕的具體形態。
一般而言，一個APP的按鈕設定四種就夠了，設置的維度可以是按鈕的定位權重（注意，菜單的入口或圖表不包括在本次討論中，比如微信的+、定位圖標這種）。
- 權重最高的按鈕：這種按鈕一般比較大，顏色明顯，主題鮮明。常見的比如用戶“登錄”按鈕；
- 中等權重的按鈕：這種按鈕在產品中最為常見，比如一般的詢問框上的【確定/取消】按鈕；
- 權重最小的按鈕：比如“關閉”、“查看更多”按鈕。這些按鈕的作用就是可以點擊，用戶看得到即可。這種按鈕形式多樣，可以沒有框，只有文字。也可以只是個圖形，比如關閉按鈕用x表示；
- 特殊按鈕，這種按鈕區別於其他的按鈕，少且特別。要麼是帶很多文字，要麼是App的核心入口，比如soul首頁的“靈魂匹配”按鈕。
筆者從產品經理設計需求的角度，分享了APP產品原型設計背後需要的注意的細節和原則，供大家參考與學習。
移動App的產品設計往往都是所見即所有，沒有太深奧的邏輯要交代的，比葫蘆畫瓢即可。
產品經理常常很快就把原型畫出完了，但是在設計UI的時候或開發的時候就常常被拉去澄清細節，原因就是對設計的細節交代不清楚，或者瞭解的不甚深入，缺少對邊界或排他項的界定。
筆者近期從事社交App的需求，本文就移動端App產品的日常總結，從產品經理設計需求的角度，分享一些注意事項和細節如下，歡迎批評探討。
一、明確App的按鈕類型
從定義需求的角度來說，產品經理只要交代了哪裡是按鈕就可以了，可以通篇一律使用同一個按鈕線框表達。但是這隻能是個初稿，在落實之前，產品經理或交互設計師需要確定按鈕的具體形態。
一般而言，一個APP的按鈕設定四種就夠了，設置的維度可以是按鈕的定位權重（注意，菜單的入口或圖表不包括在本次討論中，比如微信的+、定位圖標這種）。
- 權重最高的按鈕：這種按鈕一般比較大，顏色明顯，主題鮮明。常見的比如用戶“登錄”按鈕；
- 中等權重的按鈕：這種按鈕在產品中最為常見，比如一般的詢問框上的【確定/取消】按鈕；
- 權重最小的按鈕：比如“關閉”、“查看更多”按鈕。這些按鈕的作用就是可以點擊，用戶看得到即可。這種按鈕形式多樣，可以沒有框，只有文字。也可以只是個圖形，比如關閉按鈕用x表示；
- 特殊按鈕，這種按鈕區別於其他的按鈕，少且特別。要麼是帶很多文字，要麼是App的核心入口，比如soul首頁的“靈魂匹配”按鈕。
在輸出的需求文檔中，可以一開始在“全局規範”中就定義這四種按鈕代號，然後在原型中備註按鈕類型的代號，這樣設計就知道你是要怎麼樣的效果了。
二、瞭解第三方登錄的本質
社交類App登錄方式，基本都是手機驗證碼為主，配合第三方登陸，很少註冊賬號密碼（與App的定位和用戶群有關）。
第三方登錄就是藉助第三方應用的接口實現用戶登記，比如常見的三家：微信、QQ、微博。
其目的之一是關聯賬號，形成社交群落之間的呼應，有利於用戶生態鏈的搭建；其二是獲取用戶的一部分已有信息，比如用戶信息或流量資源。
需要注意的有兩點：
- 第三方賬號給的資料完善度和安全性不好把控。比如你期望獲取QQ中的頭像、暱稱、年齡、地區，但是QQ可能只給你頭像和暱稱。又比如有一天第三方封了接口，那麼第三方登錄功能就停擺了；
- 第三方登錄方式，對用戶來說不一定就是省時省力的渠道。因為相關法規的要求很多APP是需要用戶手機號的，而第三方登錄並不能獲取用戶已經提供給第三方的手機號（用戶隱私）。
因此對用戶來說常常是使用第三方登錄後，仍然要跳轉到驗證手機號的界面，還不如直接使用手機驗證登錄。
三、我們常見的支付功能的貓膩
支付很常見，社交應用的虛擬禮物購買、知識平臺的付費學習等。
在設計支付功能的時候，主要注意的是要從安卓和IOS兩個系統的角度區分設計。
（1）首先明確一個常識，就是支付必須是有資質的支付平臺才能進行操作處理。這就是為什麼很多大的電商公司的交易要經過支付公司的結算才能拿到錢，比如paypal、騰付通、支付寶、微信支付、網銀在線等。其中安卓手機最常用的是支付寶或者微信；
（2）安卓系統接通第三方支付體系還是比較友好的，手續費也不高。調用支付寶或微信支付，會返回其綁定的銀行卡或者餘額，可以作為業務數據保存在後臺。有時候前端感受不到這個數據，產品經理應該知道，作為功能擴展的考慮因素；
（3）蘋果手機（IOS系統）正常來說只能調用蘋果支付，蘋果順帶扣的手續費比較高。虛擬支付的時候，安卓是可以使用任意金額充值的，但是蘋果手機對特定的原幣，只能選擇固定的金額。這個是因為蘋果公司將充值金額本身固定了，當成一個一個的商品對外出售。
如下圖就是蘋果提供的清單，比如可以購買的價格列就是需要支付的金額，收入列就是扣掉手續費之後有效的金額。可以看到花6元錢，在蘋果這裡只剩下了4.12元。
"筆者從產品經理設計需求的角度，分享了APP產品原型設計背後需要的注意的細節和原則，供大家參考與學習。
移動App的產品設計往往都是所見即所有，沒有太深奧的邏輯要交代的，比葫蘆畫瓢即可。
產品經理常常很快就把原型畫出完了，但是在設計UI的時候或開發的時候就常常被拉去澄清細節，原因就是對設計的細節交代不清楚，或者瞭解的不甚深入，缺少對邊界或排他項的界定。
筆者近期從事社交App的需求，本文就移動端App產品的日常總結，從產品經理設計需求的角度，分享一些注意事項和細節如下，歡迎批評探討。
一、明確App的按鈕類型
從定義需求的角度來說，產品經理只要交代了哪裡是按鈕就可以了，可以通篇一律使用同一個按鈕線框表達。但是這隻能是個初稿，在落實之前，產品經理或交互設計師需要確定按鈕的具體形態。
一般而言，一個APP的按鈕設定四種就夠了，設置的維度可以是按鈕的定位權重（注意，菜單的入口或圖表不包括在本次討論中，比如微信的+、定位圖標這種）。
- 權重最高的按鈕：這種按鈕一般比較大，顏色明顯，主題鮮明。常見的比如用戶“登錄”按鈕；
- 中等權重的按鈕：這種按鈕在產品中最為常見，比如一般的詢問框上的【確定/取消】按鈕；
- 權重最小的按鈕：比如“關閉”、“查看更多”按鈕。這些按鈕的作用就是可以點擊，用戶看得到即可。這種按鈕形式多樣，可以沒有框，只有文字。也可以只是個圖形，比如關閉按鈕用x表示；
- 特殊按鈕，這種按鈕區別於其他的按鈕，少且特別。要麼是帶很多文字，要麼是App的核心入口，比如soul首頁的“靈魂匹配”按鈕。
在輸出的需求文檔中，可以一開始在“全局規範”中就定義這四種按鈕代號，然後在原型中備註按鈕類型的代號，這樣設計就知道你是要怎麼樣的效果了。
二、瞭解第三方登錄的本質
社交類App登錄方式，基本都是手機驗證碼為主，配合第三方登陸，很少註冊賬號密碼（與App的定位和用戶群有關）。
第三方登錄就是藉助第三方應用的接口實現用戶登記，比如常見的三家：微信、QQ、微博。
其目的之一是關聯賬號，形成社交群落之間的呼應，有利於用戶生態鏈的搭建；其二是獲取用戶的一部分已有信息，比如用戶信息或流量資源。
需要注意的有兩點：
- 第三方賬號給的資料完善度和安全性不好把控。比如你期望獲取QQ中的頭像、暱稱、年齡、地區，但是QQ可能只給你頭像和暱稱。又比如有一天第三方封了接口，那麼第三方登錄功能就停擺了；
- 第三方登錄方式，對用戶來說不一定就是省時省力的渠道。因為相關法規的要求很多APP是需要用戶手機號的，而第三方登錄並不能獲取用戶已經提供給第三方的手機號（用戶隱私）。
因此對用戶來說常常是使用第三方登錄後，仍然要跳轉到驗證手機號的界面，還不如直接使用手機驗證登錄。
三、我們常見的支付功能的貓膩
支付很常見，社交應用的虛擬禮物購買、知識平臺的付費學習等。
在設計支付功能的時候，主要注意的是要從安卓和IOS兩個系統的角度區分設計。
（1）首先明確一個常識，就是支付必須是有資質的支付平臺才能進行操作處理。這就是為什麼很多大的電商公司的交易要經過支付公司的結算才能拿到錢，比如paypal、騰付通、支付寶、微信支付、網銀在線等。其中安卓手機最常用的是支付寶或者微信；
（2）安卓系統接通第三方支付體系還是比較友好的，手續費也不高。調用支付寶或微信支付，會返回其綁定的銀行卡或者餘額，可以作為業務數據保存在後臺。有時候前端感受不到這個數據，產品經理應該知道，作為功能擴展的考慮因素；
（3）蘋果手機（IOS系統）正常來說只能調用蘋果支付，蘋果順帶扣的手續費比較高。虛擬支付的時候，安卓是可以使用任意金額充值的，但是蘋果手機對特定的原幣，只能選擇固定的金額。這個是因為蘋果公司將充值金額本身固定了，當成一個一個的商品對外出售。
如下圖就是蘋果提供的清單，比如可以購買的價格列就是需要支付的金額，收入列就是扣掉手續費之後有效的金額。可以看到花6元錢，在蘋果這裡只剩下了4.12元。
這就是為什麼陌陌同樣是充值6塊錢，安卓系統給60個虛擬幣，蘋果只給42個幣。
四、瞭解後臺數據的存儲
做APP的不僅要盯住頁面和用戶，也要理解數據的運作，這樣對內容推送機制、數據搜索的頁面展示的方案選型幫助很大。
這裡介紹三點：
（1）初創公司的數據基本都使用的雲端存儲，同時配合自己的數據庫，從效率和安全性上都會更有保障。
產品經理需大概瞭解數據存儲的定位。以視頻直播類為例，直播或視頻數據文件佔存比較大，一般都是存儲在雲端的，而用戶業務數據放在自己的服務器的數據庫中，原因很簡單這些牽扯更多的隱私和安全責任，且一般數據不會太多。
（2）產品經理需直觀地理解關係型數據庫和非關係型數據庫，比如非關係型的mongdb數據庫，一般存儲信息量大的不定型數據，比如用戶日誌。
而MySQL則承擔了大部分可以用二維表表達的規則的數據，比如用戶資料、數據字典的參數配置等。
（3）數據存儲與頁面的搜索方式等方面都有很大關係。比如，在“我的好友”中搜索用戶暱稱，是隻搜索自己關係為好友的用戶，還是搜出有一部分是好友，另一部分非好友的用戶並用標籤分類呢？
這兩個方案前者比較保守，但是如果期望用戶擴大社交圈的話後者更有價值。因為不僅可以看到好友，並且還能提供增加陌生人為好友的功能。
但是這時候還要結合後臺數據的存儲，是否好友和陌生人存儲在一個表裡了呢，如果分開了那最好就不要一起搜索，隨著用戶量增大，聊表查詢很耗性能。
五、瞭解前後端接口
項目過程中，前端與後端開發之間溝通需求基本都是圍繞接口請求數據進行的。
接口是前後端分開開發的行業標配嗎，是高內聚的體現。因此產品經理要理解接口的原理和自己的目的，協助前後端完善接口的定義（另一篇文章有專門介紹）。
後端開發在寫接口的時候，一般需要知道未來的走向，包括數據量級、功能擴展性等。
產品經理要針對該功能給開發們說清楚未來的擴展可能性，比如：App的用戶動態的評論，計劃是展示一部分優質評論內容（類似微信的朋友圈）在外層，類似下圖：
"筆者從產品經理設計需求的角度，分享了APP產品原型設計背後需要的注意的細節和原則，供大家參考與學習。
移動App的產品設計往往都是所見即所有，沒有太深奧的邏輯要交代的，比葫蘆畫瓢即可。
產品經理常常很快就把原型畫出完了，但是在設計UI的時候或開發的時候就常常被拉去澄清細節，原因就是對設計的細節交代不清楚，或者瞭解的不甚深入，缺少對邊界或排他項的界定。
筆者近期從事社交App的需求，本文就移動端App產品的日常總結，從產品經理設計需求的角度，分享一些注意事項和細節如下，歡迎批評探討。
一、明確App的按鈕類型
從定義需求的角度來說，產品經理只要交代了哪裡是按鈕就可以了，可以通篇一律使用同一個按鈕線框表達。但是這隻能是個初稿，在落實之前，產品經理或交互設計師需要確定按鈕的具體形態。
一般而言，一個APP的按鈕設定四種就夠了，設置的維度可以是按鈕的定位權重（注意，菜單的入口或圖表不包括在本次討論中，比如微信的+、定位圖標這種）。
- 權重最高的按鈕：這種按鈕一般比較大，顏色明顯，主題鮮明。常見的比如用戶“登錄”按鈕；
- 中等權重的按鈕：這種按鈕在產品中最為常見，比如一般的詢問框上的【確定/取消】按鈕；
- 權重最小的按鈕：比如“關閉”、“查看更多”按鈕。這些按鈕的作用就是可以點擊，用戶看得到即可。這種按鈕形式多樣，可以沒有框，只有文字。也可以只是個圖形，比如關閉按鈕用x表示；
- 特殊按鈕，這種按鈕區別於其他的按鈕，少且特別。要麼是帶很多文字，要麼是App的核心入口，比如soul首頁的“靈魂匹配”按鈕。
在輸出的需求文檔中，可以一開始在“全局規範”中就定義這四種按鈕代號，然後在原型中備註按鈕類型的代號，這樣設計就知道你是要怎麼樣的效果了。
二、瞭解第三方登錄的本質
社交類App登錄方式，基本都是手機驗證碼為主，配合第三方登陸，很少註冊賬號密碼（與App的定位和用戶群有關）。
第三方登錄就是藉助第三方應用的接口實現用戶登記，比如常見的三家：微信、QQ、微博。
其目的之一是關聯賬號，形成社交群落之間的呼應，有利於用戶生態鏈的搭建；其二是獲取用戶的一部分已有信息，比如用戶信息或流量資源。
需要注意的有兩點：
- 第三方賬號給的資料完善度和安全性不好把控。比如你期望獲取QQ中的頭像、暱稱、年齡、地區，但是QQ可能只給你頭像和暱稱。又比如有一天第三方封了接口，那麼第三方登錄功能就停擺了；
- 第三方登錄方式，對用戶來說不一定就是省時省力的渠道。因為相關法規的要求很多APP是需要用戶手機號的，而第三方登錄並不能獲取用戶已經提供給第三方的手機號（用戶隱私）。
因此對用戶來說常常是使用第三方登錄後，仍然要跳轉到驗證手機號的界面，還不如直接使用手機驗證登錄。
三、我們常見的支付功能的貓膩
支付很常見，社交應用的虛擬禮物購買、知識平臺的付費學習等。
在設計支付功能的時候，主要注意的是要從安卓和IOS兩個系統的角度區分設計。
（1）首先明確一個常識，就是支付必須是有資質的支付平臺才能進行操作處理。這就是為什麼很多大的電商公司的交易要經過支付公司的結算才能拿到錢，比如paypal、騰付通、支付寶、微信支付、網銀在線等。其中安卓手機最常用的是支付寶或者微信；
（2）安卓系統接通第三方支付體系還是比較友好的，手續費也不高。調用支付寶或微信支付，會返回其綁定的銀行卡或者餘額，可以作為業務數據保存在後臺。有時候前端感受不到這個數據，產品經理應該知道，作為功能擴展的考慮因素；
（3）蘋果手機（IOS系統）正常來說只能調用蘋果支付，蘋果順帶扣的手續費比較高。虛擬支付的時候，安卓是可以使用任意金額充值的，但是蘋果手機對特定的原幣，只能選擇固定的金額。這個是因為蘋果公司將充值金額本身固定了，當成一個一個的商品對外出售。
如下圖就是蘋果提供的清單，比如可以購買的價格列就是需要支付的金額，收入列就是扣掉手續費之後有效的金額。可以看到花6元錢，在蘋果這裡只剩下了4.12元。
這就是為什麼陌陌同樣是充值6塊錢，安卓系統給60個虛擬幣，蘋果只給42個幣。
四、瞭解後臺數據的存儲
做APP的不僅要盯住頁面和用戶，也要理解數據的運作，這樣對內容推送機制、數據搜索的頁面展示的方案選型幫助很大。
這裡介紹三點：
（1）初創公司的數據基本都使用的雲端存儲，同時配合自己的數據庫，從效率和安全性上都會更有保障。
產品經理需大概瞭解數據存儲的定位。以視頻直播類為例，直播或視頻數據文件佔存比較大，一般都是存儲在雲端的，而用戶業務數據放在自己的服務器的數據庫中，原因很簡單這些牽扯更多的隱私和安全責任，且一般數據不會太多。
（2）產品經理需直觀地理解關係型數據庫和非關係型數據庫，比如非關係型的mongdb數據庫，一般存儲信息量大的不定型數據，比如用戶日誌。
而MySQL則承擔了大部分可以用二維表表達的規則的數據，比如用戶資料、數據字典的參數配置等。
（3）數據存儲與頁面的搜索方式等方面都有很大關係。比如，在“我的好友”中搜索用戶暱稱，是隻搜索自己關係為好友的用戶，還是搜出有一部分是好友，另一部分非好友的用戶並用標籤分類呢？
這兩個方案前者比較保守，但是如果期望用戶擴大社交圈的話後者更有價值。因為不僅可以看到好友，並且還能提供增加陌生人為好友的功能。
但是這時候還要結合後臺數據的存儲，是否好友和陌生人存儲在一個表裡了呢，如果分開了那最好就不要一起搜索，隨著用戶量增大，聊表查詢很耗性能。
五、瞭解前後端接口
項目過程中，前端與後端開發之間溝通需求基本都是圍繞接口請求數據進行的。
接口是前後端分開開發的行業標配嗎，是高內聚的體現。因此產品經理要理解接口的原理和自己的目的，協助前後端完善接口的定義（另一篇文章有專門介紹）。
後端開發在寫接口的時候，一般需要知道未來的走向，包括數據量級、功能擴展性等。
產品經理要針對該功能給開發們說清楚未來的擴展可能性，比如：App的用戶動態的評論，計劃是展示一部分優質評論內容（類似微信的朋友圈）在外層，類似下圖：
但是對於展開部分的算法尚還在研究階段，因此這個版本將評論摺疊，只顯示數字，點開則打開評論列表。
後端在給前端傳的接口中，可能會多設計出“是否展示在外層”標識，提前預留參數，以後版本用。本版本前端只需填留下自己需要的信息即可。
六、圖片比例、圓角和縮放的注意事項
App用到圖片的地方很多，每一處又可能有不同狀態下的不同表現形式。產品經理不能只放一張圖了事，應當對圖片不同場景下的樣式列舉清楚。比如下面幾點：
1. 縮略圖的縮放比例
微信朋友圈的列表中，圖片都是縮略的，那麼設計的時候首先就是縮略方式的問題。
之所以要給出縮小的比例或最終尺寸大小，是因為拍攝的手機屏幕尺寸和比例不一致，上傳的圖片又可能有各種形狀。因此發佈之後要給予對應的規則和秩序，避免效果模糊、展示不全、圖片過小等不良效果。
在確定方案的時候，合理即可。可以通過研究競品，找近期流行的產品的規律。
比如按圖片或視頻的H:W:
- H:W>4/3(高圖）：切上下兩端，保存為4/3，靠左展示；
- 3/4≤(H:W)<4/3之間(方圖）：切成正方形，靠中間展示；
- H:W≤3/4(扁圖）：切成3/4，靠中間展示。
以上並不一定是最好的，但是秩序是要給到開發的。
2. 圖片的圓角和直角
留意的話，就會發現有的App的圖片是圓角的有的是直角的。目的只有一個，就是確定這兩種展示方式哪種更符合產品的定位和氣質。
一般而言，做社交類的產品，圖片用圓角看著舒服和氣；做技術類的或者法律類的比較嚴肅的產品，可以考慮直角。
最後還是一句話，看競品，以及一段時間流行哪種。
3. 大圖和縮略圖
消息發送成功之後 ，圖片也是縮略的，並且要設計發送失敗的提示圖例。
點擊打開之後大圖是否鋪滿整個窗口？最後就是不要忘記做縮略圖和大圖，這是完整的一套。
另外在很多公司，這個算是設計師方面的工作，但是產品經理要全局把關，就要知其然知其所以然，不是主管覺得看著順眼就就這樣。
作者：jjyypm；公眾號：唧唧歪歪PM（ID：jjyypm）
來源：https://mp.weixin.qq.com/s/sDRuzJW7GSGGH6YC17Bb5w
本文由 @唧唧歪歪PM 授權發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議
"