本文為2022摹客RP原型工具測評大賽一等獎作品

原型設計工具是很多交互設計師以及產品經理都會使用到的，國產原型工具越來越多，給了用戶許多選擇，而真正滿足用戶需求的原型設計軟件，才是為大家所選擇的。作者就摹客RP進行評測，結合實際工作案例，將蘇寧智慧屏OS系統中的“自定義頻道”功能作為測試案例，從交互設計的角度對產品進行體驗測評。

一、產品評測簡介

原型設計軟件是設計師、產品經理使用頻率很高的工具，最早期的軟件是Axure，它因為輕量化，功能豐富的特點也一直很受大家追捧，但作為一款國外開發的軟件，卻也有很多局限性，比如使用者權限，團隊協作、購買價格等，正是由于這些因素，讓國內很多公司看到了這塊市場，紛紛入局，開發相關的軟件去競標Axure；從早期的藍湖到現如今的各大品牌的原型設計軟件，給了項目設計人員更多的選擇，大大提高的團隊協作效率。

1. 測試背景

目前我們公司設計團隊使用的原型設計工具就是Axure，在實際項目中，團隊交互原型的呈現效果很差，統一性不強，組件的復用、新增、修改等同步的效率很低。原型設計樣式和規范五花八門，給閱讀的人員造成很多不便，盡管團隊在每個版本結束之后都會對原型設計的規范進行匯總和要求，但是設計師在進行原型設計時，都習慣了一遍做原型，一遍去比對熟悉規范，都是獨自去審查，大大影響了原型設計的統一性；

項目組的設計人員負責的模塊都比較獨立，繪制原型頁面過程中，無法實時同步去協作，繪制結束后還需要保存源文件或者導出html分享給項目組人員，導致Axure的共享協作成本變得非常高。

2. 測試目的

項目團隊想通過引入國內原型設計工具來替代Axure，幫助團隊更加高效地進行項目項協作，剛好應邀參加「摹客與人人都是產品經理」聯合舉辦的關于“摹客RP評測文章”的比賽。

所以就想著通過評測這款產品是否在團隊中使用和推廣，以及通過使用體驗提出一些建議，希望自己的拙見和思考能夠對摹客RP的產品設計能有一些幫助。本篇文章通過實際工作中的項目，蘇寧智慧屏OS系統中的“自定義頻道”功能作為測試案例，從交互設計的角度對產品進行體驗測評。

3. 測試環境

測試設備：Macbook pro 2019

測試產品：摹客RP網頁端、客戶端

測試形式：以實際工作項目為例，對摹客RP的產品功能使用和交互操作進行體驗評測

測試用時：四周

4. 測試大綱

測試主要從以下三方面進行：產品的設計框架、產品使用的操作流程、產品的設計組件；框架是產品最底層的基礎部分，好的框架會讓用戶一目了然，比如他的功能是有哪些，功能信息怎么去布局的，信息的層次感有沒很有分明，這些都能有效率的讓用戶閱讀和使用產品；操作交互是能讓用戶對產品體驗更直觀，如在某一功能的使用流程中，用起來方不方便，交互方式的操作是否順暢，設計和組件設計決定和產品的“顏值”，設計原則、模式和合理的組件使用能提升產品的價值和表現力，所以本次的測試大綱如下：

• 框架：功能、設計布局、信息層次
• 操作：使用流程目標、主要任務
• 設計和組件：原則、模式、組件樣式

二、角度1：設計框架

第一個角度主要是從設計框架來進行體驗，主要包括產品的功能結構、布局的信息層次；兩端主頁面的框架設計基本是保持一致的，均是左右結構，但還是有很多差異化的細節設計；

1. 控制臺頁面

網頁端拆解圖：

客戶端拆解圖：

（1）左邊區域對比

對比可以看出網頁端的側邊欄信息更多，有logo，有相關聯的工具鏈接，導航菜單類別多達7個，而客戶端側邊欄功能比較簡化，只有用戶信息和導航菜單，且導航菜單只有5個。

（2）右邊區域對比

在內容區上，網頁端和客戶端的框架是保持一致的，都是頂-中-底三層：

1. 頂層：網頁端菜單標題下方會展示詳細的項目和項目集數量信息，客戶端僅展示標題；
2. 中層：展示常用功能，如新建項目或項目集、搜索功能，樣式和布局基本保持一致；
3. 底層：網頁端項目或者項目集支持多種展示方式，且可以通過篩選條件進行查找，客戶端僅支持列表展示，不支持篩選條件查找。

2. 原型設計頁面

原型設計頁面和Axure的頁面相似度很高，大致可以拆分成四大部分：標題和工具欄，左邊功能區分上下兩層，可以上下收縮拉伸，中間是原型設計區域，右邊設置面板區主要屬性、交互、備注三個主要功能。頁面的布局符合設計師使用習慣，理解成本很低；網頁端和客戶端的也是統一的。

3. 體驗小結

整體來說，兩端的控制臺主頁面滿足了設計師基本的使用需求，布局中規中矩，但兩端細節差異還是有很多的，雖然是不影響用戶正常使用，但在實際操作中，設計師需要花很多時間來適應兩端頁面和操作的差異，所以在產品評測過程中一直疑慮：同一套信息和內容，為什么要做兩套控制臺頁面樣式來增加設計師的學習和使用成本呢？信息內容布局的差異化會影響設計師能否快速熟悉功能，操作的差異化會影響設計師的體驗感。

為了驗證統一性的重要性，我找了市面上主流的設計工具做了對比，如下圖，在多端統一性上（忽略極小的差異化細節），他們的共有率達到了100%，所以足以證明這些產品對統一性的重視程度。

關于操作臺頁面統一性的優化方案如下所示：

優化點1：兩端的主頁面側邊欄的信息框架可以保持一致，首先是logo、用戶賬號信息的位置；其次是導航菜單的數量，可以讓用戶在兩端之間切換使用時，通過統一性加強用戶對界面的理解

優化點2：兩端的右邊操作區域針對項目和項目集的管理和篩選，展示方式的多樣性應該保持同步，包括配置篩選條件也可以同步；

優化點3：兩端關于全部菜單的功能框架的設計，可以在多級菜單（全部>項目集1>項目集2）和一級菜單（全部）中二選一，復用一種設計樣式，降低開發成本；

優化點4：兩端關于“設計團隊的切換”的設計，網頁端點擊團隊名稱出下拉菜單，進行團隊切換，客戶端點擊側邊欄的用戶名，出現次聯菜單，再找到團隊切換列表，兩端可以在組件使用和入口方式的設計上統一，保證信息內容、位置的統一性的前提下，使用可復用的設計樣式，降低開發成本。

原型設計頁面，功能很全面，使用起來很便捷，整理了如下優缺點：

爽點1：如文字元素的屬性設置點非常多，英文大小寫，首航縮進等，可設置的參數很多；

爽點2：支持畫板響應式布局，選中畫板作為對象時，可以在屬性面板中進行刪除；

爽點3：可以創建項目資源庫，包括顏色、文本、組件等設計資源，設計更加高效；

問題點1：相對應的屬性列表展開顯示后，模塊空間的沒有充分利用；如圓角這個參數可以選擇百分比的樣式，就需要另起一行；

優化方案1：屬性面板可以保留比較常用的屬性參數，新增加的參數設計如果不常用會占據空間，且在黑色色彩模式下，信息的閱讀效率會收到影響

