後台怎麼搭建産品?本文作者總結了其在工作中碰到過的後台産品類型，以及這些産品的特點enjoy~，下面我們就來聊聊關于後台怎麼搭建産品?接下來我們就一起去了解一下吧!

後台怎麼搭建産品

本文作者總結了其在工作中碰到過的後台産品類型，以及這些産品的特點。enjoy~

後台産品，顧名思義就是不直接面向用戶的産品。我總結了一款後台的産品可以從以下兩個個方面去衡量：

滿足的需求更多的是業務需求而不是個人的訴求。

産品使用的目的性極強。後台産品在使用的時候一般都帶有極強的目的性，或需要完成業務方面的操作，或需要完成某些流程的審批，總之在使用的時候一般不會因為個人情感方面的原因去使用。

根據上面這兩點，同樣是在點餐，你去餐廳服務員用手中的手機給你點餐的系統就是一款後台産品，而你自己點外賣或者掃碼自助點餐就不是。我之前做的一款PDA系統，裡面有個流程與淘寶購物流程十分相似，但它由于是為了輔助業務而開發的所以也是一個後台産品。基于這兩點，我在我做過的産品中歸納了一些幾種不同的後台産品形态，并且給它們分了類。

工具類

去年的時候，我做過兩款我們平台内部的應用，一個是平台的品控系統，另外一個是稱重系統。同時，最近在做ERP項目的時候做了PDA端的部分。如果按分類來說的話，我将這幾個系統稱之為工具類系統。類似的還有出去吃飯的時候店員在用的點餐系統，我們在收快遞的時候快遞小哥手裡拿的PDA裡面的系統。

我總結了工具類産品的幾個特點：

1. 使用端一般為移動端

由于工具類産品的特殊性，所需要的便捷性特别重要，往往需要在不同的場景下使用，使用工具類後台産品一般都為移動端産品。比如PDA,PAD,手機APP等。所以一般在設計的時候，一定要根據不同的業務場景選擇合适的操作端進行設計。

2. 操作性特别強

相對于其他的後台産品，工具類産品的操作性特别強。具體來說工具類産品應該是為了滿足某些操作流程，規範化，智能化，集約化所開發的産品。所以這個時候，使用工具類後台産品的操作就至關重要，同時也是其唯一的目的。

在設計工具類産品的時候，需要考慮以下幾個方面：

（1）操作的步驟，輸入按鈕等交互需要多加考量。由于工具類的産品核心功能是操作，如何能在該場景下簡單便捷的達到操作目的，是需要設計者去思考的。

（2）工具類産品很多時候使用的場景是移動的，而不是和其他後台産品一樣在電腦上操作的。所以，這個時候就需要考慮到工具類産品的使用場景問題。比如在一個大一些的市場裡面使用PDA時信号可能不太好，那麼弱網環境下的體驗應該如何，圖片是否加載，操作步驟是否要簡化；再如一個飯店的點菜寶，使用者在飯店這樣嘈雜的地方提示音的音量是不是應該大些。

3. 相對于其他後台産品權限較低，整體比較簡單，功能較單一

我們一般在提到後台在産品的時候，第一印象可能就是複雜與繁瑣。但是由于工具類産品的操作人員一般為實際的業務操作人員，所以其權限一般來說會比較低。同時也因為它可能隻是為了滿足某些需求而要做的一套工具。所以由于以上幾個原因工具類産品會比一般後台産品簡單，功能也會較為單一。

記錄類

記錄類産品指的是在業務人員進行操作的時候，為了以後操作的可溯性，以及工作後期的查漏補缺，當前所需内容的一些記錄等所開發的産品。比如在我最近做的ERP系統裡面，商品的到貨以及入庫都需要進行記錄，同時新采購的商品需要進行錄入，而這些都屬于記錄類的産品。一般來說記錄類的産品不會單獨存在，而是作為某一套大的系統中的一小部分。

我總結了記錄類産品的幾個特點：

1. 在規劃字段的時候，記錄類産品應該加上标識字段

由于記錄類産品很大程度上會作為今後某些工作的參考記錄，其數據的流轉性，與其他數據的整合的可能性較高，業務人員的審查更改幾率也交大，有時也會有存檔的需要。所以一般記錄類的産品都需要加上一個标識字段，通過設置好規則的編碼方式給其确定唯一ID。

