筆者深入細節(jié)從多個角度解析了模塊化設(shè)計的概念，幫助我們認識、搭建模塊化設(shè)計思維。

一、什么是模塊化設(shè)計？

這兩年來，產(chǎn)品模塊化設(shè)計逐漸受到大家的推崇，那么什么是產(chǎn)品模塊化設(shè)計呢？

產(chǎn)品模塊化設(shè)計就是將產(chǎn)品分成幾個部分，每一部分都具有獨立功能，具有一致的幾何連接接口和一致的輸入、輸出接口的單元，相同種類的模塊在產(chǎn)品族中可以重用和互換，相關(guān)模塊的排列組合就可以形成最終的產(chǎn)品。

通過模塊的組合配置，就可以創(chuàng)建不同需求的產(chǎn)品，滿足客戶的定制需求；相似性的重用，可以使整個產(chǎn)品生命周期中的采購、物流、制造和服務(wù)資源簡化。

模塊化或者說接口式開發(fā)，讓產(chǎn)品在功能使用過程中，靈活性更高，下面是我在今年平臺成長體系搭建過程中，進行了任務(wù)體系產(chǎn)品設(shè)計時，運用模塊化設(shè)計思路，將功設(shè)計成模塊接口形式，提高運用效率的過程。

二、僵硬的功能設(shè)計思路

今年年初，我開始著手進行用戶成長體系——任務(wù)體系的功能設(shè)計；

在成長體系的構(gòu)建中，任務(wù)體系是不可缺少的模塊：通過任務(wù)和獎勵的合理刺激，用戶以物質(zhì)，榮譽為目的，在平臺中不斷貢獻自己的活躍，獲得更高級的物質(zhì)和榮譽，循環(huán)遞進，就像《上癮》中說到的上癮模型：

上癮模型

任務(wù)體系就是上癮模型中的行動創(chuàng)造者，不同的任務(wù)搭配不同層級的獎勵，形成多變的酬賞，讓用戶更容易投入到平臺中。

在一開始接觸這項工作時，我的設(shè)計思路是：梳理出平臺所有的任務(wù)，將對應(yīng)的獎勵也羅列出來，每一項任務(wù)綁定一個獎勵，生成后即永久固定，這樣的設(shè)計方法在開發(fā)過程中一步到位，所有的任務(wù)和獎勵設(shè)計好后，不會再有變化，如下圖所示：

但仔細想想就會發(fā)現(xiàn)，這樣的設(shè)計存在著一個巨大的缺陷：成本計算，運營效果預估，運營方案等等的準備工作都需要進行先期預估，才能進行開發(fā)；

針對不同運營時段，或者不同用戶群體，同一個任務(wù)可能會有不同的獎勵，一旦運營有新的任務(wù)或新的獎勵時，就需要通過研發(fā)重新進行任務(wù)埋點和獎勵開發(fā)；

結(jié)合上面的條件，可以想見，后臺的功能設(shè)計和開發(fā)上將會非常僵硬，無論是使用還是后續(xù)延展，都會有很大的難度，這樣的產(chǎn)品開發(fā)方式，也與敏捷開發(fā)模式背道而馳，若在前期沒有做到完整的梳理和運營規(guī)劃，將會對后續(xù)的產(chǎn)品運營產(chǎn)生極大的困難。

三、模塊化設(shè)計思維的轉(zhuǎn)變

在了解到模塊化設(shè)計方法后，我對任務(wù)體系的設(shè)計有了一個新的想法：將任務(wù)和獎勵進行分離。

任務(wù)模塊進行功能拆解，將用戶屬性，時間維度，行為等變成可編輯式， 生成后隨時調(diào)控，靈活運營。

獎勵模塊作為工具化產(chǎn)品開發(fā)，以接口形式對外進行組合搭配，不僅僅適用于任務(wù)，還可以對接至活動，從而實現(xiàn)一個模塊多處使用，真正實現(xiàn)隨時調(diào)用，隨時上線。

模塊化設(shè)計思路

此時，產(chǎn)品開發(fā)前期需要梳理的內(nèi)容就只剩下平臺行為，其他的工作，例如運營方案、運營效果的預估均可以在開發(fā)過程中同步完成，而不必占用項目的開發(fā)時間。

四、數(shù)據(jù)效果

在這樣的設(shè)計思路下，每一次的運營活動只需要進行活動邏輯設(shè)計，不再需要重復進行獎品模塊和任務(wù)模塊的開發(fā)。