問題點2：右邊整塊屬性面板不支持自適應拉伸，位置是固定的，如元素透明度這個參數為100%時，數字也不能夠顯示全。

優化方案2：屬性面板增加自適應收縮，會讓頁面空間更加靈活。

三、角度2-操作流程

第二個角度主要是從相關功能的操作使用流程作為切入點去體驗，主要7大核心流程和14個操作小任務。

1. 新建項目和新建項目集

任務1：在控制臺頁面找到功能的入口，新建一個名為“自定義頻道”的項目和兩個名為“Biuos1.0”、“蘇寧智能終端”的項目集

客戶端操作示例：在首頁菜單，有個單獨項目編輯區域，可以直接點擊進行命名和選擇尺寸。在其他菜單下，如果有創建按鈕，均可以點擊，頁面中間會跳出彈窗，直接對項目和項目集進行創建編輯。

網頁端操作示例：在相關的菜單中，只要有創鍵按鈕，就可以進行創建編輯，僅支持點擊按鈕-跳出彈窗的途徑。

設計爽點1：在客戶端，有個很大的項目創建區域，用戶可以命名，選擇尺寸，很直觀，增加了項目創建的入口；

設計爽點2：網頁端可以創建項目和項目集，客戶端只能創建項目，雖然沒有統一，但是從使用習慣的角度思考，這個設計還是非常好的，項目集是比項目要大的，根據設計師使用習慣，考慮到網頁端的網絡鏈接，大多數用戶都會下載客戶端去操作，并且當項目責任人建立好項目集，負責相關模塊的設計師就可以專注在項目上，避免了亂建項目集，造成混亂；

體驗問題1：兩端的很多基礎導航菜基本都有新建項目或新建項目集按鈕，考慮到用戶在切換不同菜單時，都能提供這個入口，雖然能方便用戶操作，但有一些過度引導；

優化方案1：減少過度設計，菜單應匹配相對應的信息需求。例如用戶切到我的收藏菜單，需求就是去查看收藏項目，新建項目就是非必要的選擇，加上就會變的強行引導；

體驗問題2：在創建項目時，通過彈窗的方式去進行創建編輯，這樣會讓操作流程變得復雜，而且彈窗中的信息優先級不高，創建結束后也都可以修改；

優化方案2：模態彈窗對用戶的干擾程度很高，創建項目應該是比較簡單的操作，不需要強干擾的組件去提示用戶，建議可以直接過度到原型設計界面。

2. 項目或項目集的移動

任務2：在控制臺頁面，把項目“自定義頻道”移動歸類到“Biuos1.0”的項目集

客戶端操作示例：項目和項目集僅有列表的展示方式，將項目“自定義頻道”移動至項目集“Biuos1.0”時，需要點擊項目中的操作按鈕，彈出操作列表，選擇移動，跳出彈窗，選擇項目集確認，無二次彈窗確認。

網頁端操作示例：項目和項目集有列表和宮格兩種展示方式，將項目“自定義頻道”移動至項目集“Biuos1.0”時，需要點擊項目中的操作按鈕，彈出操作列表，選擇移動，跳出彈窗，選擇項目集確認，再彈出彈窗二次確認。

體驗問題1：網頁端和客戶端移動項目的過程中，第一次都需要有彈窗，選擇項目集分類，但下一步的操作，網頁端使用模態彈窗讓用戶二次確認，確認移動成功后有提示?？蛻舳顺晒σ苿映晒?，沒有提示。

優化方案1：結合兩端的優缺點，首先網頁端避免使用確認移動的二次彈窗，減少操作流程，客戶端移動成功后，增加操作提示，提升交互感知。

體驗問題2：項目或項目集不可以直接拖拽進行移動管理操作，只能通過按鈕點擊選擇移動選項才能操作，操作比較遲緩。

優化方案2：為移動操作增加鼠標拖拽功能，更加快速的進行項目歸類，效率高。

3. 頁面和畫板管理

任務4：選中原型設計頁面的左邊功能區的【頁面】tab，為“自定義頻道”功能創建若干個頁面，隨機對頁面進行設置操作（創建、重命名、移動、復制、刪除、撤銷刪除）

操作示例：點擊「添加」按鈕，可以進行頁面創建，選中任一頁面，右擊出現彈框，進行選擇重命名、移動、復制、刪除等操作；雙擊頁面標題都可以進行頁面名修改，拖拽頁面可以進行運動歸類，選中頁面點擊設備刪除鍵，出現彈窗提示是否刪除。刪除后，設備無快捷鍵撤銷刪功能。

新建和復制新頁面后，新頁面變為當前頁面，且有背景底色，但無法使用設備刪除鍵直接進行刪除操作，需再次點擊選中新頁面，讓文字變為純白色，才可以刪除文件。

體驗問題1：頁面刪除后沒有進行刪除撤銷的快捷鍵“command+z”操作，“撤銷”快捷鍵是設計師最常用且依賴度很高的操作。

優化方案1：增加“撤銷”快捷鍵的使用。

任務5：選中原型設計頁面的左邊功能區的【頁面】tab，使用回收站功能、將“某一頁面”刪除再從找回

操作示例：選中某一頁面，進行刪除操作確認，點擊回收站按鈕，開始回收模式，找到分頁面，鼠標懸停在頁面上，顯示恢復和刪除按鈕，點擊恢復按鈕，再彈窗確認，頁面恢復。退出回收站模式，才能顯示當前所有頁面。

設計爽點1：增加“回收站“模式，用戶可以找回頁面，擴大了容錯范圍；

體驗問題1：回收站模式退出的按鈕樣式和工具欄的撤銷重合度高，易混淆；其次這里的回收站模式需要開始和關閉兩種狀態，整個過程中需要2次點擊操作。

優化方案1：回收站對應的是頁面，單獨再加一個tab對于信息內容切換會更便捷，省去“回收站”，模式開啟和關閉的流程。

任務6：選中原型設計頁面的左邊功能區的【頁面】tab，選擇“自定義標簽”頁面，切換到【圖層】tab，對頁面中的“默認狀態”畫板中的圖層進行順序調整

操作示例：選中畫板其中一個圖層，然后移動到另一個圖層的上方或下方，調整圖層順序，但不能進行拖拽移動，只有置于頂層和底層的按鈕操作。

體驗問題1：設計師在制作原型圖時，需要調整畫板中的圖層順序，置頂或置底的操作不能解決使用者調整圖層順序的效率問題，移動拖拽能靈活快速的給圖層排序。

優化方案1：增加鼠標拖拽移動功能，讓圖層位置的移動更加方便。

4. 項目原型設計制作

任務7：在“自定義標簽”頁面編輯區進行畫板的創建、設備和尺寸選擇、復制、命名、屬性設置

操作示例：工具欄中使用“添加輔助畫板”或者快捷鍵A創建畫板，在原型編輯區域左下角可以進行進行設備和尺寸選擇、使用快捷鍵command+c/v、直接雙擊畫板標題可以進行重命名、選中畫板后，在右側功能區域調整參數進行屬性設置。

設計爽點1：可直接在視圖中雙擊畫板名稱文字，直接選中進行修改，不用在圖層頁面找對應頁面進行名稱修改，圖層的空間有限，當畫板數量超過之后，就需要上下移動來回審查，所以這個設計細節讓操作更加聚焦，對于大批量的畫板名稱修改，很節省時間。

體驗問題1：畫板設備和尺寸選擇的優先級高于畫板快捷創建，通過鼠標懸停的操作方式呼出多級菜單分類，交互的可控性比較差。

