編輯導(dǎo)語：如今很多企業(yè)都開始發(fā)展B端業(yè)務(wù)，B端業(yè)務(wù)對于設(shè)計師來說是比較復(fù)雜的，B端軟件產(chǎn)品設(shè)計的理念也在發(fā)生很大的變化，怎么保證B端產(chǎn)品的簡潔性就成了一個問題；本文作者介紹了幾個保持簡潔性的原則建議，我們一起來看一下。

筆者曾經(jīng)將做C端產(chǎn)品比喻過建大平房，B端管理軟件產(chǎn)品類似于建小高樓，占地面積是用戶的量，樓的高度是業(yè)務(wù)的復(fù)雜度；C端產(chǎn)品重定位以及交互能力，B端產(chǎn)品重架構(gòu)以及抽象能力。

實際上將產(chǎn)品比喻為建筑物也是有不合適的地方，建筑物在建造之前一般都有了很精確的設(shè)計圖紙；但是作為軟件產(chǎn)品來說，很多時候是沒有精確的圖紙的，除非已經(jīng)很成熟的賽道，很多場景下面它更像一個相對未知的生物體、生命體；它是不斷在生長的，在產(chǎn)品生長的過程中，產(chǎn)品很容易變得臃腫不堪，最后很難維護以及擴展，用戶也很難使用。

即使SAP、Workday、Salesforce這樣優(yōu)秀的軟件也難逃其命運；不過這些軟件都是21世紀(jì)初或者20世紀(jì)的產(chǎn)物，隨著移動互聯(lián)網(wǎng)的發(fā)展，B端軟件產(chǎn)品設(shè)計的理念正在發(fā)生很大的變化。

那么怎樣保證產(chǎn)品在長期錯綜復(fù)雜的發(fā)展過程中，保持其簡潔性；筆者提供一些小的原則建議：

一、確定產(chǎn)品形態(tài)

努力想清楚產(chǎn)品最終的大致形態(tài)，以及用戶在哪些場景，用什么樣的方式來使用我們的產(chǎn)品，做好取舍。

產(chǎn)品的發(fā)展是基于公司的戰(zhàn)略以及愿景，在想清楚產(chǎn)品的最終形態(tài)之前，需要想清楚公司的戰(zhàn)略以及愿景；基于公司服務(wù)的人群，以及提供的服務(wù)，確定產(chǎn)品的最終形態(tài)。

基于戰(zhàn)略對于哪些功能需要做，哪些不要做有一定的準(zhǔn)則，否則陷入撒都要做的境地。

另外，筆者經(jīng)?？吹揭环N境況，創(chuàng)業(yè)公司有時候產(chǎn)品定位不準(zhǔn)確，切入的是用戶癢點的需求，很多時候產(chǎn)品供應(yīng)商沒有察覺到；反而覺得是功能不夠多，不斷的去迭代更多的癢點功能，實際上癢點＋癢點不等于痛點，再多的癢點功能的疊加也是不可能形成客戶對產(chǎn)品的依賴的。

二、產(chǎn)品線定位

做好每條產(chǎn)品線的定位，避免定位的混亂后，產(chǎn)品走向不明，不同產(chǎn)品線之間重復(fù)交叉在一起。

產(chǎn)品的使用一般有多個角色，使用的場景也不盡相同，很多時候我們都會有面向客戶的移動端、web端，也會有公司內(nèi)部的運營端，每條產(chǎn)品線的定位需要想的非常清楚，避免交叉。

這里我們經(jīng)常看到的誤區(qū)有如下幾個：

不同的角色用不同的產(chǎn)品線來支持。

筆者經(jīng)?？吹揭恍┕?，不同角色因為功能有所區(qū)分，就用不同的產(chǎn)品線、不同的APP來支持；實際上一般來說隨著產(chǎn)品的發(fā)展，不同角色重疊的功能會越來越多；實際上只需要統(tǒng)一成一條產(chǎn)品線，通過權(quán)限來區(qū)分不同角色的使用功能就足夠了。

濫用移動端，什么功能都往移動端來走。

作為移動端，一些經(jīng)常需要在移動端使用的功能，協(xié)同功能以及高頻需要查看的數(shù)據(jù)可以放在移動端；但是移動端不適合做一些輸入工作太重的功能，也不適合做的很重，太重了就不適合“移動”了。

三、主線功能

優(yōu)先做好主線功能，也要保證極端低頻事件有路可走。

對產(chǎn)品發(fā)展的過程當(dāng)中，需求優(yōu)先級的控制極其重要；低頻事件，特別是一些逆主流程的功能實際上的工作量是極大的；比如說流程走的好好的，用戶需要支持逆向的操作，如果這種業(yè)務(wù)流程中有大量的邏輯——這種逆向操作的代價是巨大的。

