本文根據(jù)唐杰博客整理
信息構(gòu)造圖
規(guī)劃產(chǎn)品的第一步就是梳理出產(chǎn)品的信息結(jié)構(gòu),有了信息結(jié)構(gòu)我們才能繼續(xù)往下規(guī)劃產(chǎn)品結(jié)構(gòu),并且信息結(jié)構(gòu)是服務(wù)端技術(shù)人員創(chuàng)建數(shù)據(jù)庫的依據(jù),是數(shù)據(jù)結(jié)構(gòu)的輔助文件。對于新產(chǎn)品或者新功能,沒有人能夠比產(chǎn)品經(jīng)理更加清楚所需要的信息內(nèi)容了,因此第一步我們就需要先將這些信息羅列出來,形成結(jié)構(gòu)化。(如下圖)

在這一步,我們還不需要深入的考慮產(chǎn)品的界面與功能。信息結(jié)構(gòu)的考慮有面向前端的,也有面向后端的,具體視產(chǎn)品類型而定。
例如CMS之類的程序,這類程序采用框架式開發(fā),將功能與模板獨立,因此前端具有多變性,并且這類產(chǎn)品屬于平臺型產(chǎn)品。針對這類產(chǎn)品,我們在規(guī)劃信息結(jié)構(gòu)時,只需要簡單的考慮一些前端的功能需求,更多的是面向后端管理員操作進行考慮,從后端入手規(guī)劃和羅列出所需要的信息內(nèi)容結(jié)構(gòu)。
無論是什么樣的產(chǎn)品類型,無論從哪里入手,我們第一步都是先要羅列信息結(jié)構(gòu),因為信息結(jié)構(gòu)圖不僅是輔助技術(shù)人員創(chuàng)建數(shù)據(jù)庫的圖表,也是輔助產(chǎn)品人員進行產(chǎn)品功能規(guī)劃的參考,只有對信息或數(shù)據(jù)的結(jié)構(gòu)了解,我們才能玩轉(zhuǎn)數(shù)據(jù),玩轉(zhuǎn)產(chǎn)品。
信息結(jié)構(gòu)圖是產(chǎn)品層面的理解,如果要入庫這些信息,還需要進行數(shù)據(jù)結(jié)構(gòu)的討論。一條信息的存儲有很多附加屬性,具體是存成字段還是數(shù)據(jù)表,還是說存在中間表或者關(guān)聯(lián)表,這些都需要在完成PRD文檔后和數(shù)據(jù)庫技術(shù)人員共同討論。討論時除了展示信息結(jié)構(gòu)圖,還要講解產(chǎn)品原型和功能需求,以便數(shù)據(jù)庫技術(shù)人員了解產(chǎn)品意圖,方便他們做數(shù)據(jù)庫規(guī)劃時考慮到以后的擴展。
信息結(jié)構(gòu)圖是我們將概念想法形成結(jié)構(gòu)化的第一步,也是我們接下來幾步工作的輔助文件
產(chǎn)品結(jié)構(gòu)圖和用戶流程圖
將概念想法形成了信息結(jié)構(gòu),羅列出了產(chǎn)品的所有信息內(nèi)容,現(xiàn)在我們就要依據(jù)信息結(jié)構(gòu),開始規(guī)劃產(chǎn)品的功能需求,繪制出產(chǎn)品結(jié)構(gòu)圖和用戶流程圖。首先我們要規(guī)劃出產(chǎn)品的頻道及子頻道、子模塊或子頁面。(如下圖)

圖注:講解一下我對于這個思維導(dǎo)圖的名詞理解
1、 頻道:某一個同性質(zhì)的功能或內(nèi)容的共同載體,也可稱為功能或內(nèi)容的類別。
2、子頻道:某頻道下細分的另一類別
3、頁面:單個或附屬某個頻道或分類下的界面
4、模塊:頁面中多個元素組成的一個區(qū)域內(nèi)容,可以有一個或多個,也可以循環(huán)出現(xiàn)(例如:文章列表)
5、模塊元素:模塊中的元素內(nèi)容,以文章列表舉例:文章標(biāo)題、文章摘要、文章發(fā)布時間,這些都是元素,都是組成模塊的內(nèi)容,同時他們也是可以循環(huán)出現(xiàn)的。元素的類型可以是:文字、圖片、鏈接等等
如果你學(xué)過網(wǎng)頁設(shè)計,或者了解Web產(chǎn)品的模板機制,你就能夠理解這些名詞了。如下圖所示,這是博客的首頁結(jié)構(gòu)。

當(dāng)規(guī)劃出頻道后,就需要以用戶的視角進行一步一步的模擬操作,逐漸完善產(chǎn)品的結(jié)構(gòu)導(dǎo)圖。稱為用戶流程圖,用于展現(xiàn)產(chǎn)品經(jīng)理腦海中比較抽象的產(chǎn)品邏輯,也是產(chǎn)品經(jīng)理對自己腦海中的產(chǎn)品想法進行梳理的一個過程。(如下圖示例)