優化方案1：類比市面上其他產品，基本都是快捷鍵A調出設備尺寸選擇，而且大多是在屬性面板使用列表下拉的方式展示。快捷鍵“A”的使用對象可以重新定義，加強快捷創建畫板的優先級，重新設計畫板設備和尺寸選擇的位置和交互出現方式。

體驗問題2：在復制畫板時，不支持選中畫板后，使用“option+鼠標鍵”快捷操作進行復制拖拽，新畫板不能任意的拖拽到自己想要的位置。

優化方案2：增加快捷鍵的使用。

任務8：在“自定義標簽”頁面的畫板中利用工具繪制低保真設計稿，設置元素屬性

操作示例：選中自定義頁面，在默認狀態的畫板中對元素文字、形狀、顏色等屬性參數進行設置。

例1：在畫板中縮放矩形，設置面板中的寬高參數沒有變化；

例2：在屬性中將初始矩形外邊框寬度值從“1”變為“2”，但頁面中元素沒有變化，仍然是1，只能在點擊非寬度的參數任意區域后，寬度數值的變化在頁面中才能響應；

操作示例：將圖片拖入某畫板內，圖片位置在畫版的頂部位置，當將畫板拖去來，在左邊功能區的圖層tab中，圖片還在原來畫板頂部顯示，拖動畫版，圖片在畫版外和畫板一起移動。

體驗問題1：兩個例子都是屬性面板和畫板聯動無響應的問題，不管是畫板中的元素聯動屬性面板的參數，還是屬性參數聯動畫板中的元素，都沒有實時響應。尤其是外邊框的寬度值無法實時顯示，這就對設計的效果很難把控。

體驗問題2：圖片拖進和拖出畫板時，圖片圖層的歸屬不清晰。

優化方案：這兩個槽點屬于產品的性能問題，可針對性能這個點，加強優化。

任務9：在“自定義標簽”頁面的畫板中查看元素與元素，元素與畫板，畫板與畫板的距離，進行元素和畫板的距離調整

使用鼠標和鍵盤鍵可以查看“默認狀態”畫板中元素的間隔、與相鄰畫板的間隔，在懸停展示間距的同時去調整位置距離。

體驗問題1：只能查看同一個畫板中元素之間的距離，無法查看畫板之間的距離，且同畫板中不能在顯示距離間隔的狀態下，對元素位置進行調節。

優化方案1：增加設計優化，完善距離相關的測量和位置移動的操作問題，提升設計體驗和用戶的原型設計效率

任務10：在“流程圖”頁面中使用流程模式，為“自定義頻道”功能繪制邏輯流程圖

操作示例：在「流程圖」頁面，在工具欄中打開流程圖模式，為“自定義標簽”功能畫一個簡單的邏輯流程圖，梳理業務流轉的邏輯關系。

設計爽點1：產品內置了很多流程圖組件，當鼠標獲取矩形元素的連接線端點后，開始移動至松開鼠標結束，流程組件庫彈窗會自動出現，可以選擇對應的矩形組件。并且制作好摹客RP源文件可以和自帶的PRD文檔工具相關聯，選擇帶有流程圖內容的畫板，直接轉化成圖片導入到文檔中，這個聯動做的相當給力。

任務11：對“自定義頻道”功能的原型項目進行保存

操作示例：當設計結束或中斷時進行項目保存時，可以使用保存按鈕或者快捷鍵“command+s”對項目進行保存。

體驗問題1：當用戶保存后，頁面并無明顯的關于“項目已經被保存或者可以實時進行保存項目”的提示；

優化方案1：首先用戶不知道的項目保存的時效性，可以使用“Toast”提示用戶。

5. 創建交互demo

任務12：為“自定義頻道”功能頁面的跳轉和設置保存創建頁面交互事件

操作示例：在當前頻道有內容的場景下，開啟調整模式，移動頻道順序，再次確認頻道，移動跳到頻道顯示或隱藏功能區域，為頻道自定義設置創建交互事件，最后使用彈窗對頻道順序調整、顯示、隱藏這些操作進行數據保存；在右邊功能區的選擇“交互”菜單點擊「添加交互」按鈕，對事件屬性參數進行設置。

設計爽點1：在使用Axure原型工具時，通常一個頁面我們會使用文字描述主要信息和交互操作；例如，在自定義頻道設計的頁面主要就是標題、頻道名稱以及狀態圖標，這是顯性化的信息。

對應保存的的操作還有各種隱性信息和操作，比如設置保存的彈窗，不可操作的提示、網絡異常的提示等；我們會使用很多靜態頁面去描述隱形信息和操作。但摹客RP的原型工具支持的主輔畫板的模式，可直接設計交互轉場、提示等隱形操作，更直觀的呈現原型設計效果。

6. 項目原型設計預覽

任務13：使用播放功能或進入摹客協作模式預覽“自定義頻道”原型設計和交互效果

操作示例：在工具欄點擊播放按鈕，預覽“自定義頻道”功能的原型設計和交互點擊效果；點擊發布，進行項目分類，進入慕客協作網頁端查看所有頁面和畫板以及交互效果。

體驗問題1：單獨演示預覽時，視圖窗口只展示頁面，不展示頁面內的畫板；在慕客協作網頁端可以進行查看所有內容，當使用網頁端查看畫板內容的過程中，有多次無法快速找到「畫板」入口的場景，查看畫板的入口不是很容易被注意到。

優化方案1：演示預覽狀態下，增加“查看畫板”的入口，在慕客協作的網頁端強化“查看畫板”的入口

7. 項目多人協作

任務14：發送項目或項目集鏈接邀請協作人，協作者點開鏈接進入原型設計頁面

操作實例：在操控臺找到“自定義標簽”的項目，點擊按鈕找到「成員管理」，跳出彈窗，復制鏈接，發給協作人，協作者點開鏈接進入頁面協作

體驗問題1：項目管理人分享項目鏈接給協作者，協作者點擊鏈接直接進入原型設計頁面進行操作編輯，在網頁端從原型設計頁面返回到操作臺頁面后，再點擊項目，無法進入原型設計頁面；客戶端可以正常操作。

優化方案1：打開網頁端重新進入頁面的權限，讓用戶能夠自由進入或退出頁面。

8. 體驗小結

這部分通過最常用的7個交互操作，建立以目標為中心的體驗流程，再細分出了14個操作任務對產品進行體驗說明。操作體驗主要聚焦在統一性、功能設計、交互操作效率、細節設計。首先在任務流程中體驗到的爽點設計，體驗是非常不錯的，其次是針對相關的一些設計問題也有描述并提出自己的優化建議。

四、角度3：設計和組件

第三個角度主要是從設計組件來進行體驗，這部分內容主要有如下6個體驗點組成。

1. 導航菜單

網頁端和客戶端對于導航菜單（“全部”）組件的結構不一致，網頁端的全部菜單下會展示二級菜單，客戶端沒有；兩端菜單數量都不相同；

優化建議：導航菜單組件結構和數量統一。

2. 圖標

• 網頁端全部菜單的圖標和文案語義不匹配，一個是代表“首頁”含義的圖標，另一個文案卻使用“全部”文字。
• 網頁端和客戶端的“模版例子”菜單的圖標不一致。
• 網頁端的導航菜單圖標全是面性圖標；客戶端是有面性和線性圖標兩種，首頁是面性圖標，其他全是線性圖標。
• 網頁端和客戶端的“項目”圖標列表式展示狀態下的顏色和設計形式上不統一，其次項目和項目集的圖標的區分不明顯。

