深度 | 在高級產品經理眼裡，產品架構是怎樣的？

05-03

經歷過需求的採集、分析和篩選，我們對產品的定位和用戶的需求有了越來越深刻的認識，對整個產品方向的把控和版本迭代節奏也會更有感覺。這種感覺你也可以稱之為「產品感」，雖然講得有點懸乎，可又的確存在。

以我個人的經驗來看，不斷地了解用戶需求和場景，也是積累產品感的一種良好的方式。有了不錯的產品感，我們要繼續往前走，才能將產品推向一個更高的高度。

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

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

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

什麼是產品架構

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

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

我們直接看幾個例子：

天貓商家工作後台

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

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

臉萌官網

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

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

典型的幾個產品架構模型

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

第一種，層級結構（hierarchical structure）

層級結構模型

書中原文是這麼來描述這種產品架構的——

在層級結構中，節點與其他相關節點之間存在父級/子級的關係。子節點代表著更狹義的概念，從屬於代表著更廣義類別的父節點。不是每個節點都有子節點，但是每個節點都有一個父節點，一直往上直到整個結構的父節點。層級關係的概念對於用戶來說非常容易理解，同時軟體也是傾向於層級的工作方式，因此這種類型的結構是最常見的。

這種傘狀式的產品架構，恐怕是互聯網、移動互聯網產品中使用最多的一種信息結構，比如我們使用頻度最高的微信、手q，以及各類to c 的移動APP，甚至是複雜的to b 類產品，都是使用這種產品架構進行產品設計。

這種架構的特點是符合人類的認知習慣，因為人類天生就有分類的習慣，比如書桌，我們會習慣把書籍放在一起，把錄音卡帶等放到一邊；又比如我們的衣櫃，我們一半會將不同季節的衣服放在不同的位置。在生活中，整理物品是為了更容易地找到自己需要的東西。

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

蜻蜓fm的產品信息架構

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

大家都有過逛商場的經驗，其實有時候做產品和逛商場很相似，有的商場設計的比較合理，很容易地能夠讓逛商場的用戶找到想要的商品品類，有的商場設計卻經常讓你迷路，來來回回折騰好幾次。在確定產品架構的時候，考慮產品架構的深度和廣度成為了產品經理的一道必選題。

就拿淘寶APP和唯品會APP來說，淘寶屬於廣而深的架構，唯品會則屬於淺而窄的架構（相對）。在偏深度的架構中，用戶操作起來效率不高，用戶獲取信息、完成目標任務的路徑增多，但是相對而言，減少了用戶選擇的入口。在偏廣度的架構中，用戶面對的入口增多，在選擇入口的時候比較費時，但是減少了用戶的操作路徑。

廣度和深度的架構模式

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

第二種，自然結構（organic structures）

自然結構模型

原文描述如下——

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

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

好奇心日報官網

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

第三種，線性結構（sequential structures）

依舊來看下原文描述——

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

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

金山快盤專題頁

上圖就是金山快盤做的一個活動專題頁，通過線性結構講故事的方式來將自己「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產品，看下他們的產品架構是如何搭建的，又有什麼地方是值得學習和借鑒的，這也是一個非常重要的學習手段。

說一下我常用的方法，分三步來走：

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

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

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

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

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

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

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

……

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

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

什麼叫按功能模塊來進行劃分？如下圖：

按功能模塊來劃分

如果一個後台產品的目標用戶比較單一，且用戶需求也比較統一，並沒有出現說某個用戶只需要使用其中某一個功能模塊的時候，且功能和功能之間並沒有太多的邏輯關係，往往可以嘗試使用按功能模塊來進行劃分的方式。

比如百度移動統計，它的目標用戶就是互聯網公司內部的運營人員、產品人員，且運營和產品關注的數據絕大部分是可以通用的，也就是說用戶需求還是比較統一的。

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

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

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

按業務邏輯來劃分

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

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

最後，這裡提供幾個優秀的後台產品供大家參考和研習：

淘寶的商家後台
有贊微商城的後台
微信公眾平台後台

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

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

好的產品架構對於一個產品來說是非常重要的一件事情，就如同人的骨架之於人，房屋的框架之於房屋，是起到支撐、引導、承重的作用。

說回到互聯網產品，好的產品架構要具備的幾個特徵，總結起來大致是這麼幾個點：易用性、穩定性、可擴展性。

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

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

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

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

本文由人人都是產品經理社區專欄作家（微信公眾號：倒退集）原創發布
人人都是產品經理專欄作家。在線教育企業服務領域產品經理，創業公司Team Leader。曾主導多款重量級產品的產品策劃和設計工作。
未經許可，禁止轉載