想打磨出一款“有用、可用、易用、好用”的產(chǎn)品，請先做好框架設(shè)計(jì)。本文作者將結(jié)合自己的工作經(jīng)驗(yàn)，分享了幾個易被大家忽略的點(diǎn)。enjoy~

不管是B端還是C端產(chǎn)品，框架設(shè)計(jì)的重要性不言而喻，就像一篇文章的大綱結(jié)構(gòu)，可以引導(dǎo)讀者快速理解文章脈絡(luò)和作者的思路。在它之下，是作者的知識結(jié)構(gòu)，寫作技巧，乃至他的經(jīng)歷 。一款產(chǎn)品也如此，受企業(yè)老板、用戶、市場、技術(shù)等方面的束縛和影響。想打磨出一款“有用、可用、易用、好用”的產(chǎn)品，請先做好框架設(shè)計(jì)。我只是從自己工作的角度總結(jié)了一些大家容易忽略的點(diǎn)，換了一種更遠(yuǎn)的角度，從源頭開始理解產(chǎn)品，可以減少一些團(tuán)隊(duì)后續(xù)的改動工作量。

一、明確產(chǎn)品的使用者

產(chǎn)品的使用者無非就兩類人，一類就大街上的普羅大眾，也就是大家常說的C端用戶，他們手里的產(chǎn)品，一般只能看到前臺頁面，后臺設(shè)置完全由公司運(yùn)營團(tuán)隊(duì)負(fù)責(zé)。這類產(chǎn)品對用戶體驗(yàn)比較看著，畢竟同類產(chǎn)品多，只要你讓我不爽，我分分鐘卸載。還有一類是企業(yè)用戶，這類用戶可能又含兩種角色，一種是為工作，使用產(chǎn)品的目的是提升工作效率，比如企業(yè)HR，使用人事系統(tǒng)來管理員工事務(wù)。這類用戶一般不是最終的購買決策者，但他們的意見往往起到主導(dǎo)作用。另一種角色我稱為“B端的C端用戶”，比如企業(yè)的普通員工，使用公司的人事系統(tǒng)發(fā)起申請，管理一些自己的日常事務(wù)。這類用戶面對難用的產(chǎn)品往往只能默默忍受，邊使用邊吐槽。但是他們的吐槽涉及到“企業(yè)員工滿意度”，會影響到公司管理層的考核。所以設(shè)計(jì)者請不要忽視了這類用戶的存在。

因?yàn)?B產(chǎn)品存在太多的角色，而滿足角色之間的相互協(xié)作和不同需求（有可能存在沖突的需求），是最基本的。同時還要考慮同一個用戶分屬不同角色的情況，設(shè)計(jì)產(chǎn)品的的入口時，是使用不同的賬號登錄兩套系統(tǒng)，還是同一個賬號登錄后的頁面切換。前者需要使用者創(chuàng)建多個賬號，無形中增加了用戶的記憶負(fù)荷。相反后者用戶只需記住一個賬號，利用角色權(quán)限分配，在系統(tǒng)做處理，如何讓他在系統(tǒng)中不迷茫（比如清晰的菜單分類，明確的任務(wù)提示等），但這對于本身就業(yè)務(wù)復(fù)雜的產(chǎn)品，更將考設(shè)計(jì)師的水平了。所以，一套科學(xué)完善的用戶權(quán)限機(jī)制至關(guān)重要。

二、確定產(chǎn)品的基礎(chǔ)框架和底層架構(gòu)

B端產(chǎn)品除了要考慮系統(tǒng)內(nèi)角色之外，針對不同企業(yè)的特殊性需求也是設(shè)計(jì)者的一大挑戰(zhàn)。我們作為乙方，如果只根據(jù)甲方的需求進(jìn)行設(shè)計(jì)開發(fā)，無疑是最輕松的方式。但這只適合于傳統(tǒng)的外包公司，對于有追求有理想的企業(yè)，必然有自己產(chǎn)品?，F(xiàn)在都標(biāo)榜自己是“新興的SaaS企業(yè)”，我們只賣服務(wù)。既然如此，那么軟件基礎(chǔ)框架就成了產(chǎn)品的靈魂。

哪些需求是作為產(chǎn)品的標(biāo)準(zhǔn)功能，哪些需求是單獨(dú)你這家客戶提出來的，作為你的定制化，是需要額外收費(fèi)的。這些在設(shè)計(jì)之初，就應(yīng)該評審清楚。不要急著下結(jié)論，不要糾結(jié)于細(xì)節(jié)，雖然產(chǎn)品人員在前期需求設(shè)計(jì)時，對細(xì)節(jié)把握得越充分，后期溝通成本會減少很多。但在這個階段卻是不適合的，當(dāng)一家客戶提出某個需求后，需要做的是研究清楚該需求是共性還是個性，在這個行業(yè)里的專業(yè)性有多高等等。因?yàn)槿魏我豢町a(chǎn)品都是在需求池中泡大的，這將決定你產(chǎn)品在行業(yè)中的專業(yè)程度和權(quán)威性。

