深度 | 在高級產品經理眼里,產品架構是怎樣的?

32 評論 67220 瀏覽 432 收藏 39 分鐘

一般來說,搭建產品架構這件事情,只有少數的高級PM才能勝任,絕大多數剛入門的產品經理或產品專員,還涉及不到任務這么艱巨的工作(簡單的產品功能結構不算)。

經歷過需求的采集、分析和篩選,我們對產品的定位和用戶的需求有了越來越深刻的認識,對整個產品方向的把控和版本迭代節奏也會更有感覺。這種感覺你也可以稱之為“產品感”,雖然講得有點懸乎,可又的確存在。以我個人的經驗來看,不斷地了解用戶需求和場景,也是積累產品感的一種良好的方式。有了不錯的產品感,我們要繼續往前走,才能將產品推向一個更高的高度。

產品經理之前已經將產品第一個版本的功能需求都整理好了,也輸出了一份詳細的功能需求列表,這個時候要做的工作就是為產品搭建一個好的架構,也就是產品設計的第三個環節——搭框架了。任何一款互聯網產品都應該有一個產品架構,有了這個強大而堅實的架構作為產品的基礎,我們才能將產品需求給一個一個填充進去,讓產品變的豐富立體,更有血有肉起來。

那究竟什么是產品架構,產品經理又該如何來搭建一套好的產品架構,我們來接著往下看。

什么是產品架構

任何一個產品都有自己的產品架構(也有很多人把它稱為信息架構),就好比每一個人都有自己的骨骼系統一樣,你的骨架大小決定了你大致的身材會是如何,每個人的身材都不一樣,高、矮、胖、瘦各有不同。

有些產品的產品架構比較繁雜,例如大部分to? b 的產品,如客戶關系管理系統、ERP軟件、電商網站的管理后臺、物流管理后臺、SaaS軟件等;有些架構則比較輕便、簡單,比如絕大多數的to? c 的產品,像我最近在玩的圖友、摩拜單車、直播APP映客、花椒等,當然還包括微信(雖說現在功能越來越多了,但大體架構依然是簡單、清晰明了的)。

我們直接看幾個例子:

天貓商家工作后臺

這是天貓商家的工作后臺,看到左側這一排滿滿的導航菜單了嗎,是不是感覺超級復雜,光店鋪管理就有超過10個二級菜單,要梳理好淘寶、天貓這種量級的電商平臺產品架構可真不是一件簡單的事。不過我也常常好奇一點,這么復雜的后臺,賣家們都能清楚地知道每一個功能在哪里么。

復雜架構的產品,對產品經理的能力要求較高,需要產品經理能提供功能完備、結構嚴謹的架構系統,讓用戶能通過操作流程來使用各個功能。所以這樣一個架構的特點是,它會帶來一定的學習成本,有些甚至需要對產品的用戶進行培訓(像淘寶開設了淘寶大學以及淘寶社區)。這種架構產品的用戶群體一般比較聚焦,只針對某一類人群,需要對海量功能進行合理整合、靈活布局來聚焦核心用戶場景。

臉萌官網

再來看一個例子,這是曾經爆紅一時的臉萌app的產品官網,仔細分析一下這個官網的產品架構,是不是超級簡單,簡單到只剩下2個菜單——首頁、關于我們。這里要注意一點,即使是簡單的2個菜單(有些官網只有一個菜單),也依然構成了完整的用戶體驗,因為通過這個架構,網站的目標和用戶的需求都已經得到了充分的滿足。當然,如果你想要重新定義網站的目標,或是用戶的需求發生了變化,那你就該去準備重新調整產品架構了。

輕架構的產品,它的目標就是提供給用戶一個簡單明了的信息架構,讓用戶使用方便、體驗流暢。對于產品經理來說,設計輕架構的產品,難點在于體驗和創新。我們可以通過給產品做減法來不斷聚焦用戶的核心使用場景,讓用戶簡單易上手,等產品的用戶體量上升到一個新的臺階的時候,再去拓展產品的使用場景,延展產品架構。

