APP、網站、微信二次開發非常復雜的后臺如何策劃呢？面對客戶給過來的需求中，大多數都是前端需求。很少客戶給我們后臺需求，很多想當然的實現效果在他們腦中基本沒有概念。那么讓我們用一個簡單的門戶網站舉例。
背景：A公司目前門戶是靜態的，老板為了拉融資要求對門戶網站進行改版。
需求：在網站上要有新聞模塊，首頁需要有輪播圖可以更換公司的大事件，給公司一個發聲的地方，明年的重點需要擴大招商范圍和規模，網站上最好有個招商板塊，再有就是對公司整體有個業務介紹，最后，公司最近招人比較困難，如果官網有個招聘模塊也許就能提高招聘的效率。開發周期：一個月時間，網站就要上線！要求就是這么多了，如果是你，你會怎么做？
畫原型嗎？NO。面對這個需求，我們需要調動多少人？產品經理自己，UI一個，前端一個，后端1-2個，市場文案一個，人力資源輔助配合招聘模塊1人，最后是網站后期運營者。想想功能，想想要完成的事情，大概就這么多。根據需求可以看出，大概功能并不復雜；做個功能列表，簡單用語言包裝要做的東西，然后去分別私聊或者召集大家開會，讓大家提供一個完成時間，這個完成時間不能超過Deadline，所以溝通過程中可能需要你去說服對方，提高效率，甚至可能加班，讓大家有心理準備。搞定了人，回來看看產品。
我們先來做個簡單的需求梳理：
首頁，會有一個輪播圖方便后期更新，如果更新不頻繁也可以做成靜態，開發成本低。首頁還會是一些公司競爭力介紹等等。新聞，新聞會有運營人員不定期更新，就是需要創建信息，他就是需要在后臺有這個功能。招商加盟，看看招商網站多半是一些公司介紹，在底部會放一個聯系方式提交的地方，詢問老板后，他認為也需要這個模塊，需要傳遞信息，他也需要在后臺有個功能。招聘，看看招聘網站，功能還是挺多的？那么我們需要那么多嗎？用戶可以有個word簡歷通過網站上傳給我們，人力資源人員可以通過后臺下載或預覽？再來一個解決方案，在前臺有很多表單可以讓用戶填寫，直接提交給后臺。這些都是用戶要與后臺產生互動信息。
但是這些方案好像聽起來不錯，那么不如用最原始的方式，雖然不那么酷但是后簡單，前端只提供職位職責預覽，并提供一個人力的郵箱，大家可以向里面投遞簡歷，后臺只做職位的簡單發布。業務介紹，屬于靜態頁面，設計上去就可以了，這個不涉及到后臺。
經過分析和溝通，我們發現與后臺有交集的地方分別是，首頁輪播圖，新聞，招商和招聘。這時候你可以去看看其他產品，在這些模塊都會顯示哪些字段信息，找到你決定有用的，把他填寫到這些功能描述中，再去進行前臺的產品設計；不過有時你會發現做著做著發現缺了某個字段，為了避免這種事情的發生，就需要你在信息收集的過程中，多去看幾個產品，把他們的展示的內容都先羅列下來，再做刪減。
前臺不是今天說的重點，我們直接進入后臺設計。
我常以為后臺就是一個個的「倉庫」這個庫里堆放著你想要管理的內容，后臺的搭建就是創建一個又一個的庫，并且將他們合理的連接起來?；乜次覀円龅臇|西，可以簡單的分為四個庫，并對他們分別管理。
新聞管理
輪播圖管理（廣告位管理）
加盟信息
招聘信息管理
知道有哪些庫了，我們需要將他們合理的組合起來，形成”導航“。業務流程越長，功能越多這個組合的工作越不好，這就是為什么需要信息架構師這種職位，不過面對簡單的后臺，產品們還是可以直接應付。整個后臺的界面通常會有以下模塊組成：后臺導航——管理庫(管理內容列表\管理的內容)，從最大的框架到最小元素。
后臺導航
在我接觸的后臺導航中常見的有幾種。
1. 橫向導航
2. 縱向樹結構導航
3. 橫向導航縱向樹結構
橫向導航會用在后臺功能較少，層級很少的情況下，他的優勢就是學習成本低，劣勢就是可擴展性比較差。
縱向樹結構導航，這個我們看的其實是比較常見的，很多電商網站的個人中心或是訂單頁面就是用的這種結構，邏輯清晰，能夠很快的找到想要找的東西。第三種比較復雜，適用于平臺功能較多，功能模塊相差很多的網站，會在最頂部的橫向導航放置頂級功能導航，在某個功能下用樹結構導航清晰的表現二級功能。因為這一次我們做的功能并不復雜實際上可以用橫向導航，不過因為我是根據現有后臺來制作，所以為了不增加開發成本，所以依然延續橫向導航縱向樹結構。
管理庫
決定了哪種導航形式，來看看最重要的「管理庫」，面對「庫」大家記住，絕大部分情況都會有個「列表頁」，然后就是對信息的「增刪改查」，遇到商品或是輪播圖還會有上下架，顯示與隱藏的功能，基本上「庫」都會這樣的管理的。
那么這樣想，是不是新聞的管理設計起來就容易多了。添加新聞，刪除新聞，編輯新聞，搜索新聞，再加上一個新聞列表，列表中在顯示一些需要的字段。其實整個管理列表頁已經躍然紙上了，之后就是正文編輯了，用戶可以從列表頁或導航中的「添加新聞」進入，把可以實現功能的字段做到頁面上，再加上文本編輯器，一個發布按鈕，一個簡單的新聞管理就搞定了。
那加盟信息怎么做？其實也很簡單，既然用戶需要在前臺提交信息，那么我們的后臺實際上就是一個接受信息的地方。我們讓用戶在前臺提交「姓名電話郵箱」等聯系方式，在后臺加盟管理中，利用列表頁將這些信息進行展示，有新的加盟信息推送過來可以在導航上加一個數字角標，這個功能甚至都用不到詳情頁就能搞定。
留個思考問題，廣告位管理你是不是也會做了呢？
用上面的辦法思考——列表（增刪改查）+詳情（添加內容）。是不是思路變得清晰一些？
像門戶網站這種還算比較簡單的，不過為了方便管理，你可以給不同的角色賦予不同的權限，比如人力資源的同學只可以使用招聘發布，網站運營人員只能使用新聞發布等等，專人專項，分工明確。
角色劃分與權限是怎么來決定呢？
跟隨你的產品業務。比如拿電商而言一個商品從用戶確認下單，支付之后，在后臺會走過多少流程，我想每個公司的業務流程都會不同，但是在這個流程中
一定會涉及到很多「角色」來處理訂單，而這「角色」就是你來劃分后臺權限的依據，而功能亦是從業務需求中轉化而成的。
讓我們短暫回顧一下
回顧一下后臺的設計，我們會發現他實際上是一種面向信息的設計，對于信息進行審核，記錄，閱讀，操控等等。在做后臺設計時你需要對業務流程有一定了解，知道哪個環節會與系統產生交互，那么這個交互的點就是后臺設計的「庫」，我們需要對這些庫進行管理，有時候我們還需要將這些庫與另外一些庫進行連接，庫與庫之間互相調取數據。比如電商網站做的促銷管理，都會去調用「商品庫」里面的數據。想要掌握后臺產品的設計的核心就是處理好每個庫的劃分與整個產品的運作邏輯。
先做前臺還是后臺
這是我曾經很糾結的問題，不知道你是不是也是一樣，當你慢慢了解之后，這個問題其實就不復存在了，找你熟悉的東西開始做，這樣會讓你有我已經完成了多少多少了的感覺，而不是面對一個不熟悉的東西，痛苦的死磕，磕到對自己失去信心。前臺與后臺共同構成了你的產品，缺少一方，產品便無法運轉，先把業務邏輯思考清楚，你會發現「哦，這里是給用戶看的」「啊，這里是后臺要處理的」當業務邏輯走向完整之后，我想你的前后臺就都已經設計完成了。還有一個問題可能會比較困擾人。
后臺設計要不要注重體驗和UI？
答案是肯定要，視情況而定。這個情況有可能是時間，有可能是產品階段，有可能是公司目標與規模。有些后臺只要能實現功能就可以，有些后臺需要開放給第三方來用，對于產品的“好用”程度不同，不過如果條件允許還是反復推敲下，其中的邏輯與體驗比較好。
前一陣幫助公司對商城的賣家后臺做了體驗上的改版，因為之前都會不斷的增加功能，沒有對產品很好的梳理和設計，導致很多地方體驗不好或是信息架構混亂。這些細小的地方只要多多體驗，多思考就能夠找到更好的辦法。比如后臺有個手機認證的功能，之前只這樣的操作。未認證的用戶進來的狀態，會顯示用戶未認證，點擊立即認證會有個模態窗口，讓你填寫手機號，驗證碼。
好像很正常，也能夠綁定，那么問題出現在哪里呢？不夠直接，需要兩步操作。于是做了如下修改，點擊導航中的認證中心，直接去判斷是否綁定，如果沒有綁定，直接顯示之前彈窗中的內容，兩步變一步，簡單了許多吧。
前兩天去聽了一個產品培訓課，課上深刻的記得老師說過的一句話，體驗就是對流程的梳理與調整。細思下，很有道理吧。
不知道你現在，是不是已經知道后臺是什么，給誰用，如何設計了。最近在研究拼車產品，不知道你有沒有用過嘀嘀順風車，如果沒用過你可以馬上體驗一下，然后思考一下，他的哪些東西會在后臺出現呢？