優化建議：兩端的頁面相同圖標需要保持一致，包括類型，樣式，統一性，減少差異化，關于圖標設計表意要傳達精準一點。

3. 按鈕

新建項目和新建項目集是產品的兩個重要功能，從功能重要程度來說應該是要保持一致的，目前設計明顯是新建項目的優先級高于新建項目集，雖然都是用“圖標+文字”的按鈕樣式，但圖標的樣式過于簡單，且新建文件使用強提示的高亮底色，更能吸引注意力。

競品中，如藍湖、即時設計、Figma、Pisxo的功能和摹客RP一樣都有新建文件（項目）和新建文件夾（項目集）功能，競品基本都保持相同的設計樣式，保證功能優先級是一樣的，僅有mastergo雖然按鈕和摹客RP一樣使用強提示按鈕，但它的功能框架設計和摹客RP不一樣。

它創建文件夾的功能放在左邊菜單的創建團隊中，新建文件的按鈕和文件導入是獨立的，雖然設計樣式不一樣，新建按鈕也相對突出了，文件導入的按鈕還有動畫效果。

優化建議：可借鑒主流的原型工具類的設計方案，平衡功能的優先級，在圖標設計樣式上讓功能更加形象。

4. 彈窗對話框

（1）彈窗樣式設計的統一性，如新建和刪除項目或項目集時的彈窗按鈕，它并不是特殊使用場景，都僅需要“確認”和“取消”簡單操作，但是鼠標懸停文字按鈕上的樣式是不一樣的。一種是加淺灰底色，文字沒變化，另一種是改變字體的透明度。

（2）多次彈窗增加了操作流程，如網頁端項目移動時，會有二次彈窗確認。

優化建議：彈窗的按鈕設計樣式上可以保持一致，對于產品中的個別功能的操作，建議少用或慎用彈窗組件，縮短操作流程。

5. 文案

（1）文件界面的左邊功能區的“圖層”菜單中包含畫板和圖層信息，這個標題名稱和內容不對應，表述不精準。

（2）頁面刪除的彈窗提示文案沒有給出完整且能防錯的的提示，彈窗只提示是否刪除當前頁面，并沒有提示用戶如何找回和被刪除文件的去向。

如下例子為操控臺項目刪除和原型設計的頁面刪除：項目刪除的文案：“確定將此次項目加入回收站”，頁面刪除的文案：“確定要刪除當前頁面嗎？”

（3）新建項目和新建項目集兩個按鈕的文案表意不精準，改為“文件和文件夾”，這樣的表述更簡單明了。

（4）導航收藏菜單名稱不一致，網頁端用“收藏”，客戶端用“我的收藏”，可以統一為“我的收藏”。

優化建議：關于文案部分，主要包括菜單欄、圖標、按鈕、彈窗提示文字等應用場景，進行修改完善。

6. 色彩模式

產品的主色調很深，沒有淺色色彩模式可以切換，同類的主流產品基本都是默認淺色，如即時設計、Masetrgo、Pisxo等都以默認淺色界面，Figma更是支持淺色深色切換；

優化建議：因為用戶對顏色的接受和敏感度都不一樣，提供深淺色兩種顏色模式進行切換，可以在界面色彩運用上滿足不同使用者的需求，若不提供，建議淺色模式，白色在感官上更加干凈、整潔。

7. 體驗小結

設計和組件主題包括6個部分，這些在產品評測，是很容易被注意的設計點，也是產品最基礎的組成元素；它的設計呈現決定了用戶的好感度，好的設計是需要通過這些元素來表達它的設計原則和理念；組件的設計和使用也是要合理和克制的；例如導航菜單和圖標設計應該在網頁端和客戶端保持一致；文案表述的應該精準、簡單、明了；按鈕和彈窗設計也可以再克制一點，色彩模式需要干凈簡潔，最大程度的減少對用戶的干擾，提升用戶的粘性。

五、測試總結

以上就是四周產品測試總結分享了，這篇測評文章主要是從交互的三個角度：頁面框架、頁面操作流程、頁面組件設計，通過深度使用和體驗這款產品，從中提煉出一些想法和建議，這里就個人使用體驗做出以下終結。

1. 產品關聯性

摹客RP這款原型設計工具與視覺、產品的關聯性方面設計的很好：作為一款原型設計軟件，它的功能很豐富，覆蓋了設計師做原型設計的大部分場景，能利用視覺思維發揮產品優勢，在項目協作，橫向和產品相關的工作內容進行關聯。

• 在設計上，這點主要體現它可以像頁面視覺設計一樣創立組件庫（文本、顏色、組件），團隊可以組件共享，大大的提升的高保真設計原型的設計協同效率；
• 在產品上，可以和，摹客PRD文檔工具進行關聯能夠導入RP源文件進行資源利用。

2. 功能設計

• 超預期的功能：開啟流程圖模式，產品內置了很多流程圖組件，選擇組件的設計方式非常的超預期，使用起來很便捷，操作更順暢，流程圖還可以直接導入到摹客PRD文檔工具中。
• 實用性的功能：主頁面中的回收站菜單和原型設計頁面左邊的回收站模式，回收站設計的本質是幫用戶避免誤操作，挽回損失；不管是在操控臺的找回項目或者項目集，還是在原型設計頁面對頁面進行找回的使用場景中，回收站這個功能和模式設計都能很好的容錯；
• 過度設計的功能：例如兩端的操控臺主頁面，很多基礎導航菜單都有重復的新建項目和項目集按鈕，菜單導航應該有相對應的內容；不應該站在“自己以為的用戶方便”的角度，去增加重復的設計。

3. 統一性差

這一點在產品體驗中感覺是十分明顯的，設計工具軟件，基本都有網頁端和客戶端的，控制臺頁面都不會進行差異化設計，所以當第一次在不同端打開摹客RP控制臺頁面時，呈現出的是不一樣的內容，我的第一印象是：有這么多不一樣的地方啊，我要花點時間再看看對比下？我剛才的那些操作入口在哪里??？

• 布局：在“頁面框架”已經有提及過，包括控制臺頁面的布局，側邊菜單欄的設計，項目和項目項目集的展示方式，客戶端都有不小的差異；
• 操作：如項目移動的操作，在網頁端需要二次彈窗提示，客戶端就僅需要一次提示；
• 功能：如多人協作，網頁端和客戶端的功能操作邏輯也不一樣，點擊鏈接，網頁端進入頁面再退回控制臺，重進原型設計頁面就被禁止了；客戶端可以正常操作。

4. 交互操作效率

在交互操作上產品要有暢通感，即操作起來夠舒服，能夠給予操作有效提示，能夠在進行任務操作時有效率；

• 流程和組件：控制臺移動項目的交互操作應是一個極簡單的操作，但實際產品中使用了強制性的模態彈窗和2次操作彈窗進行確認，操作步驟多且干擾程度很強。
• 交互方式：產品有一些比較實用的交互方式沒有被應用，如拖拽移動的操作，在控制臺頁面項目和項目集不能拖拽歸類，在原型設計頁面中畫板中的圖層不能拖拽移動；
• 快捷鍵：主要集中在撤銷、復制等操作；在原型設計頁面，如刪除的頁面不能使用快捷鍵“command+z”撤回，如選中畫板后，不支持使用“option+鼠標鍵”進行脫拖拽；如使用快捷鍵“a”畫板快捷創建的邏輯。