2. 産生新記錄數據時應該思考全面

在設計記錄類産品的時候，每一條數據的産生方式都是需要仔細思考的。因為其實你整個頁面就是每一條新紀錄的疊加生成的，所以一定要在源頭把控好。

一般來說如果是通過外界業務的原因直接推進到系統做記錄的話，是可以通過在頁面增加新增按鈕來進行新增的，此時應該用彈窗還是新頁面的方式，某些字段是填寫還是選擇等都需要去思考。如果是在系統内部由于一些業務的流轉直接生成的記錄，那麼從另一個頁面帶過來哪些字段，去掉哪些字段，同時需要補錄什麼信息就是比較重要的點。

另外，在産生數據後這條數據是直接疊加到列表最上面還是有狀态有位置。新增數據後有沒有審核的流程，審核需要幾步，審核過程中數據是否展示出來，展示在什麼位置都有許多可以細化的點。

3. 做篩選與搜索要精簡準确

做記錄類産品，為了更加精準的定位到所需要的數據，一般都會做篩選與搜索。從條件上來說，頁面裡面所有的字段都可以作為篩選與搜索的條件，但是我們在做的時候，不能僅憑個人習慣來做定奪。要多和業務人員進行溝通，找出他們在操作此類信息最敏感的字段是什麼，最好辨别的字段是什麼，差異性最大的字段是什麼，然後來做删選與搜索條件。篩選與搜索做的特别精簡但是所能達到的目的卻十分準确才是一個好的篩選搜索。

4. 邊界條件，輸入字段，操作等限制條件要做到位

由于記錄類産品的特殊性，需要操作人員輸入大量的數據，這個時候如果不慎操作失誤但是卻沒有發現，就可能出現錯誤，耽誤業務。所以在設計的時候，一定要考慮到這些限制條件。比如該字段的邊界值為多大多小，字段允許輸入的合法字符是什麼，一共需要輸入幾位等等這些可以通過正則表達式等技術手段減少錯誤的限制要做到位。同時，不同條件下的該條記錄可能操作也不一樣。這個也需要考慮到。這一點也适用于下文要說到的配置類産品。

5. 排序、操作交互等其他小的功能點要考慮全面

記錄類産品每一條數據的字段類型都是相同的，所以有時候會涉及到排序功能。那産品經理應該考慮到數據的正常記錄方式是如何的，時間正序還是時間倒序，哪些字段允許排序，排序的方式是什麼。操作的交互需要思考設計，這個操作是在列表頁面就讓其操作還是需要點進詳情頁必須看完詳情後才可以操作。以及要不要做批量操作的功能等等其他一些這樣小的功能點，産品經理也要根據業務考慮全面。

配置類

配置類産品可以說是後台産品中較為常見的一種，同時也是涵蓋内容較廣的一種。内容管理配置，活動配置，人員管理配置等等都叫做配置類産品。關于這個系統不同角色的權限配置，以及其他頁面下拉框的選項配置等等。所以作為一個後台系統，配置類的項目應該是必不可少的。

常見的單獨配置類産品比如CMS，這個應當就完全屬于配置類産品了。那我在平時的工作中也總結了幾個關于配置類産品的特點：

1. 一般有配置項，所以不會是單獨存在的

配置類的的産品一般都是為了達成系統中其他的一些功能點，或者配置另外一些網站等之類的東西所開發的模塊，一般不會單獨存在。所以在做配置類産品的時候，我們做的時候不能簡簡單單的将自己目前所做的東西做完就好了。一定要聯動着看配置類産品以及它所配置的系統所更改東西的變化，大局觀更重，所要考慮的東西也更多。

2. 思考的廣度不能停留在表面

在做配置類産品的時候，對應的配置項可能不是特别複雜，但是産品經理在做的時候卻要慎重思考。比如在做CMS配置商城搶購的時候，前端需要所操作的頁面可能會比較簡單，用戶所要接收到的信息也不會特别複雜，但是在進行後台配置的時候，卻要将所有的信息都考慮到。即便用戶隻有1%的操作幾率，那也要配置到這1%時候的操作結果。再如做角色劃分的時候，有些角色可能暫時用不到，但是為了整個系統未來的疊代等考慮要将其做進去。

3. 角色處理時數據要做整理，流程要走通

