起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識App產品原型背后要交代的細節或要理解的原則（二）
本文接著上一篇《App產品原型背后要交代的細節或要理解的原則（一）》，也是來自工作中的總結和整理。筆者從產品經理設計需求的角度，分享了APP產品原型設計背后需要的注意的細節和原則，供大家參考與學習。
七、產品經理對視頻拍攝窗口的界定
產品經理在設計拍攝視頻或圖片功能的時候，需要考慮是否滿屏拍攝，是否限制必須按一定比例拍攝等。
之所以考慮這個問題，是因為有的手機全屏比例拍攝的效果并不美觀。另外一些帶劉海的手機屏幕，劉海部位必然是看不到拍攝畫面的。
因此為了避免這個影響，很多產品就會選擇將上方平齊與劉海的高度遮住，設置成只支持劉海以下拍攝。
當然，也有將底部菜單位置遮住的，還有的規則是只允許拍攝出指定比例的畫面，比如安寬度固定，取16:9的畫面作為視頻窗口，多余的部分在拍攝期間都用黑色背景遮住。
這種規則的制定有好有壞，屬于A/B選擇的問題。這個選擇，需要產品經理來定。
產品經理可以通過借鑒競品和分析本產品的定位，有理有據地說出自己的理由，支持自己的觀點即可。
八、將低頻功能放深一點，以便將高頻功能凸顯出來
以拍攝視頻后的貼紙為例，貼紙可以貼在視頻的指定位置，也可以應用在視頻的某一時間段上。
但是根據調研，多數用戶使用的功能只是選擇貼紙、刪除貼紙和拖動位置。少數用戶才會花精力在手機上調整貼紙應用的時間段，因為這個操作稍微有點麻煩。
但是畢竟還是有這么一小部分用戶是希望將自己拍攝的作品精益求精的，對此我們看如下方案：
- 方案一：在選擇貼紙的同時就展示出時間軸，讓用戶選擇貼紙和應用的時間軸一次性完成。讓功能集中在一處開始和結束，干凈利索；
- 方案二：將選擇貼紙、刪除貼紙和拖動位置放在第一層。完成之后，再點擊該貼紙，彈出‘編輯’，這才進入時間軸的編輯。
很明顯第二個方案要好一些，一來提高了大部分用戶的操作效率，不被無關的功能干擾；另外也不會影響發燒用戶進一步挖掘極致。
這其實是整個產品設計的指導思想：考慮了復雜性和使用頻率，針對大眾用戶和極致用戶進行功能分離，最終實現完美的效果。
九、圖片上傳、壓縮等需要注意的細節
圖片上傳是APP離不開的功能，比如聊天消息、上傳照片做認證或頭像等。
提到圖片上傳，就離不開上傳的規制、發送或上傳成功的效果、點擊后的效果、發布失敗的效果、下載到本地的效果等。具體可以這樣分析：
（1）上傳的圖片文件大小和尺寸大小的要求：
在服務器承受的壓力之內盡量不做限制，必要的時候才給予閾值。作為產品經理，需要與開發溝通當前的方案選項是否有限制的必要。一般而言，可以由客戶端自行壓縮或調整后展示。
對于PRD，給不給上述限制都要交代清楚。
（2）限制一次上傳的圖片張數：
比如微信是9張，抖音12張。對于PRD，該限制雖小，但要交代清楚。
（3）上傳的圖片限制格式：
一般盡量不限制。作為產品經理，需要與開發溝通當前的方案選項是否有限制的必要。對于PRD，要交代清楚。
（4）上傳圖片后展示的效果：
一般都是縮略圖，固定顯示的長寬高。
上傳失敗的圖片，支持再次上傳。
點擊上傳成功的圖片，打開大圖。
（5）若需要該圖片進行小圖標或者展示形式的多樣化應用，則后臺只需要保存原圖，其余的格式化應用在客戶端進行定義。
比如頭像圖片在后臺存一張大圖，應用層面展示的是原型圖。又比如送禮物的圖標，選擇的界面展示的是大圖，發出去之后的消息通知可能就只是個小圖標。
（6）圖片上傳的方式：
①第一種是九宮格式的
典型的就是微信發朋友圈的圖片上傳功能，這種圖片上傳功能適合上傳多張圖片，圖片的呈現方式一般都是九宮格的方式，在社交類、電商類的商品上傳和寫游記的app上多見；
多用于信息內容的展示，一般都是圖文相結合。一般是先開啟相冊選取圖片，圖片的點擊順序也一般是最后的呈現順序。
②第二種文件上傳式
一般在聊天界面會用到這個功能居多，點擊qq和微信下方工具欄的加號都會有一個圖片上傳的功能，這種功能一般是基于聊天的場景；
這部分圖片上傳功能展開的方式都是半浮窗的樣式，系統會先展示當前相冊最近的幾張圖片，會有選擇是否發原圖的設計。
③第三種嵌入式圖片上傳
嵌入式圖片上傳一般應用在文檔撰寫類的應用，在編寫文章的時候需要嵌入一些圖片說明；
這種設計時圖片嵌入屬于一種輔助文檔編輯的功能，一般需要去調取系統相冊，然后手動從相冊里選取出你所需要的圖片，可一次性上傳多張圖片。
④第四種添加附件
這種圖片上傳形式一般圖片會作為附件的形式上傳，也是調取系統相冊，一般上傳成功后圖片都是縮略圖的形式展示。
例如我們常用的寫周報和百度云盤里就常用到這個功能。這種設計的圖片上傳功能適合大批量的圖片上傳。
十、時間格式的定義
時間的顯示基本分兩類，一類是展示在外層的，不需要很精準的時間，比如聊天環境下的時間、用戶動態外層顯示的時間；另一種作為嚴格的時間落款，比如賬單明細。
后者基本可以一刀切，就用年月日時分秒，一般都不是問題。
前者就要切合場景，對時間的要求和用戶情感的匹配性，融入一定的感情色彩或者暗示。
這里就有多種流派，比如推特和微信就區別很大。
對于前者，筆者在這里整理一套自己用于聊天信息、評論、系統消息、動態的時間的展示規則，可以作為借鑒：
- 剛剛（T<1分鐘）；
- XX分鐘前（1≤T<1h），比如53分鐘前；
- XX小時前（1h≤T<24h），比如23小時前；
- 昨天 +點鐘（24h≤T<48h），比如 昨天 12：20。
- 日期+點鐘（48h≤T<1年） 比如：6-5 14:52，跨年則加上年 2018-12-9 16:21
- 年-月（1年≤T） 比如：2018-5
#相關文章#
作者：唧唧歪歪PM；公眾號：唧唧歪歪PM（ID：jjyypm）
本文由 @唧唧歪歪PM 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
牛逼
好文章，新手很受用，感謝
現在已經看完第二篇了，希望大佬繼續更新這個系列得文章，分享更多的類似經驗
同感
支持，坐等下一章
周末發
111