5. 細節設計

在摹客RP體驗過程中，注意到很多設計細節，有很多不錯的地方，也有很多需要優化完善的設計點，如下所述；

• 優點：流程圖模式中的設計操作順暢，還可以直接在畫板中雙擊修改名稱；
• 缺點：第一點產品文案很多地方都表述不準確，彈窗在很多操作場景下的不合理使用；

第二點產品性能問題，很多交互操作過度不自然，轉場太快，無狀態結果的反饋，操作生硬；還有原型設計畫板、元素和屬性面板參數的聯動很差；第三點是項目原型設計中的關于元素相關的設計點，包括圖片的圖層歸屬問題，距離的測量等。

總的來說摹客RP是一款比較專業且實用性很強的的設計協作軟件，他基本兼容了原型設計軟件“Axure”的大部分功能，也適合團隊協作中進行使用和推廣，但隨著市面上的競品越來越多，后續的競爭推廣也會越演越烈，所以個人認為產品應該做好以下兩點，會增加自己產品的優勢；首先工具可以輕量化，注重常用功能的用戶體驗和產品的性能優化。

其次作為一款設計協作軟件，面向的是廣大設計師，產品細節方面的問題特別容易被設計師捕捉。所以需要著重把控這兩點，進行積極的推廣助力，才好抓住設計的心！這里也祝摹客系產品能越做越好！

本文為2022摹客RP原型工具測評大賽的測評文章，如對摹客RP感興趣可點擊體驗鏈接：https://www.mockplus.cn/rp-event/?hmsr=woshipmqianwei

本文由 @Q什伍 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。

輯導語：對于團隊產品知識庫產品，想必大家都不陌生，但是很少有人能夠系統地去管理自己的知識。因此，作者思考了關于團隊知識管理的四個問題，并對市場上的知識庫產品進行了比對，與大家分享，希望對大家有所幫助。

知識管理相信大家并不陌生，但我在身邊簡單調研一圈之后發現，大部分人沒有系統的去管理自己的知識。在工作之余的閱讀過程中，我接觸到盧曼的卡片筆記法，接觸到obsidian、Notion，并且嘗試構建自己的知識外腦。

個人知識管理我們后面可以單獨有一篇文章詳細闡述。今天想聊一下團隊知識管理，在經歷了很多次找歷史資料找不到的痛苦之后，我決心要打造一個團隊共有的知識庫系統。一方面提升團隊效率，一方面避免重復工作。

為此，我主要思考了四個問題，并且比對了市場上知識庫產品，和大家分享一下，供大家參考。

一、團隊知識管理是什么樣的市場？

團隊知識管理這一概念很少單獨拎出來說，目前團隊知識管理經常和文檔管理產品、協同辦公產品耦合在一起。由于很難找到純粹知識管理的行業報告，我們可以看一下市場上的文檔管理賽道的玩家。

文檔管理產品圖譜，圖源：甲子光年

這份甲子的報告里并不完全全面。除了上面列舉的部分文檔管理產品可以劃在知識管理產品范圍內，還有包括一些新晉的知名玩家，比如釘釘文檔的團隊空間、飛書文檔的知識庫、海外的知名產品Notion、Confluence等。

知識庫產品百度指數

我們可以看一下百度指數，知識庫這個概念非常少有人索引，而在知識庫產品里，石墨文檔相對熱度最高。

我們可以粗略的統計一下知識管理的市場。根據艾瑞咨詢的研究報告，2020年國內協同辦公市場是440億元，一直以來爆火的短視頻去年國內市場規模是1300億左右，這樣對比大家可以感受一下協同辦公的市場具體有多大。

而協同辦公產品包含：文檔協同、企業網盤、項目協同、會議系統、OA協同平臺等等。知識管理只是協同辦公的非常小一部分的市場。這樣我們能進一步感受到知識管理的市場規模其實真的不大。

二、為什么大部分用戶意識到知識管理重要，但管理知識很困難

客戶通常都知道知識管理很重要，但只有在他們遇到：明知道某個歷史檔案能解決他們眼前問題，但就是找不到這個資料的時候。他們才會對整理團隊知識有更感性的認識，或者說更痛的領悟。

我看下來管理知識困難主要有幾點原因：

首先，知識的創造困難。

創造知識的過程是反人性的，這是不能看到即時反饋的一件事。大部分團隊成員不愛寫總結文檔，工作也許可以干的很漂亮，但留下的東西非常的少。因為從工作的角度，項目交付完了，客戶或者用戶滿意了，在團隊成員心里就算了事了，文檔整理工作在他們心里屬于分外之事。

其次，知識的維護困難。

維護團隊資料的過程是對抗熵增的過程。熵增指的是：在一個封閉空間內，事物會走向混亂和無序，并且不可逆。就比如一個倉庫如果沒有人管理，一定會越來越亂。

團隊知識庫也是一樣。傳統的文檔管理流于表面，企業也許會有自己的資料庫，但很可能“XX項目文檔”文件夾下完全就是空的。按項目管理知識里的說法，就是沒有維護好組織過程資產。

知乎上經典好文里經常出現這樣一句評論：躺在我的收藏夾里吃灰去吧。大家看到好東西，第一反應會把他們收集起來，但維護和利用就非常少了。

最后，知識的快速查找和調用困難。

當知識庫內容不全，陳舊無效，搜索的結果不精準，無法導出轉發，這些都會極大打擊我們使用知識庫的熱情。我們發現知識庫存在但無法提升我們的工作效率時，這個知識庫基本就算失敗了。

三、理想的知識庫產品需要哪些能力

市場上的知識庫產品，能不能幫助團隊管理好知識呢？

我選擇幾種知識庫產品，從6個功能維度去對比市場上的知識庫產品。我認為好的知識庫產品這六方面都需要相對出色：工具、模板、協同、安全、搜索、導出。

• 工具、模板兩個方面解決知識的創造困難；
• 協同、安全兩個方面解決知識的維護苦難；
• 搜索、導出兩個方面解決知識的應用困難。

1. 工具篇

我們前面說了，創造知識困難。作為團隊知識庫，首先要解決的是內容的輸入。內容的來源有兩種：即時創造和外部遷移。

即時創造面向的是新知識。主要考量的是知識庫產品編輯器能力。如果能讓用戶更簡單便捷的編輯文字，編輯器工具屬性能讓用戶感覺到爽的話，無疑是會提升用戶的創造意愿的。

外部遷移指的是陳舊知識或者歷史資料。主要是能支持歷史數據的遷移進入知識庫。

我們先看各家即時創造的能力，也就是產品編輯器能力。

（1）頁面布局

釘釘的編輯器和傳統的word編輯器布局類似，功能區出現在編輯器上方，由于大部分人都長期使用微軟的Word，這種布局符合用戶習慣。

圖中綠色部分可以看到釘釘的文檔支持部分的塊狀編輯。塊狀編輯最大的好處是結構的靈活，便于用戶調整文檔前后文結構。

釘釘可能是為了滿足不同用戶編輯體驗，在功能欄右側設計了縮進按鈕，縮進之后保留核心功能在功能欄，這樣可以營造更簡潔的頁面。

釘釘文檔

如果說簡潔畫風，石墨文檔可以單獨拿出來。石墨的整體頁面簡約直接，按鈕加了陰影，整體是灰色系的性冷淡風。支持創建傳統文檔和文檔。石墨文檔頁面看下來讓人覺得舒適，中間的功能欄沒有影響到整體的整潔簡約的體驗。

