想打磨出一款“有用、可用、易用、好用”的産品，請先做好框架設計。本文作者将結合自己的工作經驗，分享了幾個易被大家忽略的點。enjoy~

不管是B端還是C端産品，框架設計的重要性不言而喻，就像一篇文章的大綱結構，可以引導讀者快速理解文章脈絡和作者的思路。在它之下，是作者的知識結構，寫作技巧，乃至他的經曆 。一款産品也如此，受企業老闆、用戶、市場、技術等方面的束縛和影響。想打磨出一款“有用、可用、易用、好用”的産品，請先做好框架設計。我隻是從自己工作的角度總結了一些大家容易忽略的點，換了一種更遠的角度，從源頭開始理解産品，可以減少一些團隊後續的改動工作量。

一、明确産品的使用者

産品的使用者無非就兩類人，一類就大街上的普羅大衆，也就是大家常說的C端用戶，他們手裡的産品，一般隻能看到前台頁面，後台設置完全由公司運營團隊負責。這類産品對用戶體驗比較看着，畢竟同類産品多，隻要你讓我不爽，我分分鐘卸載。還有一類是企業用戶，這類用戶可能又含兩種角色，一種是為工作，使用産品的目的是提升工作效率，比如企業HR，使用人事系統來管理員工事務。這類用戶一般不是最終的購買決策者，但他們的意見往往起到主導作用。另一種角色我稱為“B端的C端用戶”，比如企業的普通員工，使用公司的人事系統發起申請，管理一些自己的日常事務。這類用戶面對難用的産品往往隻能默默忍受，邊使用邊吐槽。但是他們的吐槽涉及到“企業員工滿意度”，會影響到公司管理層的考核。所以設計者請不要忽視了這類用戶的存在。

因為2B産品存在太多的角色，而滿足角色之間的相互協作和不同需求（有可能存在沖突的需求），是最基本的。同時還要考慮同一個用戶分屬不同角色的情況，設計産品的的入口時，是使用不同的賬号登錄兩套系統，還是同一個賬号登錄後的頁面切換。前者需要使用者創建多個賬号，無形中增加了用戶的記憶負荷。相反後者用戶隻需記住一個賬号，利用角色權限分配，在系統做處理，如何讓他在系統中不迷茫（比如清晰的菜單分類，明确的任務提示等），但這對于本身就業務複雜的産品，更将考設計師的水平了。所以，一套科學完善的用戶權限機制至關重要。

二、确定産品的基礎框架和底層架構

B端産品除了要考慮系統内角色之外，針對不同企業的特殊性需求也是設計者的一大挑戰。我們作為乙方，如果隻根據甲方的需求進行設計開發，無疑是最輕松的方式。但這隻适合于傳統的外包公司，對于有追求有理想的企業，必然有自己産品。現在都标榜自己是“新興的SaaS企業”，我們隻賣服務。既然如此，那麼軟件基礎框架就成了産品的靈魂。

哪些需求是作為産品的标準功能，哪些需求是單獨你這家客戶提出來的，作為你的定制化，是需要額外收費的。這些在設計之初，就應該評審清楚。不要急着下結論，不要糾結于細節，雖然産品人員在前期需求設計時，對細節把握得越充分，後期溝通成本會減少很多。但在這個階段卻是不适合的，當一家客戶提出某個需求後，需要做的是研究清楚該需求是共性還是個性，在這個行業裡的專業性有多高等等。因為任何一款産品都是在需求池中泡大的，這将決定你産品在行業中的專業程度和權威性。

這裡說的底層架構不是指技術上的類似于MPC-HC之類的架構，而是指産品經理需要明确的系統基礎Core。就像一顆樹的根部，無論如何生長，根部都是最重要的。上面提到的B端産品用戶角色的複雜性，一套健全科學的權限邏輯就可以是基礎Core的一部分。基礎框架可以就可以理解成樹幹，當這兩部分正常生長，剩下的就是開始讓其枝繁葉茂，開花結果了。隻有确定了這些，才能更準确地進行需求管理和确定任務優先級。從交互框架上，也不僅僅隻是從信息架構層面設計，更可以從縱向維度，像穿針引線般将多個功能串聯起來。

三、考慮産品的靈活性

當特性的數量達到一定程度時，會轉變成共性。但這中間的過程，必然要考慮産品的開放性和靈活度。這會給後續的産品疊代節省成本，同時滿足更多的用戶場景。開放性可以體現在API上，一個好的SaaS産品會擁有一套強大的數據流轉結構。績效考核系統也許部分數據來源于另一個營銷平台，部分數據也許來源于考勤系統等等。很多客戶企業因為各種曆史問題或業務原因，會在工作中使用多種軟件互相協作。關于這方面，也可以先與技術人員多進行溝通。說到靈活度，需要産品經理比較強的預判能力，簡單而言，需要考慮到該功能當前使用場景，未來的用戶場景（之後發生需求變更的可能性多大），以及由該功能引發的其他需求變更。

舉個小例子，對于企業員工的福利類别（福利城市、繳納比例等）和稅類别（減免值、計稅方式等）是根據員工的性質不同而不同的，這就需要HR來維護，從而提出需要HR管理福利類别和稅類别的需求，但對于福利的種類（如五險一金）和稅表等，屬于國家政策範疇，就可以不支持用戶親自維護。最好能了解行業裡這種需求發生的頻繁程度，當某個企業提出一個比較奇葩的需求時，你可以例舉其他公司的案例，甚至提出更完美的解決方案。

四、了解産品的收費模式

2B跟2C在商業性質上也有很大的區别，B端産品以業務複雜著稱，不像C端産品，用錢可以很快燒出一個複制品，B端産品都是慢慢熬出來的，戰線長，成本高，不是說複制就能複制的。排除個例的談情懷外，大家都是為了盈利賺錢的，2C可能先用圈用戶，賺流量，一步步讓你掏腰包。但是2B看起來更注重商業利益，很直接的交易行為。你付多少銀子，我給你多少功能。有些初創企業能有客戶就不錯了，所以會出現一口價的情況，但這種模式真的好嗎，服務既是主觀又是客觀的東西。最後你會發現，價格要麼開高了要麼開低了。最好的方式是階梯式、動态的，依據應該是企業性質、需求特點等。

商業模式其實很複雜龐大，收費模式隻是其中一個環節，但收費模式必然會關系到我們産品的框架結構。若你按license收費，當企業需要購買新模塊時，是更新license授權還是通過在線升級？如果模塊與模塊之間單獨收費，是否考慮了外部數據接口，是否可以通過人工批量導入。當激活多個模塊時，每個模塊之間數據如何流轉及交互上的互動關聯？模塊内部是否可按某種功能組合的數量來收費，如果可以，用什麼方式來限制用戶添加多個這種組合？還有客戶化内容，哪些功能是可以通過客戶化團隊來做，哪些由産品研發團隊接手？系統框架結構都會由收費模式不同而不同。

以上任何一點往細了擴展，都可以是長篇大論，這裡隻做簡單的概括，有機會再聊聊B端産品的其他方面設計。

祝好。

本文由 @一念 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部