APP建摸—一套描述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節目。下面舉一個歌單實體的例子,如圖:
頁面-我的音樂 |
|
組成部分(各個實體) | 關聯(操作) |
下載音樂
已下載/下載中 ?[歌曲]下載的歌曲 [歌手]下載歌曲所屬歌手 ?[專輯]下載歌曲所屬專輯 |
除DJ節目外的下載操作 |
最近播放
[歌曲]最近播放的歌曲 |
歌曲播放操作 |
我收藏的DJ節目
[DJ節目]我收藏的DJ節目 |
DJ節目下載、收藏操作 |
我創建的歌單
?[ (特殊歌單) 歌單]我喜歡的音樂 ?[歌單]我創建的歌單 |
新建歌單操作 |
我收藏的歌單
?[歌單]我收藏的歌單 |
收藏歌單操作 |
頁面全局:
我的音樂頁面包含操作:導入音樂、新建歌單、管理歌單 |
寫在最后的話
如果想快速上手一個app,那就可以用分析app的實體與實體關系的方法在腦中建模,形成一個全局感知。這種建模不用太精細,在大腦中形成一個提綱挈領的印象即可。不過在設計app的場景下就需要落實各個細節了,從頂層設計開始,逐步分析系統的實體與實體關系,然后再在這個基礎上去組織構建app原型,這將大大提升你的工作效率。
因為篇幅和可理解性等原因,木柄把網易云音樂app所有的實體圖放在自己的博客網站http://mubing01.cn/?p=76下,有興趣的同學可以點過去一看。這篇文章算是近期木柄的心血之作,之后木柄還會從產品經理技能的角度出發,寫一系列產品方面的“純干貨”,如果你也是執著于互聯網產品設計的同路人那就不要錯過了,敬請關注我的公共號mubing01,個人博客網站mubing01.cn。
前來學習,木柄牛逼。
一股濃厚的數據庫氣息撲鼻而來。。。
哈哈,本來就是做技術出身的。。