石墨文檔

而飛書、Notion、Confluence的布局就脫離了微軟系的畫風。特別是作為口碑非常好的Notion，幾乎是一個全新的編輯界面。Notion是非常明顯的塊狀編輯，所有的板塊依托塊狀組件化呈現，同時頁面風格靈動，和目前大部分文檔產品截然不同。

Notion

飛書和Notion一樣完全支持塊狀編輯，而Confluence并未使用塊狀編輯。頁面布局的創新可以給用戶帶來新鮮感，但對于習慣了微軟Word的用戶來說，也許會反而有一些阻礙。

百度俞軍說過，產品價值=（新體驗 – 舊體驗） – 替換成本。編輯器頁面作為最直觀的窗口，這部分的顛覆一定會帶來較高的替換成本。

Confluence

飛書輸入方式石墨文檔和釘釘將整個功能區列在主屏上方，無疑是能讓用戶所見即所得的處理文檔。

我們一系列常用的標題、對齊、插入、字體選擇等功能可以一鍵觸達，同時也支持Markdown編輯輸入。他們的做法是，同時支持傳統文檔和新式文檔。傳統文檔的輸入和微軟Word的輸入方式保持一致，新式文檔的輸入則是塊狀編輯加上支持Markdown輸入。

而對于Notion、Confluence、飛書這幾款產品，編輯頁面會做更簡潔，但非常依賴Markdown編輯，這就需要用戶去熟悉Markdown的編輯語法。

對于程序員群體來說，相信這是一個他們非常熱愛的輸入方式，但是對于大部分用戶來說，相信這還是一個相對新的概念。

Markdown輸入最大的好處就在于，你在碼字編輯文檔的時候，不需要移開右手去點擊鼠標。毫無疑問這可以提升輸入效率，但是提高了準入門檻。

插入功能插入這個功能，同樣是每個產品都引入的。我們可以非常直觀的對比各家的優劣。

通常我們在word編輯器里常用的是插入圖片、表格。新一代的知識管理產品在插入功能上做的都很好，比如釘釘除了支持常規的圖片、表格，還支持腦圖、原型圖、代碼塊等等。

（2）外部文件導入

在知識庫管理的過程中，我們一定會存在一些老文檔需要入庫。

Notion目前支持12種類型文件，其中包括競爭對手印象筆記和Confluence。

石墨文檔和飛書支持本地文件夾上傳，簡單粗暴，看起來很好用，但本質是起到網盤的作用，并不利于用戶管理。

而釘釘目前僅支持word和excel的導入，以及文件夾打包上傳，Confluence只支持word和google文檔。對于工具部分，我們用一個表格總結一下。

單從產品編輯的能力上看，目前釘釘的文檔編輯能力頁面最接近office用戶的使用習慣，基本能滿足圖片、原型圖、設計稿、腦圖、表格等常用功能的插入，同時也兼顧Markdown的編輯方式。

但從外部導入文件的能力依然需要繼續提升，目前支持Word和Excel文件導入，以及支持文件夾打包上傳。

飛書走的路線是依賴Markdown編輯方式，這對于從Office用戶引流可能會有一些困難，并且對外部導入文件的能力也需要提升，飛書支持的是文件和文件夾上傳，這種方式非常便捷。

但從知識管理的角度看只完成了其中的收集功能，知識管理除了收集應該還有科學命名，文件篩選入庫等等功能需要設計。

石墨文檔和Confluence的編輯體驗和閱讀體驗很好，基礎的編輯功能很完善，但在功能創新方面還略顯不足，同時在文件導入方面都需要進行提升。

Notion在產品編輯能力這一項上綜合看相對完善，無論是編輯能力還是遷移導入的能力都很優秀，對于習慣使用塊狀編輯和Markdown輸入的用戶，Notion可以說領先其他產品半個身位。

2. 模板篇

為了幫助用戶更好的創造知識，除了有滿足用戶體驗的設計器產品，我期待的是還需要有加速用戶創作的文檔模板，并且模板質量要高。目前模板功能也是各家都有的，我們對比來看。

飛書和釘釘的產品模板分為兩部分：知識庫模板和文檔模板。

釘釘模板

兩個產品支持創建不同屬性的團隊空間或者知識庫，并且團隊空間里為用戶整理好了對應模板，除此之外，二者支持新建文檔時候以模板的形式創建。

值得一提的是，飛書的模板能支持類似Airtable的多維表格，這和他的塊狀編輯能力密不可分，這樣一來飛書模板的靈活性會更大。石墨文檔、Notion和Confluence只支持文檔模板創建。

Confluence模板

Notion模板

在模板這一層面，各家產品看下來基本都能滿足用戶需求。

飛書和釘釘的知識庫空間模板的預整理能讓用戶更好的上手。而Notion和Confluence在模板的處理上會有更多的靈活度。特別是Notion對Airtable的集成，能讓用戶在一個文檔上玩出很多花樣。

3. 協同篇

到了協同層面，我們考慮的是團隊成員如何更好的維護知識庫，這一點上協同辦公平臺具有天然優勢。

協同主要分為兩步：

第一步是組建知識庫團隊。

在第一步，釘釘和飛書就憑借辦公產品的屬性跑在前面，這兩者可以直接打通內部團隊通訊錄，簡單便捷的把知識庫團隊成員組建好。而Notion、Confluence、石墨則是需要通過郵件邀請其他人加入團隊。

第二步是知識庫團隊共同維護知識庫。

比如，知識庫內容的刪改都被記錄，支持評論互動等。這樣能更好的讓大家參與到知識庫的建設中。

釘釘支持知識庫內@團隊成員，支持段落和劃線評論，同時能夠把釘釘內部群聊鏈接導入到知識庫文檔里。這在一部分飛書和釘釘二者的功能類似。

關于這部分功能，目前二者都只是加了群鏈接的跳轉。而我相信更有沉淀價值的可能是群聊里的某段聊天記錄。目前二者在這處理的都有點粗糙。

釘釘額外考慮到的是，在團隊空間里能夠插入項目進度，這可以及時和項目保持協同聯動。而飛書在協同的部分，考慮的是支持插入日程和投票。

Notion、Confluence、石墨文檔三者承載的OA功能比較少，基本只能在知識庫空間范圍內和隊友互動。

但是不代表這些產品沒有考慮協同的問題，Notion和Confluence能夠進入Slack生態，Slack是目前和微軟Teams競爭的辦公產品，在全球有非常不錯的用戶基礎。Notion和Confluence能夠依托Slack彌補協同的短板。

石墨文檔同樣集成在釘釘生態，能夠從釘釘生態直接訪問，也也加強了石墨文檔的協同能力。

但總體來說飛書和釘釘，依托用戶數和OA系統，形成相對完善的產品矩陣，能夠更大價值的發揮協同作用。而Notion、石墨文檔、Confluence在知識庫的特性上更純粹，協同能力會稍弱一些。

4. 安全篇

對于文檔安全方面，我考慮的是知識庫內容的創建、查閱、轉發需要有權限系統進行約束。一方面能保證團隊信息安全，一方面能更好的保證知識庫內容的質量。

Notion和Confluence的安全模塊作為付費內容沒有辦法體驗，可以看到產品設計也是考慮了文檔安全因素的。而石墨文檔在知識安全上考慮并不是很完全，僅支持空間權限設置，這也是石墨文檔需要提升的。

