分析：如何理解描述一個APP

分析：如何理解描述一個APP

引子一：一個產(chǎn)品的生命周期中需要產(chǎn)出MRD(市場需求文檔)，然后根據(jù)市場需求文檔畫出產(chǎn)品原型圖并輸出PRD(產(chǎn)品需求文檔)。在許多產(chǎn)品經(jīng)理教程或者書籍里，大家肯定沒少看到與需求、原型相關(guān)的論述，不過在工作實踐中往往會感覺“從需求到原型”還是跳躍的，僅僅明確需求就去構(gòu)造產(chǎn)品原型會不清晰，中間需要做很多的過渡工作，只是這些工作不像明確需求與建立原型那樣被廣泛提及，它們并沒有一套明確的方法論。正是因為需求到原型存在“斷層”，而之間的過渡體并沒有被提出明確的概念，因此筆者將在此文中來論述如何在需求與原型之間搭建起一座橋梁，這個“橋梁”是如何工作的，從而順暢產(chǎn)品原型的輸出。引子二：一個極客用戶(需要深度體驗各類app的產(chǎn)品經(jīng)理就算這類用戶)需要來回翻轉(zhuǎn)整個app來理解這個app的設(shè)計理念和機制，因為沒有明確的方法論去告訴我們怎樣去深度體驗app，很多時候大家會感到迷茫和低效。這是因為我們往往抓其一隅，陷在細節(jié)里不可自拔，只有當你有意識從全局上去分析整個系統(tǒng)的設(shè)計，從app的各種頁面去構(gòu)建出一個邏輯框架圖的時候，你才開始“玩轉(zhuǎn)”這個app。那么，有沒有一套方法可以幫助我們迅速在大腦中建立app模型?答案是可以有，我們要做的就是翻轉(zhuǎn)頁面，然后把這些頁面解構(gòu)、重組，形成一個邏輯(功能)框架圖。當你的大腦中有了這樣一個整體的概念，再細入到每一個具體頁面的時候，你看到的不再只是這個頁面，你會知道它處于整體的哪一個位置，它在整個app中扮演了怎樣的一個角色，它與其他頁面之間的邏輯關(guān)系是如何的。盡管這兩個引子切入角度不同，但是大家可以發(fā)現(xiàn)它們在描述同一個事實：我們需要一套方法論去為app建模，從而幫助我們?nèi)ジ玫睦斫?、設(shè)計app產(chǎn)品。這種描述一方面在設(shè)計的時候為需求與原型之間做緩沖，另一方面在準備深度體驗app的時候，能真正從全局上去理解該app的設(shè)計思想，而不僅僅是“只見樹木不見森林”?！八街梢怨ビ瘛保P者受到UML類圖以及數(shù)據(jù)庫原理E-R(實體-關(guān)系)圖的啟發(fā)，發(fā)現(xiàn)采用類似方式去描述一個app的邏輯框架非常的有效。首先從概念上來說，app的“實體關(guān)系模型”就是把app理解成有許多不同的實體組成，而且這些實體之間又有各種關(guān)系，實體們相互影響相互變化。具體的頁面就是把不同的實體按一定規(guī)則的呈現(xiàn)，而頁面之間的關(guān)系也透露出各個實體之間的關(guān)系。所以，描述一個app就是首先描述“實體”，然后描述實體之間的關(guān)系，最后描述實體的組織呈現(xiàn)。這樣就能非常深刻的去理解一個app了。當然沒有聽明白的小伙伴們也不要緊，下面筆者用一個實例(網(wǎng)易云音樂app)去說明怎樣使用實體-關(guān)系的方式去為一個app建模。描述實體實體可以理解成“概念類”，比如在網(wǎng)易云音樂中我們可以抽象出這些“概念”實體：歌曲、歌單、用戶、歌手、專輯、DJ節(jié)目。下面舉一個歌單實體的例子，如圖：產(chǎn)品經(jīng)理干貨，APP建摸：一套描述app的方法論，互聯(lián)網(wǎng)的一些事歌單實體中的變量描述了歌單是由哪些元素組成，一個歌單擁有歌單名、封面、介紹與評論。當然一個歌單也會有創(chuàng)建者、屬于此歌單的歌曲與收藏該歌單的用戶這些元素，不過它們本身也是實體類型的(創(chuàng)建者屬于用戶實體，歌單的歌曲屬于歌曲實體，收藏該歌單的用戶屬于用戶實體)，因此它們被稱作實體變量。實體變量的表示方法是在變量名之前加上括在中括號里的實體類型，比如“[用戶]創(chuàng)建者”。操作描述了歌單實體的操作集合，歌單可以被收藏、評論、分享、播放與下載。當然還有一個被大括號