經歷過需求的采集、分析和篩選，我們對產品的定位和用戶的需求有了越來越深刻的認識，對整個產品方向的把控和版本叠代節奏也會更有感覺。這種感覺妳也可以稱之為“產品感”，雖然講得有點懸乎，可又的確存在。以我個人的經驗來看，不斷地了解用戶需求和場景，也是積累產品感的壹種良好的方式。有了不錯的產品感，我們要繼續往前走，才能將產品推向壹個更高的高度。
產品經理之前已經將產品第壹個版本的功能需求都整理好了，也輸出了壹份詳細的功能需求列表，這個時候要做的工作就是為產品搭建壹個好的架構，也就是產品設計的第三個環節——搭框架了。任何壹款互聯網產品都應該有壹個產品架構，有了這個強大而堅實的架構作為產品的基礎，我們才能將產品需求給壹個壹個填充進去，讓產品變的豐富立體，更有血有肉起來。
那究竟什麽是產品架構，產品經理又該如何來搭建壹套好的產品架構，我們來接著往下看。
什麽是產品架構
任何壹個產品都有自己的產品架構（也有很多人把它稱為信息架構），就好比每壹個人都有自己的骨骼系統壹樣，妳的骨架大小決定了妳大致的身材會是如何，每個人的身材都不壹樣，高、矮、胖、瘦各有不同。
有些產品的產品架構比較繁雜，例如大部分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上突然有提示失敗、服務器異常、空等情況。
易用性和穩定性，就不再多用文字解釋了，我們來看看產品架構的可擴展性。
可擴展性其實是在傳達壹個信息，就是要求產品經理在設計產品架構的時候，就要去多思考未來這個產品是否會新增加功能或者內容，也就要求產品經理要有產品規劃的意識。如果壹個新做的產品剛上線沒多久，因為要新增功能，導致頁面的信息架構重新調整，相關人員怨聲載道，產品的使用用戶也會增加對產品的認知成本。可見，產品架構的可擴展性是有多重要，產品經理需要根據實際情況及未來可預見的規劃進行構思，爭取將產品的維護成本降到最低。