中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

作者根據自身的經驗，描述了自己制作一款產品的主要過程，從中總結了一些經驗方法與大家分享。

無論是C端還是公司內部用戶，都可能會有數據統計的需求。我個人認為，單從產品層面上看，數據類的需求其實并非需要特殊的思路去解決，仍然和其他解決需求時的方法一致。唯一區別在于內容交互、布局方面，數據內容與其他圖文內容的不同，大多體現在突出數據的查閱體驗。

去年時做了一個公司內部數據統計的APP項目，整個項目前端并不復雜（但在后端幾乎把整個電商部門的后臺數據倒騰了個遍），這次給大家分享的整個項目中產品層面的一些經歷、復盤總結。

用戶的場景、需求

用戶群角色

首先思考的是我接手的這個項目是面向哪些群體的，在需求討論會上，我見到了各個業務部門的人，從職位角度歸納了一下，大體上可以分為：銷售部（總部&地方）、B端客戶部（總部&地方）、總部領導、地方分總等角色。為何從這個角度予以區分呢？是因為兩點：1、公司內部一般而言職位相同，對數據的需要就會非常相近。2、公司后臺中普遍使用的是這種角色區分維度，容易和后臺底層接軌。

然后，不同的角色，意味著對數據的需求、權限是不同的。

用戶群的需求

需求采集：由于是公司內部人使用，所以采集這類數據需求的方式就是比較簡單直接，開會、私下郵件、當面討論，即可確定下具體的數據需求項了。遇到大家不一致的地方，會把不一致的人員拉上來，開會進行討論、辯證的分析：哪些數據是有意義的，有必要的，哪些是不需要的，可以初版不做，后期討論的。

需求采集其實就是確定需求范圍，比較類似于“體驗五要素”中的“范圍層”。

需求分析：其實在采集的過程中，多多少少能夠感覺到需求方對數據項的重視程度了。再加上格外的需求分析這個階段：對所需的數據進行重要程度分析、實現難度分析（也會和技術進行討論），經過這一系列的分析，基本上心中大體有數了。哪些高頻重要的、哪些低頻次要的，哪些簡單可做、哪些復雜延后……

需求決斷：需求分析的結果一定是需求的判斷、抉擇，這也是分析的目的、意義。判斷、抉擇異常重要，它關系著后續產品經理跟進項目的整個大局。決斷的結果，就幾乎定下了后續產品經理需要多大的精力、成本去跟進項目的進展，項目周期多長，是否能滿足領導的上線需求。所以，產品經理不妨也站在自己的角度上，該砍的需求，要毫不留情；該做的需求，要有心理準備；該豁出去時，要豁出去（頂著壓力，短時間內加班加點完成項目）。

需求管理：數據這類需求，非常需要對其進行有條理的維護、管理，最好詳細的列一個表格，記錄數據的類別、邏輯含義、重要程度，面向角色，調取來源。這樣的好處在于，以后數據出現問題，可以很好的翻箱檢查，也可以在此基礎上進行優化、迭代版本。例如：我個人的這次項目中最終確定下來的需求包括：樓盤項目數據、客源數據、財務相關數據。

系統層面的考慮

1、為了靈活配置數據指標，需要權限系統予以支持?？梢詫⒃摴δ芗{入后臺統一的權限管理系統中，不需要多余的開發。

2、由于大家需求不同，所以在權限中全部列出全部的需求數據項，然后業務人員為每一個角色進行勾選。

這樣做的好處就是大大的提高了為角色配置數據指標的靈活度，另外就是減少了產品、研發的維護成本，勾選權限的任務交給業務部門來做。

功能流程、頁面結構

整個需求階段走完后，那么就是頁面的流程、結構了。這個階段強調的是把決斷后的需求內容轉化成一個可視化的流程、架構。這個階段非常類似“體驗五要素”中的“結構層”，但我個人的描述要比這個“結構層”更實用一些，更具有實踐性（王婆賣瓜，自賣自夸?:-D）。

在這里，我想自問自答一下：為什么要把功能流程和頁面結構放在一起思考？其實我個人理解，流程和頁面是密不可分的。如果僅僅是腦中構思，一般而言可能是一個形象化的構思過程：把功能的入口放在哪里？先操作什么再操作什么？這樣便捷度如何？整體流程亂不亂？頁面跳轉的多不多等等。功能流程必定會和頁面結構息息相關。兩者分開的話，容易思路不完整；綜合考慮這兩點，會更靈活、更快捷、全面。

重要思路過程：

1、如果功能流程較多，可以畫一下流程圖。先畫流程圖，理清了功能步驟，有哪些頁面大體也就會應運而生。如果還不能想象出頁面，那么就再細化流程，直到細化到—這段流程就是一個頁面的程度，不信頁面的感覺出不來（:-D）。

2、大體頁面的形成后，就是把頁面進行組織、構架起來，形成：首頁、列表頁、專題頁、詳情頁、結尾頁、個人中心等等，也就初步勾勒出了頁面結構。

思路的重點：

1、重要的、核心的功能流程是什么？頁面上要予以突顯出來。先構架出這個核心流程的頁面。

2、功能流程轉化為頁面的思考順序，一般無非是：入口、列表、詳情、結尾、個人中心。具體的要具體分析。也會有些大類別的獨立頁面，例如：天貓，京東，有很多的類別是有獨立的匯聚頁。

3、需求的關聯性，也會影響到功能流程、頁面結構。如果需求是關聯性強，那么頁面結構上可能會更密切。反之亦然。例如：電商中的購物流程，社區分享流程。兩大功能雖然都是用戶需求，但兩者關聯性不強，可以互相獨立一些，沒必要流程、頁面交錯一起。

我個人的數據統計APP的功能流程和頁面結構，比較簡單，就是“入口、列表、詳情”，涉及到后臺的是權限管理界面。這個是現成的，只要加內容即可。

內容的交互、布局

這個階段非常類似“體驗五要素”中的“框架層”。在這里，就不過多的描述啦，相信大家都看過“體驗五要素”中對這段的描述。另外，其實我個人有時習慣把這個階段和功能流程、頁面結構一起考慮，具體看個人吧，也看具體的項目量。

對于我個人的數據統計APP的項目，我也不做交互、布局層面的原由、邏輯分析了。把之前做的保真原型圖，直接放上來：

下圖是“數據統計列表頁”， ?功能定位：對所有關鍵指標一目了然，點擊可進詳情頁。

下圖是“指標詳情頁”，功能定位：通過走勢圖、不同維度排行榜，展示某一指標的全部信息。

下圖還是“指標詳情頁”， ?增加一個時間的交互，快捷日期選擇一步到位：

本次就到這兒了，把所有的干貨都拿了出來。大家有什么不同觀點希望在評論中討論一下。

同時歡迎閱讀我的相關文章，值得你來~

本文由 @中人PM 原創發布于人人都是產品經理。未經許可，禁止轉載。