產品經理乾貨，APP建摸——一套描述app的方法論

標籤：style   http   color   ar   os   使用   sp   資料   on   

　　需求到原型是跳躍的，本文重點論述中間被忽略的過渡層，提出一套明確的方法論。首先描述“實體”，然後描述實體之間的關係，最後描述實體的組織呈現。這樣就能非常深刻的去理解一個app了。

　　引子一：

　　一個產品的生命週期中需要產出MRD(市場需求文檔)，然後根據市場需求文檔畫出產品原型圖並輸出PRD(產品需求文檔)。在許多產品經理教程或者書籍裡，大家肯定沒少看到與需求、原型相關的論述，不過在工作實踐中往往會感覺“從需求到原型”還是跳躍的，僅僅明確需求就去構造產品原型會不清晰，中間需要做很多的過渡工作，只是這些工作不像明確需求與建立原型那樣被廣泛提及，它們並沒有一套明確的方法論。正是因為需求到原型存在“斷層”，而之間的過渡體並沒有被提出明確的概念，因此筆者將在此文中來論述如何在需求與原型之間搭建起一座橋樑，這個“橋樑”是如何工作的，從而順暢產品原型的輸出。

　　引子二：

　　一個極客使用者(需要深度體驗各類app的產品經理就算這類使用者)需要來回翻轉整個app來理解這個app的設計理念和機制，因為沒有明確的方法論去告訴我們怎樣去深度體驗app，很多時候大家會感到迷茫和低效。這是因為我們往往抓其一隅，陷在細節裡不可自拔，只有當你有意識從全域上去分析整個系統的設計，從app的各種頁面去構建出一個邏輯架構圖的時候，你才開始“玩轉”這個app。那麼，有沒有一套方法可以協助我們迅速在大腦中建立app模型?答案是可以有，我們要做的就是翻轉頁面，然後把這些頁面解構、重組，形成一個邏輯(功能)架構圖。當你的大腦中有了這樣一個整體的概念，再細入到每一個具體頁面的時候，你看到的不再只是這個頁面，你會知道它處於整體的哪一個位置，它在整個app中扮演了怎樣的一個角色，它與其他頁面之間的邏輯關係是如何的。

　　儘管這兩個引子切入角度不同，但是大家可以發現它們在描述同一個事實：我們需要一套方法論去為app建模，從而協助我們去更好的理解、設計app產品。這種描述一方面在設計的時候為需求與原型之間做緩衝，另一方面在準備深度體驗app的時候，能真正從全域上去理解該app的設計思想，而不僅僅是“只見樹木不見森林”。

　　“他山之石可以攻玉”，筆者受到UML類圖以及資料庫原理E-R(實體-關係)圖的啟發，發現採用類似方式去描述一個app的邏輯架構非常的有效。首先從概念上來說，app的“實體關聯模型”就是把app理解成有許多不同的實體組成，而且這些實體之間又有各種關係，實體們相互影響相互變化。具體的頁面就是把不同的實體按一定規則的呈現，而頁面之間的關係也透露出各個實體之間的關係。所以，描述一個app就是首先描述“實體”，然後描述實體之間的關係，最後描述實體的組織呈現。這樣就能非常深刻的去理解一個app了。當然沒有聽明白的小夥伴們也不要緊，下面筆者用一個執行個體(網易雲音樂app)去說明怎樣使用實體-關係的方式去為一個app建模。

　　描述實體

　　實體可以理解成“概念類”，比如在網易雲音樂中我們可以抽象出這些“概念”實體：歌曲、歌單、使用者、歌手、專輯、DJ節目。下面舉一個歌單實體的例子，

　　歌單實體中的變數描述了歌單是由哪些元素組成，一個歌單擁有歌單名、封面、介紹與評論。當然一個歌單也會有建立者、屬於此歌單的歌曲與收藏該歌單的使用者這些元素，不過它們本身也是實體類型的(建立者屬於使用者實體，歌單的歌曲屬於歌曲實體，收藏該歌單的使用者屬於使用者實體)，因此它們被稱作實體變數。實體變數的表示方法是在變數名之前加上括在中括弧裡的實體類型，比如“[使用者]建立者”。

