產品需求文檔的寫作(二) – 梳理需求(產品結構圖和用戶流程圖)
上一篇我們將概念想法形成了信息結構,羅列出了產品的所有信息內容,現在我們就要依據信息結構,開始規劃產品的功能需求,繪制出產品結構圖和用戶流程圖。首先我們要規劃出產品的頻道及子頻道、子模塊或子頁面。(如下圖) 圖注:講解一下我對于這個思維導圖的名詞理解 如果你學過網頁設計,或者了解Web產品的模板機制,你就能夠理解這些名詞了。如下圖所示,這是我的博客的首頁結構。 當我們規劃出頻道后,我們就需要以用戶的視角進行一步一步的模擬操作,逐漸完善產品的結構導圖。我稱為用戶流程圖,用于展現產品經理腦海中比較抽象的產品邏輯,也是產品經理對自己腦海中的產品想法進行梳理的一個過程。(如下圖示例) 這樣做的目的就是梳理產品邏輯,讓我們清楚的知道產品有幾個頻道,頻道下面有沒有子頻道或者有多少個頁面,這些頁面里又有哪些功能模塊,這些功能模塊里又有哪些元素。這樣我們就模擬了用戶的整個操作流程,逐一的將產品的所有功能界面操作了一遍,也列出了產品結構圖和用戶流程圖。 有了這份結構導圖,我們可以對產品進行鳥瞰式考慮和完善,當有問題時,修改起來也比原型和文檔方便很多。這樣的方法同樣適用于移動互聯網產品的規劃,并且比起Web產品更加容易梳理產品結構。 以上講的都是前端面向瀏覽者的用戶流程,但是如果規劃的是一個平臺級的大眾化產品就不能從前端進行梳理了,例如CMS、BBS之類的程序,他們采用框架式開發,將功能與模板獨立,前端的界面布局僅僅是通過模板機制的標簽調用,因此在做產品規劃時,前端是涉及不到的,也不應該從前端入手。遇到CMS類平臺產品的規劃,也同樣使用這樣的方法,只不過是從后臺入手模擬管理員的流程。 PRD文檔寫前準備就是讓我們先通過思維導圖梳理思路,明白產品有多少個頻道、有多少個頁面、頁面有多少個功能模塊、功能模塊有多少個元素,逐步的將腦海里的想法明確梳理成結構。雖然已經明確了產品的結構,但是這樣的思維導圖對于設計與技術人員依舊是抽象的,他們仍然看不懂,同時對于產品經理自己來說,這樣的結構圖也是沒有經過推演的,具體是否符合產品邏輯,是否符合用戶體驗,都是沒有深思過的,因此我們接下來就要進行原型設計,開始具體的考慮結構方案的可行性。 下一篇我將講解原型設計的幾種方法,并說明為什么原型設計要早于產品需求文檔的撰寫。 產品需求文檔(PRD)的寫作:
1、頻道:某一個同性質的功能或內容的共同載體,也可稱為功能或內容的類別。
2、子頻道:某頻道下細分的另一類別
3、頁面:單個或附屬某個頻道或分類下的界面
4、模塊:頁面中多個元素組成的一個區域內容,可以有一個或多個,也可以循環出現(例如:文章列表)
5、模塊元素:模塊中的元素內容,以文章列表舉例:文章標題、文章摘要、文章發布時間,這些都是元素,都是組成模塊的內容,同時他們也是可以循環出現的。元素的類型可以是:文字、圖片、鏈接等等
產品需求文檔(PRD)的寫作方法(文章的摘要介紹)
產品需求文檔的寫作(一) – 寫前準備(信息結構圖)
產品需求文檔的寫作(二) – 梳理需求(產品結構圖和用戶流程圖)
產品需求文檔的寫作(三) – 原型設計(手繪原型,灰模原型,交互原型)
產品需求文檔的寫作(四) – 撰寫文檔(PRD文檔)
產品需求文檔的寫作(五) – 用例文檔(UML用例圖、流程圖)
本文出自 產品經理 唐杰
第三個圖,是不是 信息結構圖和功能結構圖的混合版本?
對于頻道,子頻道,子模塊,子頁面那塊還是不能理解,能舉例說明一下嗎?
感覺這個用戶使用流程圖是不是不對啊?
啰哩吧嗦。。。。明明2個圖,幾行字就能講清楚的事。。。。
要顯得專業,要說得你聽不懂,文章的作用就達到了
樓主關于用戶流程圖的描述部分容易造成誤解,通常我們說用戶流程圖指的都是使用流程,不包括模塊描述和頁面元素。這里的“用戶流程圖”不如稱作框架層設計更為合適
恩,支持樓主的說法
同樣覺得這里的用戶流程圖用詞不對
對,我也同意你的看法,不是應該是操作流程嗎?
贊同,文章這里講的“用戶流程圖”準確的說應該是產品結構設計
想知道你用的軟件是哪個呀 ?? ??
思維腦圖
謝謝!其實我知道是思維導圖,只是想知道具體是哪個軟件,現在已經知道啦!
你用的是哪一個?
百度腦圖也挺好的
思維腦圖
Xmind