這里的一個原則就是對于低頻極端事件，不一定要完全線上支持，很多時候可以采用線上＋線下的支持方式，保證客戶在低端情況發(fā)生的時候，系統(tǒng)不至于無路可走就行。

打一個比方，在ERP的上下游結(jié)算，或者薪酬的薪資計算的時候，總是會有一些費用是很難標(biāo)準(zhǔn)化的，或者計算方式是很難抽象的；這種時候可以考慮開一個口子支持這種費用項目，但是這種費用項目的完整管理不要線上化，讓客戶通過線下的計算，然后有入口進行輸入或者調(diào)整就好了。

四、每個迭代把握做小、做少、做精的原則

每個迭代把握做小、做少、做精的原則；做加法很容易，做減法很難。

將一個產(chǎn)品做復(fù)雜很容易，但是復(fù)雜之后，要變簡單非常難，無論是前端，還是后端的數(shù)據(jù)庫以及邏輯層；做加法都是容易的，但是做減法都是極難的。

所以在產(chǎn)品的把控上面，采用線做小、做少、做精的克制原則是非常重要；否則，產(chǎn)品發(fā)展2，3年之后，就復(fù)雜到客戶很難使用，維護成本很高，擴展難度很大的積重難返的地步。

五、合并同類項，減少復(fù)雜度

前面說過筆者有一個看法是產(chǎn)品是不斷在生長的，無論是大的功能，還是小的邏輯分支；這些分支隨著產(chǎn)品的發(fā)展會不斷生長出新的分支，這樣不斷的裂變，會導(dǎo)致產(chǎn)品復(fù)雜度不斷上升；所以需求控制、產(chǎn)品設(shè)計、邏輯實現(xiàn)上面，需要盡量抽象、合并同類項，盡量減少分支是在產(chǎn)品落地層面的最重要的技巧。

所以在設(shè)計以及研發(fā)這個層面，核心工程師的抽象能力也是非常重要的，需要找一些邏輯思維能力強，追求最佳實現(xiàn)路徑的工程師來承擔(dān)一些核心的功能。

六、基于場景來進行設(shè)計，避免過度設(shè)計

過度設(shè)計是經(jīng)常發(fā)生的現(xiàn)象，簡單如一般的搜索，筆者看到大量客戶不會用到的檢索條件羅列放在上面；客戶在用這個功能的時候希望看到哪些信息，可能會怎樣進行檢索，一定要了解客戶使用的場景之后再去做設(shè)計。

當(dāng)然一些通用軟件，因為使用場景很難預(yù)測，將場景進行放大也是可以理解的；只是無論通用場景還是垂直場景，都需要盡量了解場景之后，基于場景做最小化的設(shè)計，過度的設(shè)計實際上會影響用戶體驗，也會增加系統(tǒng)的復(fù)雜度。

七、做好權(quán)限的區(qū)分，盡量讓每個客戶、每個角色只是看到自己需要的功能

每個客戶，每個角色需要的功能集是會有一些不一樣的，保證每個客戶，每個角色只看到自己需要的功能集，對于產(chǎn)品的易用性會有不錯的提升。

八、做好系統(tǒng)，每個模塊，每個功能首頁的設(shè)計

B端產(chǎn)品的功能很多，只是客戶真正高頻關(guān)心的數(shù)據(jù)，真正高頻使用的功能實際上是不多的；系統(tǒng)的首頁，每個功能模塊的首頁，每個功能的首頁就變得非常重要（關(guān)于首頁的設(shè)計，可以參考我原來寫過的一篇文章，“怎樣讓B端產(chǎn)品像C端產(chǎn)品一樣極致易用”）。

需要將用戶真正高頻關(guān)心的數(shù)據(jù)，使用的功能放在首頁上面，這樣保證用戶只使用少數(shù)幾個功能就能看到自己真正關(guān)心的核心數(shù)據(jù)，完成自己日常的工作。

復(fù)雜易，簡潔難；萬物之間，簡潔最美，希望最美。

#專欄作家#

作者：李東林（微信公眾號：SaaS產(chǎn)品說；微信號：jianguzhuxin），菜小秘聯(lián)合創(chuàng)始人，原ADP大中華區(qū)產(chǎn)品負(fù)責(zé)人，14年To B研發(fā)與產(chǎn)品設(shè)計，團隊管理經(jīng)驗，主導(dǎo)過多款大型企業(yè)管理軟件的設(shè)計、研發(fā)、上線，也有過數(shù)年移動互聯(lián)網(wǎng)TO C的創(chuàng)業(yè)經(jīng)驗。

本文由@東林-Tony 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash, 基于CC0協(xié)議。