功能結構圖、信息結構圖、結構圖,你還傻傻分不清嗎?(上)
![](http://image.woshipm.com/wp-files/img/92.jpg)
你還在問產(chǎn)品結構圖到底是信息結構圖還是功能結構圖嗎?這里有微信的實際例圖幫助你更好地理解這組命運三姐妹圖類。在寫PRD、競品分析文檔中,我們常常會看到產(chǎn)品結構圖、產(chǎn)品功能結構圖或者產(chǎn)品信息結構圖的身影,但需要講清楚他們的定義和作用也真沒看上去那么簡單,這里作者嘗試分享一下自己的觀點。
特別聲明:由于篇幅和其他因素限制,本系列中所有的實例圖在完整性上有省略和簡化,僅作為舉例講解用,請讀者不要糾結圖表是否描述完整、是否有缺失模塊,主要是給讀者來對比3類圖表的聯(lián)系與區(qū)別。
功能結構圖
1定義
功能結構圖就是按照功能的從屬關系畫成的圖表,在該圖表中的每一個框都稱為一個功能模塊。功能模塊可以根據(jù)具體情況分得大一點或小一點,分解得最小功能模塊可以是一個程序中的每個處理過程,而較大的功能模塊則可能是完成某一個任務的一組程序。(百度定義)用通俗的話來說,功能結構圖就是以功能模塊為類別,介紹模塊下其各功能組成的圖表。
2作用
- 產(chǎn)品概念設計的運用工具之一,能夠對不完全確定的設計問題或相當模糊的設計要求,以一種較為簡潔和明確的方法表示。在繪制的過程中,能夠幫助PM思考并清晰產(chǎn)品的功能模塊及其功能組成;
- 梳理需求,以鳥瞰的方式對整個產(chǎn)品頁面中的功能結構形成一個直觀的認識,防止在產(chǎn)品需求轉化為功能需求的過程中出現(xiàn)功能模塊和功能點缺失的現(xiàn)象。
3注意事項
在區(qū)分功能結構、信息結構圖、結構圖前,有一個重要的前提需要大家達成共識:軟件產(chǎn)品本身就是傳遞信息和提供功能的載體,完全絕對的信息類或功能類產(chǎn)品是不可能存的在,信息往往伴隨著功能,我們很難劃一條界限將兩者徹底分開。從某種意義上,信息傳遞甚至就是軟件產(chǎn)品最主要的核心功能。鑒于此,通常我們默認地把信息展示功能獨立了出來,作為信息架構的一部分去思考,在產(chǎn)品功能結構時不考慮信息展示功能。
這里舉一個信息與功能糾纏的例子更好理解,如微信的個人信息模塊(如下圖),“名字”字段在這里既是信息又提供著修改設置的功能。
所以我們不難理解許多功能結構圖中出現(xiàn)了信息結構的要素,但由于功能結構圖的使用目的(即上文中的作用)要求我們專注于產(chǎn)品功能這個維度,在功能結構圖中我們最好盡量減少信息結構要素出現(xiàn)的可能性。
就用上面功能與信息糾纏的例子來說,在其功能結構圖中許多朋友會直接用“名字”來表示其功能點,畫圖人可能本人清楚,但看圖人就會產(chǎn)生疑惑:這個“名字”到底是指提供可查看名字的功能還是可查看并修改名字的功能。
在這里介紹一個小訣竅,形容一個功能點時建議多采用“動詞+名詞”的語言描述形式,這種方式不僅信息傳達更加準確而且可以避免讀者不必要的困惑。如上面的例子中我們就可以把“名字”改為“設置名字”或“查看并設置名字”來描述功能點。
4如何繪制功能結構圖
在實際應用時,產(chǎn)品功能結構圖通常在以下2種情況下繪制:
- 對未完成的產(chǎn)品在設計階段繪制,確定產(chǎn)品功能結構;
- 對已完成的某個版本的產(chǎn)品繪制,用于分析并傳遞該產(chǎn)品的功能結構;
(一)在產(chǎn)品的設計階段,如何挖掘并確定功能結構圖中的主功能模塊呢?
首先主功能模塊應該是產(chǎn)品在完整業(yè)務流程中的各個核心功能模塊,我們可通過業(yè)務流程中所涉及到的功能需求去提煉出主功能模塊,提煉完成后再通過業(yè)務流程走查一次,看是否有遺漏的主功能模塊。
舉個例子,假設我們參與了微信的早期功能設計,其產(chǎn)品初期定位是一款移動社交軟件,那么其對應的核心業(yè)務可以簡化為
這樣我們就很容易得出產(chǎn)品設計階段微信的主功能模塊,如下:
結合下面現(xiàn)有版本的微信功能結構圖對比一下,經(jīng)過上百次迭代,其主功能結構幾乎沒有發(fā)生變化,我們不得不佩服其功能結構的拓展性;
當通過業(yè)務流程將主功能模塊確定下來后,再根據(jù)業(yè)務需求對其進行功能的詳細設計即可,在此就不再展開了。
2.對于已確定產(chǎn)品來說如何繪制功能結構圖呢?
對一款已確定產(chǎn)品繪制功能結構圖,最快捷的方法便是參考產(chǎn)品的Tab功能模塊找出產(chǎn)品主功能模塊,然后按照層級歸屬關系詳敘該功能模塊提供的下一級功能模塊或功能,如有必要,其顆粒度可一直細化到功能操作的描述程度。
那上圖“微信功能結構圖(V6.5.21)”的主功能模塊為什么不是“微信”、“通訊錄”、“發(fā)現(xiàn)”、“我”這四大標簽功能模塊?
在這里作者希望傳達一個概念,結構圖中的主功能模塊不一定就是Tab中的標簽功能模塊,許多時候產(chǎn)品受限于移動端的空間限制,不得不把功能分為3到4個Tab中,這是一種務實的妥協(xié)。當然正常情況下以Tab標簽名作為主功能模塊的做法沒有錯,只是當產(chǎn)品功能復雜時,產(chǎn)品功能結構圖采用這種劃分有點粗糙。而繪制已確定產(chǎn)品的功能結構圖能夠幫助我們?nèi)ネ诰蜻@個產(chǎn)品的核心功能模塊,梳理產(chǎn)品的功能架構。我們建議作圖人可以嘗試脫離Tab標簽用自己的語言去挖掘并描述主功能模塊。
這樣說來我們就可以隨意將標簽功能模塊中的次級功能模塊劃分出來作為主功能模塊嗎?
其實也不是,一款不管多復雜的應用其主功能模塊的劃分數(shù)量都不能太多(5-9個為佳),一般情況下當對產(chǎn)品功能結構進行分析后,我們?nèi)匀粫捎肨ab功能模塊作為主功能模塊然后對其下屬的功能模塊進行整理。只有當我們認為某個次級功能模塊在業(yè)務上太過重要且產(chǎn)品價值較高時,我們才可以將其劃分出來作為一個單獨的主功能模塊。
這里介紹一個小秘訣,當一個次級功能模塊反復出現(xiàn)在不同的Tab功能模塊中的時候,我們就可以考慮將其拆分出來作為主功能模塊,因為這個時候意味著這個次級功能模塊在產(chǎn)品的業(yè)務流程中來說十分重要,而且這也可以讓我們的產(chǎn)品功能結構圖更加簡潔清楚。如上面“微信功能結構圖(V6.5.21)”中的搜索模塊就同時出現(xiàn)在了Tab中的微信功能模塊和通訊錄功能模塊。
最后如何確定功能結構圖中的顆粒度呢?
功能結構圖中的顆粒程度需要根據(jù)具體應用場景來定,由畫圖人根據(jù)需要自行把控即可。比如說在產(chǎn)品設計的過程中,功能結構的建立是設計者的設計思維由發(fā)散趨向于收斂的過程,剛開始的顆粒度一般比較大,可能僅涉及到某個功能模塊,隨著設計的不斷推進,功能結構圖的顆粒度會不斷細化,最終可以拆分至某個具體的功能操作。這里作者將“微信模塊-個人對話”功能模塊作了細化,僅供參考:
未完待續(xù),歡迎訂閱!
作者:藍調(diào)Lee,微博號:藍調(diào)L
本文由 @藍調(diào)Lee 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉載。
題圖由作者提供
功能和信息,一個動詞一個名詞
這樣理解對嗎?
產(chǎn)品功能結構圖:較抽象,功能模塊下的功能點,功能點幾乎不會重復。
產(chǎn)品信息結構圖:更細化,從頁面出發(fā),每個頁面下各個功能都寫全。一個功能點可能會出現(xiàn)在多個頁面下。
信息結構圖重在信息,就是說明每個對象要展示什么信息,這個對象是從系統(tǒng)呢抽象出來的
從抽象到具象到階段過度而已。這里提供一個思路,就是我們不要被流程綁架,流程是協(xié)助我們更好的進行梳理和表達的,如果為了設計而設計的去將一個本不需要繁瑣的過度階段去梳理的產(chǎn)品去繁瑣化表達,那就是脫了褲子放屁了,這樣不僅自己會暈,而且同協(xié)作的同事也會暈,這樣適得其反的事情還是不要做。
看了你這篇有很大收獲 之前我只會用axure畫原型 我想問下功能結構圖的”添加朋友模塊”可不可以變成添加模塊 然后分支持添加朋友 掃一掃 首付款這些
我覺得 這樣會造成前端誤解
那對于已確定的產(chǎn)品來說,我們是不是也可以通過先縷清它的完整業(yè)務流程,然后提煉出主功能呢?
我就是這樣,確定業(yè)務邏輯圖,基本上每一個節(jié)點就是一個功能模塊
剛學還是傻傻分不清楚
我和你同名,可以加個v一起交流討論下嗎
很贊的知識分享!目前自己輸出的PRD就會按這個分類去輸出。信息結構圖->功能結構圖->產(chǎn)品原型結構圖->若干產(chǎn)品原型頁面。
好像不是吧,應該是功能結構-信息結構-產(chǎn)品結構-原型
是否可以理解為功能結構圖是描述實際所需功能,信息結構圖是在功能結構圖的基礎上描述對應功能所需展示的信息需脫離實際頁面
嗯,這樣理解比較順
干貨
我就想知道這個圖是拿什么工具畫的哦~
mind
xmind
好的 謝謝
說的非常清晰,感謝~~~
還有個小問題請教~
如果是商城模塊,列功能結構時,是否需要列出“商品分類”這個維度呢??
那個應該叫 篩選 或者 種類篩選吧
嗯嗯 ,大概明白,感謝~~。畫功能結構時,會混淆到底是從頁面內(nèi)提取功能,還是提取單純的某某功能
請問功能結構圖是使用什么軟件畫的呢?
干貨。贊??
我作為小白才明白,功能和信息的區(qū)別,一個是用戶要去產(chǎn)生動作,完成一個流程。而信息只是作為內(nèi)容查看性質(zhì)。
很干貨,感謝分享~
“名字”感覺就可以了,改成“查看與設置名字”是不是有些多余
之前做項目的困惑,謝謝解惑!
分析的很好,受教了
謝謝,看完后有收獲。分析過程深入淺出,同時也有很好的經(jīng)驗之談。
寫的很棒,回頭思考了下,瞬間頓悟。
能不能通俗的話,來幫我解答一下呢?萬分感謝
我是小白,還是沒分清。。怎么辦
作者的意思是按功能去劃分,因為有些tab僅僅是提供信息查看,而沒有設置的功能。
有個問題:引導頁、啟動頁算是什么模塊,登錄注冊?有些引導頁會在其他模塊中顯示
我個人愚見,引導和啟動頁面應該不屬于登錄注冊界面,可以根據(jù)具體情況合并到其他信息指引模塊,或者單獨抽離出來。舉一個較為極端的例子,某個效率類的App可能不需要登錄注冊,但是同樣會有引導和啟動頁面。
和“對話列表”、“搜索模塊入口”等平行的一個功能模塊:“引導頁查看”,然后這個模塊用戶只有一個查看功能所以就不用往下樹形結構了,如果從后臺端可能功能模塊叫“引導頁設置”
前后臺功能是垂直對應的,引導頁啟動頁屬于廣告資源位功能中的前端展示。
好文章,很干貨!
好文章
微信信息結構圖中,錢包中的交易記錄、收藏列表、表情下載記錄,這些都不用寫進去?
肯定要寫啊 信息結構圖不就是每個頁面的具體詳情都要寫嗎 作者是沒寫這一塊吧
添加好友模塊放置在通訊錄模塊下,和通訊錄其他子功能平行。
這樣的思考有什么問題么?
支持干貨,由思維發(fā)散到收斂
一般來說,在我的接觸的工作流程里面,上面這兩個會叫做腦圖和功能list,也是我接觸的大部分2C產(chǎn)品經(jīng)理都會出的。
站在2B后端的角度來看,我們的工作流程和產(chǎn)品設計,一般會出這么幾個東西:
1.產(chǎn)品信息結構圖:設計整套信息結構,接觸層、應用層、邏輯層、數(shù)據(jù)層、接口,服務設計
2.系統(tǒng)構架圖;信息、作業(yè)、流程、規(guī)則、基礎設置,上下游;
3.業(yè)務構架圖;業(yè)務實現(xiàn)組件,組件實現(xiàn)方式結構
4.用例圖;這個就不用多說了吧?
5.業(yè)務流程圖;業(yè)務實現(xiàn)流程,跟系統(tǒng)流程無關
6.系統(tǒng)流程圖;對應業(yè)務流程做實現(xiàn)
7.改動范圍腦圖【這個也不一定用圖】
然后下面是具體的圖:
1.每個活動的時序圖;
2.用例詳述,前置后置等等;
2B 2C不一樣吧,后端產(chǎn)品經(jīng)理關注的更多是產(chǎn)品目的是什么,為了這個目的我們要做什么,做成什么樣子,在哪里實現(xiàn),實現(xiàn)方式是什么,從此一步步確定產(chǎn)品設計,最后出原型,當然 上面幾個出來了,原型這個東西,也沒那么重要,后端可以開工了,前端也可以跟后端一塊設計接口了,最后等產(chǎn)品原型、交互與視覺設計,出前端
感覺步驟1和步驟3更多是(技術)架構師來操刀做的,產(chǎn)品只要能看懂理解,并在技術方案評審階段基于系統(tǒng)靈活性以及擴展性做出對應的判斷和建議,與研發(fā)達成共識即可。
嗯 可能每個團隊不一樣,我們這邊都是產(chǎn)品確定大致的方式,架構師決定實現(xiàn)采用方式,因為這樣速度最快,如果產(chǎn)品不決定,那么會有來年各個問題,一個是產(chǎn)品和架構要溝通非常多的事情,另一個項目開始開發(fā),開發(fā)會轉向以架構為中心,而不是以產(chǎn)品為中心,可能會有溝通問題,以及最后做出來會跟產(chǎn)品的設想有差異。
評論里也是干貨呢 ??
最近想多加研究后端產(chǎn)品,不知可否加到前輩的微信,向您討教~
我的微信號:18711138641
之前做前端的,現(xiàn)在讓我做后端產(chǎn)品,一臉懵逼中,求大神指教!留個聯(lián)系方式啊。。。
這才是干貨!贊
總結的很到位,下篇什么時候出,,等著呢,
已發(fā)布,歡迎查看
http://www.codemsi.com/pmd/844937.html
這