釘釘和飛書同為協同辦公產品，在安全能力上是優于純知識庫產品的。目前飛書限制導出、打印、創建副本和復制。釘釘支持訪客水印、限制復制、私密文檔、權限繼承等。二者都在文檔安全上有自己的思考。

關于安全這部分，Notion、Confluence和石墨文檔都需要再深入思考一下。

5. 搜索篇

對搜索部分的期待主要就是搜的準，支持自定義的搜索。毫無疑問搜索能夠幫助用戶更好的使用知識庫。

這里我們就要說一下為什么不要用PC本地做知識管理，因為文檔內部的內容是完全無法檢索到的，這樣的檢索能力相對就弱很多了。而目前知識庫產品大部分是可以同時檢索標題和內容的。

飛書搜索

釘釘搜索

石墨文檔搜索

Notion搜索

Confluence搜索

可以看到知識庫產品對于空間內文檔搜索能力不錯。而且搜索精度也能滿足使用需求。

在搜索的篩選規則上，石墨文檔、飛書、Noiton、Confluence都支持更為細節的篩選，比如根據創建時間、文檔類型、修改時間等進行搜索。

目前釘釘團隊空間的搜索準確度很高，篩選規則的功能設計偏少。而讓人感覺不一樣的地方是，針對文檔索引，釘釘采用了其他產品沒有的首頁輔助腦圖架構的方式管理文檔，以便用戶更快索引和知識記憶。

在新建知識庫的過程中，知識庫會自動生成知識庫首頁，知識庫文件的標題名會自動生成思維導圖出現在首頁里。同時給腦圖加了跳轉鏈接，這個設計很獨特。

釘釘團隊空間首頁

6. 導出篇

最后一個環節，導出。知識庫的文檔經常會碰到需要導出轉發的場景，比如導出一份合同去簽署，如果導出的類型受限，導出的格式混亂的話，這肯定是不能接受的。

• 目前Confluence支持整個空間打包導出和單個文檔的分享；
• Notion支持Markdown&CSV、PDF、HTML三種格式的導出；
• 釘釘支持Word、PDF、長圖等文件格式導出；
• 飛書僅支持PDF和Word格式文件導出；
• 石墨文檔支持Word、Markdown、PDF、JPG的格式導出。

從導出這一功能看，能夠導出PDF和Word這兩類常見文件，產品基本就合格了。目前知識庫產品都能基本滿足需求。

7. 小結篇

我們在各家產品綜合能力上做一個總結。

釘釘的團隊空間產品形態兼顧創新和兼容，更符合微軟Office用戶的編輯習慣，這樣帶來的好處是能夠更平滑的將用戶從微軟Office引流。

其次，釘釘的辦公工具屬性可以與知識管理更好地融合，以文檔為核心天然形成知識庫，釘釘的團隊空間能減小協同的障礙，日常聊天記錄里的工作文檔，可以快速的轉入團隊空間進行管理。

并且釘釘團隊空間對知識庫內知識安全考慮的更為細致，能夠讓人放心的保證團隊知識的私密性。作為目前在線組織數最多的辦公產品，可以感受得到釘釘在協同辦公上的深厚積累，對知識庫建設來說是強大助力，對于其他產品來說也是不小的壓力。

Notion是可玩性非常高的產品，all-in-one的理念也圈粉不少用戶。Notion的塊狀編輯和豐富的插入組件儼然是很多同類產品模仿的對象，可拖拽的塊狀編輯讓頁面非常的靈動，支持Airtable式的表格插入更是為產品拓展了表格能力。

但是用好Notion是需要一定極客精神的，Notion更像是少數派的效率工具，而不是普適的文檔管理工具。純粹地把Notion當成Word用會讓人覺得非常浪費這個產品。

而Notion非常依賴Slack補充他的協同能力，這就需要Notion和Slack同時非常優秀，才有更大的競爭力。

目前Notion只支持英文和韓文，網上有一些非官方漢化方式，在一些語言細節處理上還有一些問題。Notion如果完全漢化，并且做好教程，綁定協同辦公平臺的話，對本土的文檔、知識庫產品一定會帶來較大沖擊。

飛書的知識庫在編輯上依賴Markdown編輯，并且有一些塊狀設計和Notion是趨同的，可以看到產品設計的過程是想要改變用戶輸入習慣的。

出身于辦公系統的飛書知識庫，在安全性上做了一定的考慮，而在知識庫搜索功能上，飛書看起來考慮的也很深入。對于釘釘和飛書這兩個協同辦公產品來說，自成生態的建設知識庫一定是最簡單高效的。

Confluence可以說是純知識庫產品的代表，編輯頁面簡潔，功能相對豐富。知識庫生態組件完善。

然而，和Notion一樣，全英文模板絕對會把一大部分人擋在門外。然后網頁打開時間較長，這也是一個不利因素。

石墨文檔的頁面風格是讓人蠻喜歡的，當然這個相對主觀，也不保證會不會時間長看了覺得略微單調。

從產品實用性來說，石墨文檔一直穩扎穩打有著比較好的應用基礎。對于視頻、地圖的直接集成可以極大的提升閱讀體驗，讓人驚喜的一鍵回溯功能可以做好版本管理，不得不說石墨文檔在產品細節上是花了心思的，百度指數相對最高也說明了石墨文檔產品口碑。但插入的組件類型不足，會讓人稍感缺憾。

四、怎么利用好團隊知識庫產品？

創建團隊空間，管理團隊知識庫在我眼里是很重要的一件事，也是一件難而正確的事。我們要怎么才能在內部用好知識庫產品。

1. 選擇最適合自己團隊的產品

我們在前面介紹了各家產品能力，如果團隊成員都很Geek，對新鮮事物有探索的好奇心，可以考慮使用Notion。

如果團隊成員更穩健一些，并且已經在公司內部使用了釘釘、飛書這類產品，毫無疑問，用釘釘的團隊空間和飛書的知識庫更合適。

如果對知識管理和協同辦公的交集很小的話，石墨文檔和confluence作為非常專業的知識庫產品也是很好的選擇。

Notion和Confluence是海外的產品，使用這二者的話需要考慮語言差異的問題。

同時，在選擇的時候也需要考慮產品費用，目前notion、石墨文檔、Cofluence對于一定人數規模的團隊是會收費的。而釘釘和飛書的使用成本更低一些。

2. 激勵團隊創造維護團隊知識庫

我們都知道，讓員工在工作之余進行文檔總結，創造整理是一件非常反人性的事情，是對抗熵增這一自然規律的事情。那么打破熵增的辦法是什么？那就是打破封閉空間。引入外部激勵。

我們可以建立一套機制，鼓勵團隊成員維護知識庫。比如建立一套積分機制，新建一篇文章獲取一定積分，為其他人文章評論、點贊、舉報獲取一定積分，文章閱讀量、點贊量達到一定數值獲取一定積分。最后用積分作為考核標準，獲得額外的獎勵。這個獎勵最好不要和工資掛鉤，很容易被噴卷。

這里只是一個建議，所有的機制都應該是為了讓團隊成員注重知識管理，培養知識管理的習慣。

五、最后

團隊管理在團隊初期是一件附加值很低的事情，很多團隊選擇不關心。這就很像團隊文化一樣，一家企業在創業初期都是野蠻生長，基本沒人會關心企業文化，也不會關心團隊知識沉淀。而當公司快速發展具備一定規模時，還能凝聚大家在一起往前走的，一定是企業文化。