同時運用模塊化的思路，每一次的活動都做成模版工具，和任務(wù)模塊，獎勵模塊做好功能接口對接，直接調(diào)用，在后續(xù)的運營過程中，活動的復用性也得到了保證。

經(jīng)過這套模塊化工具設(shè)計方法，活動運營的前置開發(fā)時長減少了85%，運營人員只需要準備好活動方案，就可以在后臺進行活動的設(shè)置，獎品的設(shè)置以及任務(wù)關(guān)聯(lián)。

五、模塊化設(shè)計思維的好處

也許你會說上面的經(jīng)歷僅僅是某次需求設(shè)計時的思路變化，但當真正掌握模塊化設(shè)計思維方式，并應(yīng)用在其他方面時，你就會發(fā)現(xiàn)模塊化設(shè)計思維的強大。

1. 輸出的統(tǒng)一性

舉個例子，當有兩個設(shè)計師負責同個項目，列表模塊在多個頁面都會出現(xiàn)，這時兩個設(shè)計師就會設(shè)計出兩個不同樣式的列表在APP中出現(xiàn)，這樣子是極其不合理的。

這個時候，采用模塊化設(shè)計思維，針對復用性高的模塊形成設(shè)計規(guī)范，保證最終成品輸出的統(tǒng)一性，就像微信小程序的設(shè)計規(guī)范一般：

統(tǒng)一的頁面體驗和有延續(xù)性的界面元素都將幫助用最少的學習成本達成使用目標，減輕頁面跳動所造成的不適感。

2. 便于維護

每當系統(tǒng)出現(xiàn)bug的時候，查找問題總會是一個大難題，錯綜復雜的接口代碼關(guān)系總會讓錯誤查找也變成一個難題，如上文的例子如采用第一種設(shè)計思路，功能設(shè)計的高耦合度會讓任務(wù)體系出現(xiàn)問題時，問題查找極其麻煩，無法定位問題究竟是在任務(wù)模塊出現(xiàn)的還是在獎勵模塊出現(xiàn)的，只能全部代碼所有流程跑一次。

而當你采用模塊化設(shè)計時，bug的初始就能很快定位是哪個模塊出現(xiàn)了問題，你只需要在對應(yīng)模塊查找問題，將模塊內(nèi)的問題解決就可以了；

3. 提高效率

以最近遇到的web端頭部UI修改舉例，前端人員根據(jù)設(shè)計師重新設(shè)計好的頁面頭部進行修改時發(fā)現(xiàn)，web端的部分頁面采用的是同一套js代碼，修改后即可直接替換，而部分頁面卻是獨立設(shè)計，無法進行復用，如果要進行頭部修改，只能一個頁面一個頁面的修改，修改工作繁重。

如果在網(wǎng)站建立的初期，我們就采用模塊化設(shè)計思路，復用性高的模塊抽取出來共用，將來需要修改時，也只需要修改對應(yīng)模塊，而不需要每個使用到的頁面都進行修改。

4. 低耦合高內(nèi)聚的程序思維

在產(chǎn)品功能設(shè)計的過程中，我們現(xiàn)在經(jīng)常采用的是敏捷開發(fā)，快速迭代的方式。

在這個過程中，若設(shè)計思路不明確，就會在功能設(shè)計中出現(xiàn)功能之間交互復雜，聯(lián)系過于緊密，開發(fā)的時候也會因為功能設(shè)計的缺陷，而造成功能模塊之間耦合性加強，即使是敏捷開發(fā)，在迭代過程中也要不斷地為前面的功能進行修補，對后續(xù)的功能迭代和拓展造成影響。

當采用模塊化設(shè)計思維時，我們其實就進入了程序開發(fā)中經(jīng)常講到的低耦合高內(nèi)聚設(shè)計思維

降低模塊間的耦合度能減少模塊間的影響，防止對某一模塊修改所引起的“牽一發(fā)動全身”的水波效應(yīng)，保證系統(tǒng)設(shè)計順利進行，使得模塊的可重用性、移植性大大增強。

六、總結(jié)

從上文可以看出，采用模塊化設(shè)計就像搭建積木一樣，統(tǒng)一的接口輸出規(guī)范，高效的維護成本，以及與高效程序思維一致的產(chǎn)品設(shè)計思路，帶來的是高效率，高復用性的產(chǎn)品設(shè)計。

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

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