基於SKU的頁面快速搭建工具設計
在資源有限的前提下，就衍生出了頁面快速搭建的需求。而在這種情況下，我們往往需要一個能快速搭建的工具型產品，那麼這類產品如何設計呢？
自網際網路誕生之初，頁面快速搭建的需求就從來沒有斷絕過，最早的純靜態PC頁面、包含商品/營銷資訊的頁面、移動端自適應的複雜頁面……在網際網路發展的過程中，頁面的展現形式越來越多樣化，承載的資訊也越來越多，幾乎，90%以上的資訊都是以頁面作為載體，通過網際網路的形式，傳播到各個角落。
實際工作中，各種各樣的頁面需求也接踵而來，不論每種需求承載的底層邏輯是複雜還是簡單，都逃不了【需求設計–>互動設計–>視覺設計–>開發–>測試–>上線–>資料提取–>資料分析】這個完整的鏈路。
那麼，在資源有限的前提下，就衍生出了頁面快速搭建的需求，以解決互動設計、開發、測試、資料提取與分析等多個環境的資源消耗。
接下來，開始產品的 設計前準備 。
- 首先 ，我們給這個工具起一個名字，併為他做一個定義：（DIY）+“提供複雜頁面快速搭建能力，易用、穩定、靈活、可分析的工具。”
- 其次 ，為什麼做這件事：為公司節約開發、測試資源及過程中消耗、為產品運營提升效率、節約開發/測試人力成本、服務整合化輸出增加整體競爭力。
可以看到，在體量足夠大的情況下，這件事是有價值的。
接下來，我們來看看模組設計。
我們拿出市面上的各種頁面進行調研，會發現，基本上一個頁面的構成，無外乎以下幾種元素：
- 內容元素： 圖片、商品、視訊、音訊等；
- 佈局元素： 上下滑動、左右滑動、輪播等；
- 導航元素： 錨點、分tab、外鏈、集合頁等；
- 頁面層級元素： 多層級頁面設計。
然後，我們要做模組的抽象，核心是可以通過各種模組的堆疊，完成一個頁面的搭建。有兩種產品設計的方向：第一種，設計純粹抽象的模組；第二種，設計相對具象的模組。
如何理解純粹抽象的模組呢？
即可以任意設定內容的不同樣式，然後根據不同的佈局元素屬性，不同導航元素容器，進行組合。這是純抽象的，擴充套件性非常強，但是學習成本較高。這個留個懸念，大家可以選思考下。
我們用相對具象的模組來進行設計，這種方式，會更加容易理解。
包含的模組為：Banner、IMG、Hot Pot、商品、各類導航、宮格等。
針對模組細節，顆粒度定義，功能設計，就不展開描述了，我們就整體 產品規劃 做一下描述。
從能力上，不同公司的業務場景下，對模組的抽象程度不同，抽象出來的模組也可能包含部分業務含義，拿在做的結構及模組輸出舉例，對內的產品模型如下：
對外的商業模式及產品模型，這邊簡單描述下：
- 首先，工具是服務於具體公司的業務的，要先保證能滿足運營、視覺、開發以及測試的需求；
- 其次，工具類產品要本身獨立，成為一個產品，有其應有的底線，不進行強耦合；
- 再者，在工具類產品設計之初，就需要考慮到是否可以對外面向集團或者市場，這涉及到系統定位（內網/外網）、前後端互動形式（檔案/介面）、以及賬戶體系、抽象程度等多種因素的考慮；
- 最後，需要保證，對內可以帶來資源的節約和效率的提升；對外又可以具備一定的盈利的可能性。
接下來，我們聊一下產品的實現層級設定：
其中，每一個節點均很考驗產品設計能力，底層模組對應的資料結構及圖形化配置介面（落資料）、以json檔案的形式生成還是介面提供（效能和能力考量）、前端獲取json後解析的方式、渲染能力、CDN、多場景支援等等。不一一展開來講了。
最後再提一下，作為工具類產品，不可避免地會面臨諸多業務需求，千萬不能通過簡單的線性疊加需求來進行需求設計，否則幾個版本下來，產品會不堪重負，並且失去靈活性和擴充套件性。在進行業務需求溝通和需求拆解的過程中，要注重需求的抽象，儘量 減少與業務系統的耦合， 保持產品的 獨立性 。
獨立性、易用性、穩定性、靈活性、可擴充套件、可追溯，是工具類產品的核心。
如果有一天，作為工具類的設計者，有一天看到使用者（運營或其他）通過自己的產品，搭建出的頁面非常華麗，不看配置或者程式碼都不知道是使用什麼模組組合而來的，這種成就感，是無價之寶。
要做好一個完整的產品，需要在細節把控到位，針對性的有如下tips：
- 熟練掌握前端頁面除錯工具（chrome即可）；
- 底層模組設計時對資料庫和高併發業務場景的考量；
- 工具類產品的邊界，有所為，有所不為；
- 做好長期規劃及版本迭代計劃。
本文由 @whisperbot 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議