我們會說阿里人、華為人、騰訊人，這個標簽貼完，你會自然對這個群體有一種固化的認知，這就是梁寧說的集體人格，背后本質是企業文化的引導。同樣，團隊發展到一定規模，沒有誰會繼續無視團隊知識管理。

而無論協同辦公產品釘釘、飛書，還是面向未來的工具Notion，亦或是專業的知識庫Confluence。在知識管理上只能做到“術”的幫助，而真正管理好知識更需要“道”和“法”的引導和規范。

希望這邊文章對你有幫助，下一次我們再聊一下個人知識管理，也聊一聊知識管理的“道”和“法”。

#專欄作家#

忙里偷賢，公眾號：忙里偷賢，人人都是產品經理專欄作家。B端產品，低代碼玩家，工具類產品思考者。熱愛分享，務實的理想主義者。

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

題圖來自 Pexels，基于CC0協議

推薦: foo_bar(self, width, height, color='black', design=None, x='foo',
 emphasis=None, highlight=0)
 if (width==0 and height==0 and
 color=='red' and emphasis=='strong'):

x=('這是一個非常長非常長非常長非常長 '
 '非常長非常長非常長非常長非常長非常長的字符串')

Yes: # See details at
 # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
No: # See details at
 # http://www.example.com/us/developer/documentation/api/content/\
 # v2.0/csv_file_name_extension_full_specification.html

Yes: if foo:
 bar()
 while x:
 x=bar()
 if x and y:
 bar()
 if not x:
 bar()
 return foo
 for (x, y) in dict.items(): ...
No: if (x):
 bar()
 if not(x):
 bar()
 return (foo)

Yes: # 與起始變量對齊
 foo=long_function_name(var_one, var_two,
 var_three, var_four)
 # 字典中與起始值對齊
 foo={
 long_dictionary_key: value1 +
 value2,
 ...
 }
 # 4 個空格縮進，第一行不需要
 foo=long_function_name(
 var_one, var_two, var_three,
 var_four)
 # 字典中 4 個空格縮進
 foo={
 long_dictionary_key:
 long_dictionary_value,
 ...
 }
No: # 第一行有空格是禁止的
 foo=long_function_name(var_one, var_two,
 var_three, var_four)
 # 2 個空格是禁止的
 foo=long_function_name(
 var_one, var_two, var_three,
 var_four)
 # 字典中沒有處理縮進
 foo={
 long_dictionary_key:
 long_dictionary_value,
 ...
 }

Yes: spam(ham[1], {eggs: 2}, [])
No: spam( ham[ 1 ], { eggs: 2 }, [ ] )

Yes: if x==4:
 print x, y
 x, y=y, x
No: if x==4 :
 print x , y
 x , y=y , x

Yes: spam(1)
no: spam (1)
Yes: dict['key']=list[index]
No: dict ['key']=list [index]

Yes: x==1
No: x<1

Yes: def complex(real, imag=0.0): return magic(r=real, i=imag)
No: def complex(real, imag=0.0): return magic(r=real, i=imag)

Yes:
 foo=1000 # 注釋
 long_name=2 # 注釋不需要對齊
 dictionary={
 "foo": 1,
 "long_name": 2,
 }
No:
 foo=1000 # 注釋
 long_name=2 # 注釋不需要對齊
 dictionary={
 "foo" : 1,
 "long_name": 2,
 }

def fetch_bigtable_rows(big_table, keys, other_silly_variable=None):
 """Fetches rows from a Bigtable.
 Retrieves rows pertaining to the given keys from the Table instance
 represented by big_table. Silly things may happen if
 other_silly_variable is not None.
 Args:
 big_table: An open Bigtable Table instance.
 keys: A sequence of strings representing the key of each table row
 to fetch.
 other_silly_variable: Another optional variable, that has a much
 longer name than the other args, and which does nothing.
 Returns:
 A dict mapping keys to the corresponding table row data
 fetched. Each row is represented as a tuple of strings. For
 example:
 {'Serak': ('Rigel VII', 'Preparer'),
 'Zim': ('Irk', 'Invader'),
 'Lrrr': ('Omicron Persei 8', 'Emperor')}
 If a key from the keys argument is missing from the dictionary,
 then that row was not found in the table.
 Raises:
 IOError: An error occurred accessing the bigtable.Table object.
 """
 pass

class SampleClass(object):
 """Summary of class here.
 Longer class information....
 Longer class information....
 Attributes:
 likes_spam: A boolean indicating if we like SPAM or not.
 eggs: An integer count of the eggs we have laid.
 """
 def __init__(self, likes_spam=False):
 """Inits SampleClass with blah."""
 self.likes_spam=likes_spam
 self.eggs=0
 def public_method(self):
 """Performs operation blah."""

# We use a weighted dictionary search to find out where i is in
# the array. We extrapolate position based on the largest num
# in the array and the array size and then do binary search to
# get the exact number.
if i & (i-1)==0: # true iff i is a power of 2

# BAD COMMENT: Now go through the b array and make sure whenever i occurs
# the next element is i+1

Yes: class SampleClass(object):
 pass
 class OuterClass(object):
 class InnerClass(object):
 pass
 class ChildClass(ParentClass):
 """Explicitly inherits from another class already."""
No: class SampleClass:
 pass
 class OuterClass:
 class InnerClass:
 pass

Yes: x=a + b
 x='%s, %s!' % (imperative, expletive)
 x='{}, {}!'.format(imperative, expletive)
 x='name: %s; score: %d' % (name, n)
 x='name: {}; score: {}'.format(name, n)
No: x='%s%s' % (a, b) # use + in this case
 x='{}{}'.format(a, b) # use + in this case
 x=imperative + ', ' + expletive + '!'
 x='name: ' + name + '; score: ' + str(n)

Yes: items=['<table>']
 for last_name, first_name in employee_list:
 items.append('<tr><td>%s, %s</td></tr>' % (last_name, first_name))
 items.append('</table>')
 employee_table=''.join(items)
No: employee_table='<table>'
 for last_name, first_name in employee_list:
 employee_table +='<tr><td>%s, %s</td></tr>' % (last_name, first_name)
 employee_table +='</table>'

Yes:
 Python('Why are you hiding your eyes?')
 Gollum("I'm scared of lint errors.")
 Narrator('"Good!" thought a happy Python reviewer.')
No:
 Python("Why are you hiding your eyes?")
 Gollum('The lint. It burns. It burns us.')
 Gollum("Always the great lint. Watching. Watching.")

Yes:
 print ("This is much nicer.\n"
 "Do it this way.\n")
No:
 print """This is pretty ugly.
 Don't do this.
 """

with open("hello.txt") as hello_file:
 for line in hello_file:
 print line

import contextlib
with contextlib.closing(urllib.urlopen("http://www.python.org/")) as front_page:
 for line in front_page:
 print line

# TODO(kl@gmail.com): Use a "*" here for string repetition.
# TODO(Zeke) Change this to use relations.

Yes: import os
 import sys
No: import os, sys

import foo
from foo import bar
from foo.bar import baz
from foo.bar import Quux
from Foob import ar

Yes:
 if foo: bar(foo)
No:
 if foo: bar(foo)
 else: baz(foo)
 try: bar(foo)
 except ValueError: baz(foo)
 try:
 bar(foo)
 except ValueError: baz(foo)

def main():
 ...
if __name__=='__main__':
 main()