　　操作描述了歌單實體的操作集合，歌單可以被收藏、評論、分享、播放與下載。當然還有一個被大括弧括起來的操作，這說明執行此操作是需要條件的。在歌單例子中，管理歌單與 編輯歌單封面、介紹是需要條件的，因為只有歌單的所有者才能執行這些操作。

　　描述實體關聯

　　描述了app中的各個實體，我們就能清晰的知道app是由哪些部分構成的，但是實體是靜態，事實上這些實體之間往往有著複雜的關係，它們是彼此聯絡彼此依賴的，一個的變化往往可以引起另一個的變化。形象的來說，可以把實體和實體關聯類別成公交網站與大眾運輸路線，實體是公交網站，而實體關聯，就是描述了這些網站是如何串連起來的大眾運輸路線，只有明確了網站與路線一個公交系統才算規劃好，同樣明確了實體與實體關聯，才算描述好了一個app系統。以網易雲音樂為例，描述了歌曲實體與歌單實體的關係：

　　歌曲可以被添加到歌單，而使用者又可以使用“歌單管理歌曲”的功能管理歌曲。比較特殊的是系統內建歌單“我喜歡的音樂”，使用者點擊歌曲的“喜歡”表徵圖就能將歌曲加“我喜歡的音樂”這個歌單。此外，實體自己對自己也可能會有關係，比如：

　　描述實體的組織與呈現(製作原型)

　　這一步事實上就是我們平常的製作原型，不過利用前面兩步的分析成果，製作原型的過程就可以認為是“描述實體的組織與呈現”，這將會帶來很多好處。如果直接按照傳統的“根據需求製作原型”，我們心裡也許會有把握全域的模糊意識，不過一旦陷入頁面配置、內容擺放等原型製作的細節裡(如果使用axure還要做一些編輯與互動)，由於缺乏通盤考慮，很容易使自己迷失。更多的情況是，沒有一個對全域很好的描述(缺乏對實體與實體關聯的解析)，我們在設計詳細頁面的時候就沒有一個清晰的架構約束，可能設計出的各個部分間會存在邏輯的不順暢甚至彼此矛盾。而如果我們前期已經在全域上分析了app系統的實體與實體關聯，那麼製作原型的過程相當於將這些已經分析思考比較全面的實體“放”到具體的頁面上呈現，這就像我們在旅遊某一個景點的時候身上一直帶了一張地圖，感到有所迷失的時候，就可以開啟地圖去尋找自己的位置，迅速理清思路，也就是你在設計某個頁面的時候心裡一定清楚它屬於全域架構的哪個部分，它與其他頁面之間存在著怎樣的關聯。實體、實體關聯與原型的關係可以總結成：

　　下面舉一個網易雲音樂中“我的音樂”頁面的具體例子(印證以上的關係圖)：

頁面-我的音樂
組成部分（各個實體）	關聯（操作）
下載音樂已下載/下載中 [歌曲]下載的歌曲[歌手]下載歌曲所屬歌手   [專輯]下載歌曲所屬專輯	除DJ節目外的下載操作
最近播放[歌曲]最近播放的歌曲	歌曲播放操作
我收藏的DJ節目[DJ節目]我收藏的DJ節目	DJ節目下載、收藏操作
我建立的歌單 [ (特殊歌單) 歌單]我喜歡的音樂 [歌單]我建立的歌單	建立歌單操作
我收藏的歌單 [歌單]我收藏的歌單	收藏歌單操作
頁面全域：我的音樂頁麵包含操作：匯入音樂、建立歌單、管理歌單

　　寫在最後的話

　　如果想快速上手一個app，那就可以用分析app的實體與實體關聯的方法在腦中建模，形成一個全域感知。這種建模不用太精細，在大腦中形成一個提綱挈領的印象即可。不過在設計app的情境下就需要落實各個細節了，從頂層設計開始，逐步分析系統的實體與實體關聯，然後再在這個基礎上去組織構建app原型，這將大大提升你的工作效率。

　　因為篇幅和可理解性等原因，木柄把網易雲音樂app所有的實體圖放在自己的網站http://mubing01.cn/?p=76下，有興趣的同學可以點過去一看。這篇文章算是近期木柄的心血之作，之後木柄還會從產品經理技能的角度出發，寫一系列產品方面的“純乾貨”，如果你也是執著於互連網產品設計的同路人那就不要錯過了。

產品經理乾貨，APP建摸——一套描述app的方法論