典型的幾個產品架構模型

Jesse James Garrett在《用戶體驗要素》這本書中,為我們系統闡述了互聯網產品的幾個典型的產品信息架構模型。第一種信息架構模型比較符合我們產品經理對產品架構的理解和定位,后面三種信息架構模型,你可以當作是第一種模型的補充,或者你也可以把它當作頁面級別的信息架構梳理。

第一種,層級結構(hierarchical structure

層級結構模型

書中原文是這么來描述這種產品架構的——“在層級結構中,節點與其他相關節點之間存在父級/子級的關系。子節點代表著更狹義的概念,從屬于代表著更廣義類別的父節點。不是每個節點都有子節點,但是每個節點都有一個父節點,一直往上直到整個結構的父節點。層級關系的概念對于用戶來說非常容易理解,同時軟件也是傾向于層級的工作方式,因此這種類型的結構是最常見的?!?/p>

這種傘狀式的產品架構,恐怕是互聯網、移動互聯網產品中使用最多的一種信息結構,比如我們使用頻度最高的微信、手q,以及各類to c 的移動APP,甚至是復雜的to b 類產品,都是使用這種產品架構進行產品設計。這種架構的特點是符合人類的認知習慣,因為人類天生就有分類的習慣,比如書桌,我們會習慣把書籍放在一起,把錄音卡帶等放到一邊;又比如我們的衣柜,我們一半會將不同季節的衣服放在不同的位置。在生活中,整理物品是為了更容易地找到自己需要的東西。

下圖是蜻蜓fm早期版本的一個層級信息架構:

蜻蜓fm的產品信息架構

在使用層級結構的時候,需要注意層級的深淺和寬窄這個問題。

大家都有過逛商場的經驗,其實有時候做產品和逛商場很相似,有的商場設計的比較合理,很容易地能夠讓逛商場的用戶找到想要的商品品類,有的商場設計卻經常讓你迷路,來來回回折騰好幾次。在確定產品架構的時候,考慮產品架構的深度和廣度成為了產品經理的一道必選題,就拿淘寶APP和唯品會APP來說,淘寶屬于廣而深的架構,唯品會則屬于淺而窄的架構(相對)。在偏深度的架構中,用戶操作起來效率不高,用戶獲取信息、完成目標任務的路徑增多,但是相對而言,減少了用戶選擇的入口。在偏廣度的架構中,用戶面對的入口增多,在選擇入口的時候比較費時,但是減少了用戶的操作路徑。

廣度和深度的架構模式

寬而淺的產品架構和窄而深的產品架構,各有優勢和劣勢,具體使用哪一種產品架構,關鍵是要結合自身產品的定位、業務特性、發展階段和用戶特征及使用場景來進行取舍和判斷。

第二種,自然結構(organic structures

自然結構模型

原文描述如下——“自然結構不會遵循任何一致的模式。節點是逐一被連接起來的,同時這種結構沒有太強烈的分類概念。自然結構對于探索一系列關系不明確或一直在演變的主題是很合適的。但是自然結構沒有給用戶提供一個清晰的指示,從而讓用戶能感覺他們在結構中的哪個部分。如果你想要鼓勵自由探險的感覺,比如某些娛樂或教育網站,那自然結構可能會是個好的選擇;但是,如果你的用戶下次還需要依靠同樣的路徑,去找到同樣的內容,那么這種結構就可能會把用戶的經歷變成一次挑戰。”

事實上,這種形態的產品架構一般在to? c 的游戲、娛樂、資訊產品里面運用的比較廣泛,例如優酷視頻、好奇心日報等。當然,很多時候自然結構是應該結合層級結構來進行思考的,比如用戶進入好奇心日報這個網站,可能的一種使用方式是,用戶心里已經有一個明確的資訊目標,想看一下最近商業有發什么大故事,所以用戶會點擊上方的“全部分類”,選擇電影,選擇商業板塊然后進行瀏覽。也有另一種使用方式,就是毫無目標,直接就是這么從上到下瀏覽下去,看到自己感興趣的文章標題便點擊進去。

好奇心日報官網

自然結構很適合輕架構產品的瀏覽式形式,尤其比較適合to ?c 類的娛樂休閑類產品,因為這類產品的目標用戶,絕大多數時候的使用場景都是無聊式地瀏覽,并沒有明確的用戶目標,也不需要解決什么特定的任務。

第三種,線性結構(sequential structures

依舊來看下原文描述——“線性結構來自于你最熟悉的線下媒體。連貫的語言流程是最基本的信息結構類型,而且處理它的裝置早已被深深地植入我們的大腦中了。書、文章、音像和錄像全部都被設計成一種線性的體驗。在互聯網中線性結構經常被用于小規模的結構,例如單篇的文章或單個專題;大規模的線性結構則被用于限制那些需要呈現的內容順序對于符合用戶需求非常關鍵的應用程序,比如教學資料?!?/p>

說的直白一點,所謂線性結構,就是你用一個講述故事的方式去給用戶介紹你的產品,多見于產品專題頁、幫助文檔的設計。其實這部分也沒什么可講的,關鍵是講述故事或者問題的時候,你的思路是否清晰,很多時候這部分工作也會由運營的同事替我們代勞。

金山快盤專題頁

上圖就是金山快盤做的一個活動專題頁,通過線性結構講故事的方式來將自己“100G空間永久免費”的活動宣傳出去。

第四種,矩陣結構(matrix structure

矩陣結構模型

書中是這么描述矩陣結構的:“矩陣結構允許用戶在節點與節點之間沿著兩個或更多的“維度”移動。由于每一個用戶的需求都可以和矩陣中的一個“軸”聯系在一起,因此矩陣結構通常能幫助那些“帶著不同需求而來”的用戶,使他們能在相同內容中尋找各自想要的東西。

舉個例子來說,如果你的某些用戶確實很想通過顏色來瀏覽產品,而其他人偏偏希望能通過產品的尺寸來瀏覽,那么矩陣結構就可以同時容納這兩種不同的用戶。然而,如果你期望用戶把這個當成主要的導航工具,那么超過三個維度的矩陣可能就會出現問題。在四個或更多維度的空間下,人腦基本上不可能很好地可視化這些移動。”

看了上面這段話,你的第一反應是不是想到了下面這個產品設計界面:

淘寶的寶貝詳情頁

矩陣式的信息結構,需要將多種信息內容放置在一個頁面里,所以它的重點和難點是在于如何做好信息分層,讓信息更加有效率地傳達給自己的目標用戶,這個問題我們放在后面來講。

總體來說,產品經理了解這幾個典型的產品信息架構模型,對于后期自己設計產品架構的時候,會更加明確應該朝哪個方向進行努力。這就好比一個建筑師在設計房屋之前,都需要先有足夠的建筑設計知識,其中搭建建筑物的框架便是其中少不了的重要一課。

在具體的工作場景中,大多數產品經理從事的工作基本會分為兩個大類,一類是C端產品經理,負責和普通用戶打交道,更考驗對用戶痛點和興奮點的把握和拿捏;另一類則是B端產品經理,負責和企業用戶打交道,更考驗對業務本質和行業戰略的思考。那么,具體這兩種類型的產品該如何來搭建產品架構呢?

To C?類的產品如何搭建產品架構

先簡單介紹下業務背景:

2014年開始變熱的O2O行業,已經迅速從表層變革進入深水區,很多O2O相關商業模式被驗證錯誤或者迅速發展壯大,這個過程無數創業公司創立和倒下。除了商場、吃喝玩樂商戶、線下服務商戶等成為O2O熱點之外,到家模式也成為一個新熱點,美甲的、按摩的、泡腳的手藝人很多都變成了流動作業(典型如河貍家),如果說吃喝玩樂等希望輻射的是商圈流量,那到家服務無非希望搞定社區這塊“富礦”。

15年初,當時我所在的公司正好也看中社區O2O這個行業(當然是老板有相關資源,又覺得市場前景廣闊),而做社區O2O,有個繞不開的門檻——物業,如果有誰愿意費力氣去啃物業這塊兒硬骨頭,就能有機會贏得未來。

于是我們就組建了一個小團隊,先去做了一番市場調研,看一下市面上的這些社區O2O產品都做了哪些連接社區居民的服務,得出了這么一份競品分析報告:

競品分析報告

把玩了幾十款APP后,我們發現只有少數幾家公司的產品做了向業主提供在線支付物業費、停車費的服務,更別談業主可以在線報修,呼叫安保等服務。

總的來說,當時的社區O2O還不算是一片紅海,仍然有市場空間和機會進行切入。以產品的開發背景來說無非是兩類APP,一類是“叮咚小區”“小區無憂”為代表的第三方創業公司,一類便是開發商自有的“住這兒”“彩之云”等移動端應用。

第一類像“叮咚小區”這種平臺模式,沒有用戶基礎,只靠燒投資人的錢來鋪地面工作,當時來看是圈了不少小區,但是由于沒有根基,用戶隨時會被搶走,想要做到成規模的應用不知道要燒多少年。目前傳聞好像已經倒閉了,估計資本的錢也燒的差不多了吧。

第二類應用大都停留在試水階段,扮演配合物業的角色,還沒找到完整的盈利模式?!安手啤笨梢运愕蒙掀渲械膬炐愦砹?,其垂直電商模式或許可以成為一個突破口,同阿里爭奪“最后一公里”。

而當時的BAT等巨頭還都持觀望態度,沒有太大動作,又或者是等待哪一家創業公司做起來之后再進行投資收購。很明顯,大家都把這塊難啃的骨頭放在了一邊。

由于當時公司在房地產物業這塊有相關資源,所以,我們團隊將產品的切入點定位在了物業公司,物業服務站和物業從業人員這里。而后,通過相關小區的試點,驗證產品可行性后,再將產品的使用場景拓展到進行車位信息化管理、社區商戶平臺——商戶通過物業平臺入駐小區并投放廣告、為成熟的業委會提供在線管理平臺、社區教育等等。當時,產品的名字暫時就命名為“樂業安居”,正有讓社區的老百姓擁有了我們的產品,就能安居樂業的意思。

經過一系列的產品設計準備工作,就要開始搭建APP的產品架構了。結合之前的市場調研及產品路徑規劃,以及團隊對O2O的理解,梳理了一下我對社區O2O產品架構的規劃思考,主要由4個tab組成:

  • 社區:負責連接人與人,這個部分可以滿足鄰里之間人與人的交流溝通,你既可以在這里發布相關信息尋求幫助或需求交換,也可以在這里找到志趣相投的鄰居一起去做一件事情。包括后期的業委會、居委會等等,都可以在這里展示相關信息。
  • 物業:負責連接人與物業,這個部分就是通過移動互聯網來改善業主和物業的連接效率,讓物業的服務成本降低,效率提高,也提升業主的用戶滿意度。
  • 周邊:負責連接人與O2O服務,這個部分就是第三方O2O(如家政服務、維修服務、養老服務、社區教育等)、電商團購的綜合展示舞臺,通過整合資源可實現有自己特色的O2O社區服務。
  • 我的:負責管理與”業主“有關的所有信息,如”我的報修“、”我的繳費“、若后面產品拓展做了社區教育,則還可能有”我的課程“等等。

社區o2o的產品架構

當然,第一個產品版本的開發,打算就先做2個部分——”物業“和”我的“,既然是從物業作為切入點,就先把這個點做好,后期在相關小區試點可行后,立即迭代產品,再引入其他功能讓產品的使用場景變得更加豐富起來。

如果你仔細分析,應該可以看出這里面的框架邏輯——連接。

這里就涉及到對O2O最本質的理解,它的本質是什么?O2O本質其實就是用互聯網去改善消費者和服務提供者的連接,讓他們之間的連接變得效率更高、成本更低。所以整個產品架構都是圍繞著連接去做的功課,連接人與人,人與物業服務、人與其他服務,這樣對于用戶來說,他們對你產品的認知邏輯就會非常清晰,每一次打開產品的時候,都能夠輕松地找到自己想要的東西。

就這個案例,我們嘗試著來做一點總結:

1. 做好分類

前面我們就已經說過一點,人類天生就有分類整理的習慣,有這個習慣也是為了更方便地找到自己所需要的東西。超市里的商品擺放也是如此,所有的商品需要按照不同的分類,擺放在不同的貨架上,并且上面還要貼上相應的指示牌,告訴用戶這是什么商品區域。

我們常用的Windows 資源管理器也是一個極佳的例子,試想一下:如果我們將自己電腦上的所有文檔都歸存在一個盤里,而且這個盤并沒有文件夾的形式讓你分類管理你的文件,word文檔、excle文檔、ppt文檔、pdf文檔、視頻文件、圖片格式文件等都混雜在一起,那你想要找到自己需要的文檔也則太難了。幸好在Windows 資源管理器模式下,我們可以創建文件夾,并且可以按照文件的名稱、修改日期、類型、大小等進行排序和分組,這樣才方便了我們更加快捷地找到自己所需的信息和文檔。

同理,網站或者移動APP應用也是如此,信息越多,就越需要組織和整理。我們可以根據邏輯習慣來對信息進行分類整理,如上面所舉的例子,就是根據社區O2O“連接”的邏輯進行分類的;當然,也可以直接去探究用戶的想法,了解用戶的使用習慣。一個好的產品經理,往往也是這個行業的資深人士,或者稱為行業專家。因為只有產品經理自己本身對所處行業有極深的理解,他才能更準確地命中產品架構的脈門,有時候甚至是一擊而中。

2.?平衡用戶與商業

對產品架構的設計,一方面是要了解用戶的信息需求,另一方面也要了解整個產品的商業目的和訴求。一般情況下,用戶目標和商業目標之間肯定存在著矛盾,比如用戶都不想看廣告,但企業又希望能夠把自己的業務和廣告推薦給用戶(典型如微信的朋友圈廣告)。如果一個產品只滿足用戶的目標,產品體驗當然會不錯,但這個產品也很難走的長遠,畢竟企業的終極目標是要盈利的。

這個時候,如何平衡用戶與商業,就成為考量產品經理的功底的重要一環了。在這方面,我們向微信團隊進行學習,微信在平衡用戶體驗和商業目標這一塊做的非常好。還記得2015年1月份的朋友圈廣告么,當時一經推出,便立刻成為了朋友圈的熱門話題,大家都爭相在廣告底部進行點贊和評論,仿佛品牌一下子就成為了我們身邊的朋友一樣,在朋友圈直接與我們分享故事和內容。而在社區O2O這個案例中,我們也將周邊這種帶有業務、廣告性質的功能,放在了后面的版本進行迭代開發,并沒有立即嘗試進行產品的商業化,這也是一種平衡的體現。

微信廣告

3. 重要的功能設置快捷入口

產品架構應該是結構清晰、合乎邏輯的,讓有明確目標的用戶能夠快速找到所需信息;有不確定目標的用戶,通過瀏覽和尋找,一點點地明確自己需要的信息;沒有目標的用戶,則可以在探索中激發需求。所以,對于后兩者用戶來說,如果重要功能和常用功能隱藏地太深,則很有可能會讓他們對產品喪失興趣。

為重要功能和常用功能設置快捷入口,就好比在原有的產品架構上搭了一個“快捷通道”,典型如微信將“購物”放在了“發現”這個菜單里,手Q的“購物”入口改成了“京東購物”,京東和騰訊的“聯姻”,由微信和手機QQ社交應用入口、朋友圈、朋友群、公眾號、廣點通,以及線下推廣共同組成了多場景的京東社交購物生態,匯聚了龐大的社群流量,為京東帶來了不少的新用戶和成交增長。

當然,快捷入口的設置也是一個需要權衡的過程。必要的快捷入口可以提高用戶的使用效率,也能滿足產品一定的商業目標,但是如果快捷入口過多(尤其是參雜太多商業目標的快捷入口),產品也會變得混亂和復雜,這個時候就會讓用戶的使用效率下降,有點得不償失了。所以你會看到,微信這款產品,并沒有把所有的業務都通過快捷入口的方式展現出來,而是通過在“我--錢包”里面,展示其他的第三方服務。這么一來,這些功能隱藏地如此之深,產品的用戶就不會覺得微信是一款復雜而混亂的產品了。

京東微信手機QQ購物兩周年慶典

當然,在業余時間我們自己把玩產品的時候,也可以試著去解構一下其他公司的APP產品,看下他們的產品架構是如何搭建的,又有什么地方是值得學習和借鑒的,這也是一個非常重要的學習手段。

說一下我常用的方法,分三步來走:

  1. 拆解產品骨架,將所有模塊和功能點畫成思維導圖
  2. 分析重點功能的使用場景與流程
  3. 分析次要功能的使用場景與流程

當然,分析產品的時候需要考慮很多因素,不僅是從產品設計出發,還要從行業背景、公司戰略、運營、實際資源等情況出發,才能得出更接近真相的答案。

To?B?類產品如何搭建產品架構

To B類產品(通常都是后臺產品)的設計非常具有挑戰性,因為To C類的前臺產品,大家都已經培養起了使用習慣,對功能有一定程度的理解,見過的模式足夠多,能夠建立起一定的產品模型,也容易找到參照物去模仿。但是To B類的后臺產品,你幾乎沒有什么競品可以參照和模仿,所以在搭建產品架構的時候則要求產品經理非常懂業務,非??简濸M的核心競爭力——業務知識儲備、結構化思維和系統性抽象能力。不同行業的產品可能做整體架構的思路也不一樣。

稍微簡單類比一下,產品架構復雜程度的感覺由弱到強是這樣的——

設計或者操控以下交通工具:

  • 自行車
  • 汽車
  • 飛機
  • 火箭
  • 宇宙飛船

……

是不是感覺到難度越來越大了,不過我們也算是了解了復雜產品的架構是怎么樣的了,其實依然還是有對應的方法去進行設計的。在對后臺產品搭建產品架構的時候,往往有兩種思路可供參考:

1.按功能模塊來進行劃分

什么叫按功能模塊來進行劃分?如下圖:

按功能模塊來劃分

如果一個后臺產品的目標用戶比較單一,且用戶需求也比較統一,并沒有出現說某個用戶只需要使用其中某一個功能模塊的時候,且功能和功能之間并沒有太多的邏輯關系,往往可以嘗試使用按功能模塊來進行劃分的方式。比如百度移動統計,它的目標用戶就是互聯網公司內部的運營人員、產品人員,且運營和產品關注的數據絕大部分是可以通用的,也就是說用戶需求還是比較統一的。

2.按業務邏輯來進行劃分

另一個劃分邏輯,是按業務邏輯來進行劃分。很多公司內部的信息管理系統,都是采用這種產品架構來進行設計的,因為這個產品的目標用戶往往涉及到多方角色,既有公司的業務人員,如市場、銷售、客服、前臺等,又有公司的職能部門人員,如人事、財務、行政等。這個時候再采用功能模塊來進行后臺的產品架構梳理,則顯得不是那么適用了。

按業務邏輯來進行劃分,則要求產品經理在規劃系統時要思考這個系統的作用到底是解決了什么問題,再具體一點就是——解決了哪些用戶的哪些問題。在這個大的環境下確定了之后,在需求的收集和分析的階段,就應該按照業務角色來進行相關的工作,而后到了梳理產品架構這一步才能更得心應手一些。如下圖所示,一個研發管理的子系統,就對應了這么多不同角色人員的不同需求。

按業務邏輯來劃分

那么,產品經理在做to b產品的時候,進行業務規劃和產品架構之前需要儲備哪些方面的能力呢?

  • 需要有一定的技術理解能力,幫助自己理解清楚信息在不同的系統之間是怎樣交換、存儲、耦合和解耦的。
  • 要有基本的商業邏輯思維,比如節省成本、提高營收、提升效率等。
  • 業務的整合需要對所在行業及業務本身有深刻的理解,同時對公司整體的運行邏輯也要有一定的認識,如銷售、市場、財務、運營、產品、技術等。
  • 需要有更強的抽象能力。不僅是把一個工作流程抽象成一個功能,而是要把一個業務抽象成一個系統,并且知道這個系統在產品中所處的位置;不是理清任務與任務之間的關系,而是要清楚業務與業務之間的關系,這樣的關系最后是如何交織和演化在一起,共同促進產品繁榮的。

最后,這里提供幾個優秀的后臺產品供大家參考和研習:

  • 淘寶的商家后臺
  • 有贊微商城的后臺
  • 微信公眾平臺后臺

總結來說,產品架構這件事情涉及的面非常廣,上至產品的宏觀計劃,下至產品的功能模塊,囊括產品的目標及愿景、用戶需求、商業需求、數據業務流程和設計框架,還涉及到產品的生態結構,所以要搭建好一套產品框架并不是件易事。產品經理在這條道路的學習上,也要做好一個漫長的認知迭代準備。

好的產品架構具有怎樣的特性

好的產品架構對于一個產品來說是非常重要的一件事情,就如同人的骨架之于人,房屋的框架之于房屋,是起到支撐、引導、承重的作用。說回到互聯網產品,好的產品架構要具備的幾個特征,總結起來大致是這么幾個點:易用性、穩定性、可擴展性。

什么是易用性呢?人的天性是懶惰的,試想如果用戶在一次簡單的使用產品后能記住每一個操作,而且能重復使用,不用刻意學習具體的操作,使用起來一定是很“爽”的。對于產品經理來說,我們必須竭力讓用戶能夠方便地使用產品,這就需要產品架構上能夠提供一個清晰的路徑導航,讓用戶不會產生迷路等不爽的用戶行為了。

什么是穩定性呢?這部分又通常和后臺的技術架構有所關聯,當產品不斷演進和迭代的時候,系統的架構是否能夠承受那么多用戶的同時訪問,在性能和響應速度方面有沒有什么影響。所謂的穩定性原則,就是說你提供的服務一定是穩定可靠的,是能及時響應需求的,盡量避免類似APP上突然有提示失敗、服務器異常、空等情況。

易用性和穩定性,就不再多用文字解釋了,我們來看看產品架構的可擴展性。

可擴展性其實是在傳達一個信息,就是要求產品經理在設計產品架構的時候,就要去多思考未來這個產品是否會新增加功能或者內容,也就要求產品經理要有產品規劃的意識。如果一個新做的產品剛上線沒多久,因為要新增功能,導致頁面的信息架構重新調整,相關人員怨聲載道,產品的使用用戶也會增加對產品的認知成本??梢?,產品架構的可擴展性是有多重要,產品經理需要根據實際情況及未來可預見的規劃進行構思,爭取將產品的維護成本降到最低。

#專欄作家#

壹百度,微信公眾號:倒退集,人人都是產品經理專欄作家。在線教育企業服務領域產品經理,創業公司Team Leader。曾主導多款重量級產品的產品策劃和設計工作。

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 已收藏,學習了

    來自北京 回復
  2. 現在看來還是會覺著是比較好的一篇信息結構的說明~尤其是最后的可擴展性,真的是需要相當高的視野和對行業的理解,
    才能規劃出一個相對穩定的框架來

    來自北京 回復
  3. 收藏了

    來自上海 回復
  4. 你講的是產品結構/信息結構吧,是產品架構嗎?

    來自上海 回復
  5. 想跟著BAT大咖老師學習更多系統高階產品知識嗎?
    在【產品總監修煉之道】,四位來自騰訊、百度的資深總監級導師,將和你面對面分享高階產品必備的系統知識,幫你掌握更加全面的產品專業知識和團隊管理思路……

    想了解更多詳情?立即戳>>http://996.pm/z4bLB
    也快可以聯系KK進行咨詢哦~微信/TEL:13043462422

    PS:除了咨詢問題,還能領取【產品總監課程學習筆記】! ??

    來自廣東 回復
  6. 講的不清楚,,

    來自海南 回復
  7. 人人都是產品經理這個產品好不?如果你覺得有改正的地方,可以提出你們的看法

    來自廣東 回復
  8. 產品構架很難啊~~~~

    來自河南 回復
  9. 總結的挺好的,但是現在市場上toB的產品經理越來越不好混了

    來自北京 回復
    1. 為什么不好混了,競品太多,需求者要求太多,系統越來越大嗎?

      來自湖北 回復
    2. 是的

      來自湖北 回復
  10. 確實一個好的產品架構,需要產品經理是這個業務的專家,也就是你需要使用很多的APP,然后都是這些APP業務中的專家,并且不斷的推敲為什么這個產品會這樣設計。如果自己設計會怎么設計。文中的解釋非常到位,讓自己對產品架構有一些了解和框架,讓自己在設計架構的時候,能夠有一個思考的邏輯,謝謝作者的分享·

    來自廣東 回復
  11. 用戶體驗學的不錯,繼續繼續

    來自江蘇 回復
  12. 這個只能算產品信息結構圖吧,算不上產品架構吧

    來自江蘇 回復
    1. 我也感覺是,產品架構還包括技術層面的,這里都沒有提到

      來自北京 回復
  13. 以前沒做過,但是公司又沒有人帶,一些標準啥的都不知道,哎。 ??

    來自北京 回復
  14. 現在還是以看為主,最多去做點小修小補

    來自上海 回復
  15. 我想弱弱的問下,文中提到的那幾個后臺怎么去看呢 ??

    來自北京 回復
  16. 您好,壹百度先生,想和您談一下合作,不知怎樣才能聯系到您

    來自北京 回復
    1. 可以關注我的公眾號,然后在里面留言,留下你的聯系方式和合作目的

      回復
  17. 干貨
    拆解產品骨架,將所有模塊和功能點畫成思維導圖
    分析重點功能的使用場景與流程
    分析次要功能的使用場景與流程

    來自浙江 回復
  18. 不明覺厲,慢慢看 ??

    來自廣東 回復
  19. 別整天張嘴閉嘴就是各種名詞 架構 ,毛線。好好畫你原型去

    來自山東 回復
    1. 你真沒素質,人家在解釋知識,你不想看就別看

      來自浙江 回復
  20. 贊一個,暫時還處在看,到設計的階段還有一段路要走,感謝分享 :mrgreen:

    來自廣東 回復
  21. 不錯

    回復
  22. 產品架構,感覺好吃力啊 ??

    來自浙江 回復
  23. :mrgreen:

    來自廣東 回復
  24. 這個很牛的感覺。有時間我要細細看看

    來自四川 回復
  25. 讀完之后,有很多的收獲。謝謝 ??

    來自香港 回復
  26. :mrgreen:

    來自北京 回復
  27. :mrgreen:

    來自廣東 回復