如果我們在做一套特别複雜的系統的時候，配置項往往都會決定着你的系統是否易用，因為可能不同的角色看到的會是不同的操作内容。而這些操作内容對于該角色來說都會是一個有機的整體，要讓他們覺得這個系統不突兀，所有的流程都要流暢，不覺得哪裡少點什麼，怪怪的。

所以，我們在進行配置設置的時候，不能簡單的做字段的增删，功能的顯示隐藏，要将系統的易用性放在重要的位置考慮。要在隐藏字段與操作的同時将與之關聯的内容都進行配置。這樣才可以讓不同的角色使用時都會覺得自己用的是一套完整的系統。

關系類

關系類産品可以說和上面的幾種産品的分類定位不一樣。無論是配置類還是記錄類，都是通過其操作方式來劃分的。而關系類是通過功能來劃分的。隻是因為自己最近在做關系類産品，所以拿出來單獨說一下。

市面上目前比較典型的關系類産品就是CRM了，許多公司通過自己的CRM來管理與客戶之間的關系。我們最近在做一個關于合作夥伴的管理系統，所涉及到的關系主要是商場與商場入駐店鋪之間的關系管理，設計一個關系管理産品的時候，思路是什麼樣的呢？

我覺得，既然是關系管理系統，那麼産品經理第一步要做的就是理清他們的關系，雖然可能一開始的關系會特别的複雜，而且難度更大的是可能有時候不止是兩者的關系，會有三種甚至多種角色的交叉關系，這個時候，開頭的工作一定會很艱難。

一般在做的時候，第一步要将這角色之間發生的所有交流都整理出來，在何種情境下這兩方會發生交流，然後在系統中會有哪些交流。這一步異常重要也十分複雜，需要産品經理極具耐心和細心。

其次，在将關系整理完畢後，需要整理出一條主線，即為什麼這兩者可以發生關系？之間怎麼傳遞的？傳遞的過程中會帶來哪些信息？需要進行什麼樣的操作？比如一個電商的客戶管理系統，其主線就是客戶購買商品，所以這個就是它的主線。在數據内容方面，客戶購買完商品之後，我就有了客戶的購買數據，可以整理出客戶的RFM數據模型，可以為每個用戶進行畫像。在營銷方面，我可以根據客戶的購買的狀态及記錄進行相應的操作。可以通過其客單價複購率等為客戶進行VIP的評級，不同優惠的制定等等。通過這條主線進行發散，将整套系統的架子先搭起來。然後再填充上無法通過此流程進行關聯的内容，比如客戶信息的錄入等等。

然後，再根據業務的重要性調整位置，填充具體内容。

最後，将整體流程跑一邊，看一下有沒有遺忘的流程，再和需求方業務方對接。

内部應用，外部應用

内部應用與外部應用說的主要是我們提供的服務對象。内部就指的是公司内部用的，而外部可能就會作為一個B端産品面向市場或者合作夥伴。

在做我們網站首頁的CMS時，第二部分的廣告條數量一開始是打算限制的，後台對接的時候負責CMS的運營說我們不會傻到加100條的吧，網站的内容也是我需要負責的啊；在做品控系統的時候，需求對接的十分順暢，因為其實這些東西都是他們實實在在迫切要用到的，然後推到我們這邊來做。

所以在做内部應用的時候，相對來說壓力和挑戰都稍微少一些。一是本身就是自己的同事需求方面會盡可能的滿足你，二是既然公司要做這個系統就說明了的的确确公司需要這樣的一套系統。

然而外部系統卻不是這樣，因為這個時候我們面對的時候客戶，如果碰到一些本身自己需求就不明确的客戶，或者市場上有和我們在競争的客戶，這個時候如何博得客戶的歡心，得到市場的認可也異常重要，與C端産品的研究用戶就有一拼了。

以上是我總結的一些不同類型的後台産品及其特點。可能劃分的方向不盡相同，有些也會有些重複，但是都是作為一個單獨具有該類型鮮明特點的後台産品，這也是我在平時工作中所總結出的它們的特點。一套後台系統往往的複雜的，龐大的，單獨以此作為一套系統的其實不是很常見。将這幾個小塊根據業務内容實際整合到一起，也是考驗産品經理能力的地方。

專欄作家

執迷，執迷有悟，人人都是産品經理專欄作家。電商O2O領域，關注數碼硬件，人工智能，新聞資訊領域。

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

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