這里說的底層架構(gòu)不是指技術(shù)上的類似于MPC-HC之類的架構(gòu)，而是指產(chǎn)品經(jīng)理需要明確的系統(tǒng)基礎(chǔ)Core。就像一顆樹的根部，無論如何生長，根部都是最重要的。上面提到的B端產(chǎn)品用戶角色的復(fù)雜性，一套健全科學(xué)的權(quán)限邏輯就可以是基礎(chǔ)Core的一部分。基礎(chǔ)框架可以就可以理解成樹干，當(dāng)這兩部分正常生長，剩下的就是開始讓其枝繁葉茂，開花結(jié)果了。只有確定了這些，才能更準(zhǔn)確地進(jìn)行需求管理和確定任務(wù)優(yōu)先級。從交互框架上，也不僅僅只是從信息架構(gòu)層面設(shè)計(jì)，更可以從縱向維度，像穿針引線般將多個功能串聯(lián)起來。

三、考慮產(chǎn)品的靈活性

當(dāng)特性的數(shù)量達(dá)到一定程度時，會轉(zhuǎn)變成共性。但這中間的過程，必然要考慮產(chǎn)品的開放性和靈活度。這會給后續(xù)的產(chǎn)品迭代節(jié)省成本，同時滿足更多的用戶場景。開放性可以體現(xiàn)在API上，一個好的SaaS產(chǎn)品會擁有一套強(qiáng)大的數(shù)據(jù)流轉(zhuǎn)結(jié)構(gòu)。績效考核系統(tǒng)也許部分?jǐn)?shù)據(jù)來源于另一個營銷平臺，部分?jǐn)?shù)據(jù)也許來源于考勤系統(tǒng)等等。很多客戶企業(yè)因?yàn)楦鞣N歷史問題或業(yè)務(wù)原因，會在工作中使用多種軟件互相協(xié)作。關(guān)于這方面，也可以先與技術(shù)人員多進(jìn)行溝通。說到靈活度，需要產(chǎn)品經(jīng)理比較強(qiáng)的預(yù)判能力，簡單而言，需要考慮到該功能當(dāng)前使用場景，未來的用戶場景（之后發(fā)生需求變更的可能性多大），以及由該功能引發(fā)的其他需求變更。

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

四、了解產(chǎn)品的收費(fèi)模式

2B跟2C在商業(yè)性質(zhì)上也有很大的區(qū)別，B端產(chǎn)品以業(yè)務(wù)復(fù)雜著稱，不像C端產(chǎn)品，用錢可以很快燒出一個復(fù)制品，B端產(chǎn)品都是慢慢熬出來的，戰(zhàn)線長，成本高，不是說復(fù)制就能復(fù)制的。排除個例的談情懷外，大家都是為了盈利賺錢的，2C可能先用圈用戶，賺流量，一步步讓你掏腰包。但是2B看起來更注重商業(yè)利益，很直接的交易行為。你付多少銀子，我給你多少功能。有些初創(chuàng)企業(yè)能有客戶就不錯了，所以會出現(xiàn)一口價的情況，但這種模式真的好嗎，服務(wù)既是主觀又是客觀的東西。最后你會發(fā)現(xiàn)，價格要么開高了要么開低了。最好的方式是階梯式、動態(tài)的，依據(jù)應(yīng)該是企業(yè)性質(zhì)、需求特點(diǎn)等。

商業(yè)模式其實(shí)很復(fù)雜龐大，收費(fèi)模式只是其中一個環(huán)節(jié)，但收費(fèi)模式必然會關(guān)系到我們產(chǎn)品的框架結(jié)構(gòu)。若你按license收費(fèi)，當(dāng)企業(yè)需要購買新模塊時，是更新license授權(quán)還是通過在線升級？如果模塊與模塊之間單獨(dú)收費(fèi)，是否考慮了外部數(shù)據(jù)接口，是否可以通過人工批量導(dǎo)入。當(dāng)激活多個模塊時，每個模塊之間數(shù)據(jù)如何流轉(zhuǎn)及交互上的互動關(guān)聯(lián)？模塊內(nèi)部是否可按某種功能組合的數(shù)量來收費(fèi)，如果可以，用什么方式來限制用戶添加多個這種組合？還有客戶化內(nèi)容，哪些功能是可以通過客戶化團(tuán)隊(duì)來做，哪些由產(chǎn)品研發(fā)團(tuán)隊(duì)接手？系統(tǒng)框架結(jié)構(gòu)都會由收費(fèi)模式不同而不同。

以上任何一點(diǎn)往細(xì)了擴(kuò)展，都可以是長篇大論，這里只做簡單的概括，有機(jī)會再聊聊B端產(chǎn)品的其他方面設(shè)計(jì)。

祝好。

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

題圖來自 Pexels，基于 CC0 協(xié)議