這樣做的目的就是梳理產(chǎn)品邏輯,讓我們清楚的知道產(chǎn)品有幾個頻道,頻道下面有沒有子頻道或者有多少個頁面,這些頁面里又有哪些功能模塊,這些功能模塊里又有哪些元素。這樣我們就模擬了用戶的整個操作流程,逐一的將產(chǎn)品的所有功能界面操作了一遍,也列出了產(chǎn)品結(jié)構(gòu)圖和用戶流程圖。

雖然已經(jīng)明確了產(chǎn)品的結(jié)構(gòu),但是這樣的思維導(dǎo)圖對于設(shè)計與技術(shù)人員依舊是抽象的,他們?nèi)匀豢床欢?,同時對于產(chǎn)品經(jīng)理自己來說,這樣的結(jié)構(gòu)圖也是沒有經(jīng)過推演的,具體是否符合產(chǎn)品邏輯,是否符合用戶體驗,都是沒有深思過的,因此我們接下來就要進行原型設(shè)計,開始具體的考慮結(jié)構(gòu)方案的可行性。
原型設(shè)計
原型設(shè)計是幫助我們更細致的思考,并做各項需求的評估,同時也是將自己腦海里的想法進行輸出,通過原型設(shè)計后,我們就可以進行產(chǎn)品宣講了。相對于之前抽象的文字描述,原型則更加清晰產(chǎn)品的需求,設(shè)計和技術(shù)人員或者老板也能夠更加直觀的了解到產(chǎn)品意圖。
原型設(shè)計是將結(jié)構(gòu)化的需求進行框架化,因此原型也被稱為線框圖,具體的表現(xiàn)手法有很多種,相關(guān)的輔助軟件也有很多,例如:Axure RP、Balsamiq Mockups、UIDesigner等等。
手繪原型
因為原型也被稱為線框圖,因此手繪是最簡單直接的方法,也是最快速的表現(xiàn)產(chǎn)品輪廓的手法(如下圖)

手繪原型在初期驗證想法時非常高效,也方便討論和重構(gòu),同時也適合敏捷開發(fā)時快速出原型。
灰模原型
灰模原型是由圖形設(shè)計軟件制作而成,最常用的軟件是 PhotoShop 和 FireWorks ,相對手繪原型,灰模更加清晰和整潔,也適用于宣講,但是需要產(chǎn)品人員熟悉使用圖形設(shè)計軟件(如下圖)。

灰模原型常用于移動互聯(lián)網(wǎng)產(chǎn)品的設(shè)計,由于移動產(chǎn)品的交互需求復(fù)雜,原型設(shè)計軟件難以高效的表達需求,因此移動互聯(lián)網(wǎng)產(chǎn)品的設(shè)計通常是灰模原型加交互文檔組合成 PRD 文檔。幾天我再詳情講講移動互聯(lián)網(wǎng)的產(chǎn)品設(shè)計)

交互原型
交互原型是使用原型設(shè)計軟件完成的原型,常用軟件是 Axure RP,通常情況交互原型的設(shè)計僅早于 PRD文檔,是產(chǎn)品經(jīng)理想法推演的最后一步。通過Axure RP之類的交互原型軟件制作出來的產(chǎn)品原型,在功能需求與交互需求的表現(xiàn)和正式產(chǎn)品幾乎是一致的,所以有時交互原型也被稱為產(chǎn)品Demo版。
以上三種方法并不是漸進的流程,而是三種原型設(shè)計的方法,具體取決于你的產(chǎn)品需求和團隊要求。
產(chǎn)品經(jīng)理設(shè)計原型是為了幫助自己更細致的思考方案的可行性,也是為了給別人講解的時候,讓聽眾能夠清晰直觀的了解產(chǎn)品,同時也是為了確保產(chǎn)品在執(zhí)行過程中,是按產(chǎn)品經(jīng)理最初設(shè)想的需求和期望完成的。因此產(chǎn)品經(jīng)理的原型是沒有很高的要求的,只要對方能夠聽懂看懂,使用手繪原型是最高效率的方法。
撰寫 PRD 文檔
通過之前的準備工作,我們更加清楚了產(chǎn)品的需求,并細致的考慮了方案的可行性,從而減少與避免了撰寫文檔時容易忽略的細節(jié)黑洞。
PRD文檔沒有標(biāo)準的規(guī)范,也沒有統(tǒng)一的模板,每個公司都不一樣,并且每個人也不一樣,這個取決于個人習(xí)慣和團隊要求。雖然PRD文檔沒有標(biāo)準的規(guī)范,但是有兩項是必不可少的,那就是文件標(biāo)識和修改記錄。文檔在撰寫過程中,我們可以自行不斷的修改完善,但是如果正式發(fā)布或交給團隊其他成員后,一旦有了修改,為了文檔的同步,我們就需要標(biāo)注出文檔的修改內(nèi)容,備注修改記錄。關(guān)于文件標(biāo)識和修改記錄,大家的格式都大同小異(如下圖)。

PRD 文檔的形式常見的有以下三種:Word、圖片、交互原型
Word
這是傳統(tǒng)意義上的 PRD 文檔,主要有四個部分組成(具體視你的產(chǎn)品要求進行劃分),分別是:結(jié)構(gòu)圖、全局說明、頻道功能、效果圖。PRD 文檔的閱讀者更多是偏向于技術(shù)人員,因此 PRD 文檔目的性很明確,就是要描述產(chǎn)品的功能需求,所有PRD文檔是沒有關(guān)于市場方面的描述,同時也建議大家盡量減少不必要的文字,在能夠讓閱讀者看懂并且了解產(chǎn)品意圖的情況下,文字越少越好。這主要是因為絕大多數(shù)人是沒有足夠耐心認真看完 PRD 文檔的,因此我們要盡量減化文檔內(nèi)容。
結(jié)構(gòu)圖
- 信息結(jié)構(gòu)圖:主要是輔助服務(wù)端技術(shù)人員創(chuàng)建或調(diào)整數(shù)據(jù)結(jié)構(gòu)的參考文件
- 產(chǎn)品結(jié)構(gòu)圖:主要是輔助設(shè)計和技術(shù)開發(fā)人員了解產(chǎn)品的全局結(jié)構(gòu),他和用戶流程圖不一樣,產(chǎn)品結(jié)構(gòu)圖只是羅列出產(chǎn)品的頻道和頁面。
全局說明
主要講解產(chǎn)品的全局性功能的說明,例如網(wǎng)站產(chǎn)品的頁面編碼、用戶角色,移動產(chǎn)品的緩存機制、下載機制,這類全局性功能的說明。這里舉一個移動產(chǎn)品的“狀態(tài)維持與恢復(fù)”的例子,示例如下
狀態(tài)的維持與恢復(fù)
當(dāng)用戶退出產(chǎn)品時(誤操作、Home鍵、鎖屏、自動關(guān)機),產(chǎn)品需要維持用戶操作前的狀態(tài),當(dāng)用戶返回產(chǎn)品時仍可以恢復(fù)到之前狀態(tài),并繼續(xù)使用。
維持狀態(tài)包括流程操作、信息瀏覽、文本輸入、文件下載。
鎖屏狀態(tài)時,如果用戶在產(chǎn)品中有下載任務(wù)時,仍然保持下載。
提供一個產(chǎn)品需求文檔實例
頻道功能
以頻道為單位,頁面為子項,分別描述產(chǎn)品的頻道、頁面及頁面模塊元素的功能需求(格式如下)。
示例格式
1、頻道名:頻道介紹及需求說明
2、頁面1:頁面介紹及需求說明
2.1、頁面模塊1:模塊功能需求說明
2.1.1、頁面模塊1-元素1:功能說明
2.1.2、頁面模塊1-元素2:功能說明
2.2、頁面模塊2:模塊功能需求說明
在撰寫功能需求時,我們需要考慮用戶的流程,例如一個“完成”按鈕,我們需要描述他完成后,系統(tǒng)要不要給出反饋提示(反饋提示是什么樣的形式反饋,內(nèi)容顯示成什么,有沒有內(nèi)容需要調(diào)取數(shù)據(jù)庫),或者要不要跳轉(zhuǎn)頁面(跳轉(zhuǎn)到哪個頁面,這個頁面是其他頻道頁面,還是這個功能的子頁面,如果是子頁面就需要再描述這個子頁面的模塊及元素內(nèi)容)。
效果圖
效果圖是由設(shè)計師完成的產(chǎn)品圖,和實際開發(fā)完成的產(chǎn)品保真度一致。
圖片
圖片形式的PRD文檔是基于效果圖的說明文件,將傳統(tǒng)Word形式的功能需求說明標(biāo)注在效果圖上,這種方式經(jīng)常使用在移動互聯(lián)網(wǎng)領(lǐng)域,實際上是圖文形式的交互需求文件,只是在此基礎(chǔ)上更深入的描述出功能需求。
對于圖片形式的PRD文檔,我們只需要另外再描述一下全局說明,其他頻道頁面的需求直接以圖片形式展示,這種方式相對于Word文檔的純文字更加生動易讀并且直觀,因此有一些產(chǎn)品經(jīng)理非常喜歡用這種方式代替Word形式的PRD文檔。

交互原型
這里指的交互原型就是上一篇文章講的原型設(shè)計,使用Axure PR之類的交互原型設(shè)計軟件制作出來的產(chǎn)品原型非常真實和直觀,并且原型軟件還支持元素標(biāo)注和導(dǎo)出Word文檔,因此很多產(chǎn)品經(jīng)理都喜歡使用Axure PR來代替Word完成PRD文檔。
當(dāng)我們通過Axure PR制作出產(chǎn)品原型后,實際上他已經(jīng)是很完善的產(chǎn)品Demo了,因此我們只需要加上元素的標(biāo)注,在標(biāo)注中說明功能需求,這樣導(dǎo)出的HTML文件相比Word文檔更直觀易懂,是非常高效的產(chǎn)品需求說明方式。
總結(jié):無論你采用哪種方式產(chǎn)出需求文檔,最終的目的都是為了方便團隊成員理解產(chǎn)品的意圖,因此哪種方法能夠避免細節(jié)黑洞,高效完成產(chǎn)品的設(shè)計和研發(fā),那么這種方法就是最有效的方法。