📖 ZKIZ Archives

什麽才算好的自媒體後臺？今日頭條PK企鵝哪家強？

羅超 2017-04-12 12:39

前幾天在科技媒體記者群“山寨發布會”看到有道雲筆記在宣傳其剛上線的“語音速記”功能，受到群里記者小夥伴的歡迎。有人說再也不需要錄音筆了，有人說以後再也不用在現場劈劈啪啪打字幹擾別人了，還有人說以後機器就能寫快稿了。從科技媒體記者們熱捧這個小功能，可以看出內容創作者眼下還是有許多痛點的，創作工具遠遠不夠多、不夠好、不夠智能。

最近兩年，隨著企鵝媒體平臺、今日頭條、UC等內容平臺的興起，在平臺上進行內容創作也成為越來越多文字工作者和內容生產者的日常工作。以我本人為例，自從2012年嘗試撰寫科技專欄以來，我一直跟不同平臺打交道，最初是科技博客的投稿後臺，現在則入駐了超過10個自媒體類平臺，除了頭條號、企鵝號、網易號、搜狐、大魚號、百家號等“號”之外，還有知乎專欄、艾瑞專欄等等，我每天都要耗費個把小時進行內容同步。這些平臺的後臺已經成為內容創作者的工作臺，好用的後臺，不只是可以讓發布內容事半功倍，還可以給內容創作者提供好的支持。

不同內容平臺的後臺究竟做得如何？最近“羅超頻道”基於長期的體驗做了一個橫評。一方面，希望可以給不同內容平臺提供改進建議；另一方面從中管窺內容平臺的策略和業務能力。在進行正式評測之前，先談談我對內容平臺後臺的理解和期望。

自媒體後臺的自我修養

首先說一下我現在的日常的內容生產流程。

一般是通過MacBook在Pages里面撰稿，因為它提供簡潔易用和沈浸式的書寫體驗。在發布之前會將需要用到的圖片存放到一個文件夾，發布時會用Chrome瀏覽器打開所有自媒體平臺，逐個發布實現“一處水源供全球”。還有一些自媒體朋友的工作流程可能是開著某個平臺的後臺寫稿，之後再同步到別的平臺，我偶爾也會這樣做。總之，大家的使用場景和流程應該是大同小異。

其次，談一下我眼里合格的內容平臺後臺。

1、正常工作。確保內容可以正常發布，不會頻繁地出現提交失敗、提交卡頓、提交後消失、圖片上傳失敗等問題——除非遇到不可預測的偶發故障。

2、簡單高效。要讓內容創作者盡可能少的在發布內容上耗費時間，只有這樣才能聚焦於創作本身。比如發布內容的步驟要少、不用重複填寫不必要的信息、支持一鍵導入、直接複制在線圖片等。

3、容錯能力。比如在線編輯時突然卡死重啟了，內容要能自動保存草稿，否則創作者肯定想跳樓；再比如提交時沒有填寫標題等關鍵信息或者標題字數超過限制，要有友好的提示。

最後，再談一下我眼中優秀的內容平臺後臺。

能做到上面三點，是一個正常的內容發布平臺，不只是自媒體後臺，包括發帖後臺等等表單提交頁面，都要具備這些基本能力。這三點都做不到，不能算一個合格的後臺，歡迎對號入座。但是要成為一個好的內容平臺後臺，就必須充分考慮內容創作者的運營需求，滿足其在內容管理、粉絲互動、數據分析、財務統計等工作項上的需求。

具體來說這些點很關鍵：

1、內容管理：通過技術手段提高發布效率，比如自動檢測格式、比如編輯框設計、再比如考慮到原創自媒體的內容維權訴求的抄襲檢測、原創標記、抄襲舉報等功能。還有有合適的內容維護（撤回、編輯、刪除）權限。總之，必須確保自媒體高效地進行內容的發布和管理。

2、粉絲互動：自媒體平臺上，內容是產品，產品就要運營用戶（不是讀者）。因此如何讓自媒體與粉絲建立聯系，並且圍繞內容進行互動就至關重要。

3、數據分析：用數據指導內容生產是每個自媒體平臺都在提的。傳統媒體時代媒體人憑借經驗，互聯網時代自媒體要基於數據對內容進行生產和運營。

4、財務統計：無利不起早，自媒體平臺都有不同形態的分成機制。讓內容創作者可以清晰地了解收入明細，便捷地對賬和提現同樣是十分重要的事情。

自媒體的後臺哪家強？

接下來，基於我上面提到的“標準”，對我認為最具代表性的幾個自媒體平臺後臺進行評測。

1、今日頭條：該有的都有，還有小創新。

今日頭條能夠從眾多個性化資訊App中脫穎而出，除了算法支撐起的千人千面特質之外，一個關鍵原因是App足夠簡單好用——而不是像其當初對手一樣去重視設計或者別的。在後臺上今日頭條也做到了簡單好用，不論是內容管理還是粉絲互動還是數據分析還是財務統計，都很好用。

說一下我印象深刻的幾點：

1、發布效率高。比如在線圖片複制過去，它會自動保存到雲端；再比如每次打開都自動載入上次的草稿，聲明原創一般不需要填寫任何信息，編輯框具有標題、引用、加粗、項目這幾個關鍵格式選項，不多不少。

2、數據分析強。文章列表就可以輕易看到關鍵數據，其外還提供文章分析、視頻分析、粉絲分析、頭條號指數等細化分析服務，可以看到細粒度數據，支持excel表導出進行更細化分析。

3、創新功能多。雙標題支持不同標題的AB測試（側面表明今日頭條上標題的重要性），粉絲必見和內容置頂給自媒體更大的運營權限，號外服務支持對內容進行付費推廣。

說一下我覺得不好的點：

1、互動能力差。今日頭條用戶評論活躍度高，但是卻不好管理，尤其是在評論數變多之後，很難去運營，設計上也不夠周密比如回複一個評論之後就跳走了，也很難理清與粉絲的關系。

2、圖片描述功能不好用。頭條編輯框增加了一個功能，添加圖片之後就會強制要求填寫圖片描述，很難取消，但很多時候圖片並不需要描述，所以導致了編輯效率的降低。

整體而言，今日頭條的後臺已經算上乘水平，不少自媒體小夥伴都曾表達對今日頭條後臺的認可，在整體功能大同小異時，能體現出內容平臺功夫的地方在於細節。今日頭條後臺最近增加了批量視頻上傳功能，反映出它在強化短視頻。還增加了原創維權賠付功能加大原創保護。頭條號指數的五維模型表征內容質量進而決定分發效果，扶持優質內容、清洗低質內容成為一個趨勢——這是它必須要解決的問題，否則就會劣幣驅逐良幣。

2、企鵝媒體平臺：一鍵分發，充分發揮騰訊優勢。

盡管今日頭條聲名鵲起近日還流出10億美金融資消息，然而眾所周知，騰訊才是移動資訊的No1。不論是易觀還是Questmobile數據都顯示，騰訊新聞是最大的移動資訊App，天天快報是僅次於今日頭條的第二大個性化資訊客戶端，其外騰訊還有微信、QQ等分發渠道。

騰訊對內容創作者的統一窗口就是企鵝媒體平臺，今年啟動芒種計劃2.0，投資12億補貼內容創作者，後臺這樣的基本支持自然不會缺位，體現出了騰訊的產品功底（當然，還是要看具體團隊，同樣是微信，Mac版就比手機版差遠了）。

說一下我印象深刻的幾點：

1、發布效率高。跟今日頭條一樣，功能設計都註重發布效率，自動保存圖片、草稿和原創聲明都有，同時也很少出現提交失敗這樣的情況。最近還上了一個功能，支持標簽的自動生成，可以少填寫或者不填寫標簽了。

2、互動能力強。騰訊是社交基因，企鵝媒體平臺也在互動上發力，可以對評論進行精選，可以分別從評論維度和文章維度來管理評論。

3、一鍵分發能力。這是騰訊的優勢，與今日頭條只有一個App不同，騰訊有分發渠道矩陣，不少註意力入口，微信、QQ自不必說，騰訊新聞、天天快報在移動資訊中分別位列1、3名，還有QQ瀏覽器、手機騰訊網以及騰訊視頻、騰訊體育等垂直App。企鵝內容平臺與這些平臺都已（將）打通，在後臺可以選擇內容源同步，接入微信；也可以進行內容輸出到QQ等平臺。至少在騰訊系，騰訊媒體平臺的後臺做到了一鍵分發，降低獲取單位閱讀數的時間成本。

4、數據分析強。跟頭條一樣，提供文章分析、視頻分析、粉絲分析、頭條號指數等細化分析服務，可以看到細粒度數據，支持excel表導出進行更細化分析。還提供熱門文章可以讓自媒體進行針對性的選題優化。不過，在文章列表頁的數據沒有頭條詳細。

說一下我覺得不好的點：

1、編輯框有待改進。企鵝的編輯框，缺乏其他媒體平臺後臺基本都有的標題、引用和列表三大格式刷，很多時候會覺得別扭。

2、缺乏雙標題等功能。文章置頂、雙標題和粉絲必見等功能還不支持，相信為時不遠。

3、發文數量只有5篇。一個自媒體人一天只能發布5篇內容，可以滿足我的產量，但可能無法滿足一些團隊運作的機構自媒體的產能訴求，我想騰訊此舉是出於控制內容質量的考慮，但要做到這一點靠限制更新數量是做不到的，而是要更系統化的方法，當然騰訊也在踐行。

企鵝媒體平臺後臺充分考慮了自媒體人的日常生產和運營訴求，提供全套工具而不是一個單純的發布後臺。它與今日頭條的後臺大同小異，但充分利用了騰訊在社交互動和多渠道分發上的優勢，提供了更好的互動管理和一鍵分發能力。最近企鵝媒體平臺上線全網維權功能表明其正在加強原創保護；企鵝媒體平臺還支持圖文直播等內容形態，形成內容的差異化布局。

其他自媒體平臺的後臺功能大同小異，但整體都各有長短，簡評如下：

1、百家號起步較晚，在內容發布、數據分析、互動管理、原創維權、一鍵分發等方面都還有較大提升空間，比如它現在連標記原創、定時發布都還不支持。“發現”菜單下，通過大數據分析時事熱點、稀缺詞給創作者提供內容創作參考算一個創新。

2、一點資訊基本做到了跟企鵝媒體平臺、今日頭條一樣好用，一鍵導入功能還支持對不同來源的文章鏈接進行導入，但是在數據分析、互動管理、原創保護等維度還有較大提升空間。

3、UC頭條（大魚號）在內容發布上已經做到足夠簡單，亮點是數讀輿情功能，可以進行更專業的輿情分析，在所有平臺中做得最全。不過，它在互動管理、數據分析等維度也有進步空間。

整體而言，目前今日頭條和企鵝媒體平臺的後臺相對更完善、更好用，這也與公司入場時間有一定關系，這兩家做得早，也是目前最大的兩個自媒體平臺，後臺好用似乎也是理所當然。

自媒體後臺的下半場

拜王興所賜，一切都在進入下半場。自媒體後臺也在進入下半場，我認為以下幾個方面最為重要：

1、全網實現一處水源供全球。

我現在每篇文章都要花大約1個小時進行10多個主流自媒體平臺的更新，非主流的不會主動更新。盡管自媒體後臺不斷提高發布效率，但依然還要時間。能不能實現全網一鍵發布呢？就像企鵝媒體平臺打通騰訊新聞、天天快報等九大分發渠道一樣，如果不同公司之間形成一個協議，實現一鍵分發對內容創作者來說每篇文章可以省下差不多一個小時的時間，這個事情就很有價值，這樣內容創作者就可以更多聚焦在創作本身，降低單位閱讀數的運營時間。

我認為這個可能性還是有的，畢竟自媒體平臺之前的競爭不應該是提高發布門檻，因為就算不打通自媒體也會手工去更新到不同平臺。自媒體平臺應該聚焦在內容生態、用戶運營、商業變現等維度，而不是內容發布這樣的細節上，未來就看誰牽頭來做這個事情了，這也蘊藏著第三方的自動發布平臺的創業機會。眼下對於內容創作者最合適的策略還是聘用實習生助理進行更新。

2、人工智能技術的應用。

人工智能正在改變各行各業，它與資訊行業結合還是非常密切的，不過更多是在內容的個性化分發上，除了今日頭條、天天快報這樣的個性化App之外，還有騰訊新聞、網易新聞等新聞App也在引入個性化算法。不過未來人工智能技術會更多被應用在後臺，比如實現智能語音寫稿、自動識別錯別字、智能識別洗稿洗思路的內容、大數據分析指導創作、給創作者生成100個標題供選擇……總之，用AI幫創作者提高效率。

3、移動支持實現隨時隨地創作。

現在對於大多數自媒體來說，說到後臺還是會首先想到電腦後臺。很多時候會不方便，比如在外面時急著要發布內容、更新內容、刪除內容、添加白名單、精選評論，都還不夠好用，自媒體很多時候都有到處找地方用電腦的窘迫。微信公眾賬號後臺推出了移動App之後很受歡迎，我想自媒體平臺後臺的App會成為標配，讓自媒體隨時隨地管理後臺，至少可以完成部分事情。

總之，後臺是平臺能力的展示窗口、是平臺與自媒體的互動窗口，也是自媒體的生產平臺。因此，自媒體平臺必須做好後臺，不要設置任何障礙，提供創新增值服務，同時還可擁抱AI、開放和移動化解決現在自媒體們的問題，讓他們可以專註於創作本身。

文章評論

匿名用戶

發布

全部評論：10

發布

後臺產品經理跳坑“指南”

PMCAFF 2017-05-18 13:15

來源 | PMCAFF

文 | crossfone

從入產品坑開始，其實早期都是做前臺產品和Web產品為主，對前臺業務、用戶體驗、交互還是有一定熟悉了解。近些年來，被逼跳後臺、帶團隊，一個項目往往前後臺產品經理基本都帶上做。對於後臺產品開始也慢慢有了自己的模式和想法。

在之前的回答中，也提到像我們這種媒體型互聯網公司來說，產品還是非常看臉的。做後臺產品，不僅僅需要有業務流的分析梳理能力、項目管理能力，還必須要帶上點兒交互設計能力。多種角色集於一身，所負責的往往是一整條產品線，一名產品經理必須能有很強的獨擋一面能力。

好了，既然獨當一面，踩坑就是難免之事。結合幾個小案例，回憶回憶吧。

龐大後臺架構坑

也許是運氣太好，第一個後臺產品就是一個大坑。這是一套自主試驗型的後臺CMS產品，產品之初是一個很小的架構規劃，目標是小型資訊APP後臺使用。但是，很快產品的風向就變了，架構鋪大，功能和業務邏輯有的沒的都往里加。

就這麽大概幹了3、4個月，RD團隊和產品團隊已經處在崩潰的邊緣，這時候，我們團隊加入了，原來的產品團隊火速撤離，坑爹的經歷開始了。剛接到產品時我們做的第一件事情就是梳理功能架構：

看到了吧，這是一個小型APP的CMS可能需要的後臺架構嗎？顯然不是。

問題清單如下：

內容管理不夠突出，並且分布在各個功能模塊中。

會員管理是個毛？完全沒用。

維護菜單下一堆百科內容管理，我實在不想看下去，全都拿出去。

站點管理和欄目管理等核心管理功能不全，需要增加管理功能。

經過和Boss的一番論戰，將一些將來可能用到的模塊繼續保留，但調整結構，核心功能集中。最後的初步成果如下： 

經過這次調整，成績可以總結為：

首先，我們對產品的功能架構進行了相當深入的了解。

其次，建立了站點管理模式，使得系統大規模站點集群管理成為可能。

再次，對缺失的核心管理功能進行了設計。

最後，對後臺的交互和體驗做了全新改版設計。 

但實際上回頭來看，仍然留下後一堆後續的大坑，也總結一下：

被逼留下的功能模塊實際上不少到最後也沒有用上，功能該砍的時候還是要痛下狠手。

欄目配置頁的核心作用是絕對突出了，在這個面板里能幹的事情實在是太多了，而其他關聯的功能模塊能對其配置調用的相對有限，造成一些管理不便。

編輯器有大坑，我們默默地沒有發現。這個功能模塊被前行牽扯了太多業務邏輯和功能，導致後續代碼維護的困難。

權限系統還有坑，這個後面講。

權限體系的設計坑

接上文的權限體系坑，原來的系統權限體系經過一段時間實際使用測試發現，具有以下問題：

權限的類別不清，View類權限和Function類權限高度綁定，導致用戶菜單難以根據角色權限調整。

Function類權限沒有根據角色進行調配，幾類用戶角色沒有很好實現權限隔離。

試運行階段，系統管理員由RD同學兼任。用戶權限配置在實際工作中，效率很低，需要提升交互效率，同時還要降低學習門檻以便RD撤退。

面對這些情況，具體怎麽做的，我就貼點兒圖少碼字吧：

使用RBAC角色權限控制模型：

設計權限應用流程：

增加Data類權限，對應原來的欄目、稿件等內容類操作權限。

將原來View\Function兩類權限拆分，View類權限單獨在菜單權限模塊配置。

重新設計配置頁面交互，提升效率。

看下圖，原來的設置方法是一條下面有N條子菜單，控件方式既有單選也有多選。調整後改為左側權限樹方便批量選擇，右側詳細功能列表，單項功能可設：是、否、全不。 

在權限分類的理念下，建立角色組概念，將內容運營、開發、系統管理等角色分離，讓角色組作為角色的權限模板進行快速全局管理。

上面的一套工作看上去還挺過癮，但我可以負責任的告訴你，坑爹的地方太多了：

角色組概念很美好，但和權限類別還是無法區分，搞到最後萬不得已，搞出了可視化權限等級。

用戶權限配置聽起來簡單清晰多了，用戶體驗細節超豐富，但實際上系統管理員看完之後依然想罵娘！

權限維度很多，導致多個權限配置頁面都可能要做相關快速配置入口。API多，還要交叉調用，RD們已經罵娘了！

這件事情的最終結果是，辛辛苦苦做了一個禮拜，Boss並不買單，要求砍砍砍改改改，結果砍了多少然而我並不想說……

後臺做交互的坑

前面看到有一些後臺界面的截圖對吧，看上去還挺不錯的吧。壓根沒有交互設計師，我們產品狗們畫的可全都是最高水準的UE圖，甚至交互功能都做完了。

結果可想而知，以後後臺所有頁面都要按照這套交互做，UI和FD們更是被我們逼瘋。不過，也得承認確實有好處：構建了自己的一套前端交互框架，不少後臺產品可以直接照搬照抄這套交互邏輯。

坑很多，還是講講正面案例吧，比如說本人設計的一個在線VR全景快速生成後臺。

在做這個後臺前還是對全景拼合相當了解的，全景在線展示基本上底層都是使用的老毛子Krpano，這個平臺的交互功能豐富，做快速後臺的話，需要做一定思考，什麽功能參數是我們需要的，哪些是用戶高頻操作的。開始設計前，簡單畫了個圖幫助思考： 

業務流程基本就是簡單幾步：設置簡介-添加場景圖片-添加附加內容-設置交互事件-提交。附加內容資源主要有：按鈕、圖片、視頻、音樂、文字。

主要的VR全景應用需求有：

根據上面需求，構建了場景將最常用的功能設置加入場景設置第一步驟中： 

根據場景編輯器的需要，先添加擴展內容資源，後在場景編輯器中添加已上傳資源並調試位置：

跳坑之後總結的6點教訓

案例簡單講了幾個，最後總結下後臺產品經理的經驗教訓吧。

1、後臺產品能不新做UI和UE就別做，盡量用些現成的前端框架，基於bootstrap的後臺前端架構有不少，商用的有不少，開源的也有很多好用的，這種東西一搜一大堆。

2、To B 類後臺產品實際上也非常需要良好的用戶體驗，這類後臺產品可以加入細膩的交互設計，但也要註意把握度，產品工作的重點仍然是需要聚焦在業務梳理和邏輯。

3、To B 產品更需要良好的業務流程設計，盡可能涵蓋用戶（每種參與者都要）流程、業務流程、系統流程這幾項關鍵流程。

4、後臺業務流程負責，不妨在流程圖中為不同角色或模塊設置不同的“泳道”以方便RD理解（也是為了方便自己理解）。

5、功能架構複雜的後臺產品定時梳理功能架構十分有用。搭建SVN，利用Axure的多人協作功能提升效率。

6、後臺功能的調整上線重要度並不亞於To C 類產品的功能上線，務必盡量做到多方測試，特別是主要使用角色的測試盡量全覆蓋。有些改動你只是和其他調整修改時順手修改的，但實際上會嚴重影響某類用戶角色的使用習慣，盡量先灰度測試再做上線計劃。

文章評論

匿名用戶

發布

全部評論：10

發布

關於後臺產品，你需要知道的4個原則

枯葉 2017-07-11 10:03

來源 | 人人都是產品經理（ID：woshipm）

作者 | 枯葉

大家都說後臺產品難做、要求高，這是有原因的。而且這個原因會超出我們的認知，一起來看看吧。

什麽是後臺產品

後臺產品也被我們稱為後臺管理系統、內部管理系統。

簡單而言，是給企業員工開發的辦公性質產品，同時也是對用戶使用的App，Web等產品的一個伴生產品。

我們還可以將後臺產品按照使用對象分成兩種：

其一是自己使用的產品，實際上，任何一個產品都需要一個後臺，包括我們的C端產品。

另一種是客戶性質的產品，多見於B端產品。

我們會認為後臺產品很難，本質原因是因為做後臺產品的人很多 ，我們常常將後臺產品交給新人來設計，用來練手，也用來學習。

後臺產品的特殊性質，讓我們可以將其交給新人練手，這個特殊性質在於他的用戶身份——因為這是一款自己人使用的產品，我們能對其具備最強的包容心，即便他的體驗不那麽友好，他存在許多問題，我們也可以通過人為的方式來協調解決。

後臺管理系統的用戶大部分都是運營同學使用，產品同學偶爾使用，而後臺系統最終坑的也是這兩個崗位的同學——這種坑最終會被轉化成崗位之間的矛盾。

然而在實際項目中，我們往往會將後臺系統設計的非常簡單，最大限度的節省開發資源。同時也是為了節省產品經理的精力耗損，我們會將該系統的設計任務交給新人完成。

原因在於：後臺系統設計的好壞對於用戶而言，損失較少，幾乎可以不計；這是一個做好了沒有人稱贊，做差了，也沒人責罰的產品。

在這樣的環境下，後臺系統的複雜度也會被誇大，畢竟是我們做的第一款產品，畢竟接觸後臺產品的朋友要遠遠的多過面向用戶的產品。

實際上，確實存在極為複雜的後臺產品，複雜度遠遠超過了面向用戶的產品，尤其是牽扯到算法層面的後臺產品，不是專業後臺產品經理幾乎無法駕馭——這樣的後臺產品是極為少數，極為特殊的。

面向用戶的產品，也存在極為複雜的邏輯，我們不能因此就斷定面向用戶的產品比後臺產品難，也不能盲目的斷定後臺產品比面向用戶的產品複雜，這兩類產品都具備難度等級。

現在的環境，對於產品而言，更多的是應用創新階段。高複雜度的產品，其實很少人能接觸到，實在不足以讓我們斷言後臺更複雜，幾乎80%以上的後臺產品都是很簡單的。

這就好比三人成虎，人們都在說後臺複雜，我們也就先入為主的認為後臺更難，深入一點，到底哪里難了呢？卻很難說出一二。

如果你是一位2年經驗以內的產品，而這時，你又需要設計一款後臺產品，無需緊張，按需設計就可以了。

你所接到的任務本身是存在風險規避因素的，這話可能不中聽，但我們很難將極為複雜的任務交給經驗尚且不足的你，這無疑將會放大我們的風險，而這種風險是我們原本可以避免的。

如果你是一位產品新人，你也正在接觸後臺，那就潛心去研究吧。

我特別樂意將後臺任務交給新人，因為他更加的固定，後臺產品的變化很少，是有跡可循的，他不像面向用戶的產品，有很多變術，而每一個變術都藏著天使與惡魔，將會給我們造成實實在在的傷害。

當然，最重要的，任然是這個觀點：企業和我們的上級在做任務分配時，必然會考慮風險因素，考慮失敗或者犯錯的成本是否在我們可接受的範圍。因此，無需有太大的心理壓力及負擔。

後臺設計的原則

多數後臺都會遵守以下四個原則，實際上這是後臺的基礎設計原則。我將其定義為可視化原則、數據源原則、控制性原則以及內部設置原則。

其中，最重要的是前三個原則。

可視化原則

典型的可視化原則便是後臺產品里的數據統計部分，我們可以將其理解成一種暴露信息的機制。

產品在運營過程中，必然會產生若幹信息，但這些信息往往是我們看不見的，或者每一次的查看都需要研發進行支持的，為了方便我們的查看，就將這部分內容在後臺里展示出來。

可視化原則的典型特征是只允許查看，各種維度的查看，但本身不具備更多的操作性質。

想想看，在我們接觸到的後臺產品里，都有哪些功能是屬於可視化原則的。

數據統計部分、數據明細部分、用戶列表、內容列表幾乎都是屬於可視化原則的。

這部分功能的設計方法，只需要我們去考慮哪些信息是我們需要看的，又以何種維度進行查看就可以了。

我們上線一款活動，便需要在後臺查看該活動的一些信息。諸如報名人數、實際參與人數、甚至於時長；當然，我們還可以把參與人員的地理分布統計出來，還有性別分別、年齡分布。

遵循可視化原則常見的功能，包括我們的多維度篩選、排序、導出、數據明細、餅狀圖、柱形圖、折線圖等等。這些功能都符合可視化設計原則，用最合適的方法，提高我們查看信息的效率。

數據源原則

幾乎所有的後臺系統都會扮演著數據源的角色。

我們要在面向用戶的產品里投放一個活動、放一個新的banner圖、推薦一篇文章、推薦一個專題，都需要有一個錄入信息的地方。而在後臺里，符合數據源原則的部分便承擔了這部分內容。

數據源原則的典型特征在於新增。除了常規的查看的能力，數據源部分必然包含新增功能，我們可以斷言，不具備新增功能的後臺，便不符合數據源原則。

這表示該產品幾乎不具備可運營能力，運營同學也無法通過後臺對產品的內容，風向，活躍度進行幹預。

以微信公眾號的後臺管理系統而言，我們新增的圖文素材，新建的推送任務便是屬於數據源設計原則的功能，可以將既定的信息主動的插入到面向用戶的產品里。

這部分功能的設計主要是與面向用戶的產品進行搭配，是一種配合形式的設計，後者需要預留支撐空間才行，諸如預留banner位，預留推薦標簽，預留PGC的內容規則。

簡單而言，數據源原則便是要求我們後臺要具備“生產新內容”的能力。產品運營過程中，要具備能夠生成新的主題，新的活動，新的通知能力。

他是與面向用戶的產品進行配合而存在的一種後臺設計原則。

版本更新通知，也是屬於數據源原則的功能設計。

當我們更新了一個新版本時，需要通知用戶更新；此時，我們就需要新建一個版本通知。

在該模塊里，填寫通知的內容，通常都是對新版本的簡單介紹，在設定好通知對象，諸如1.x版本及之前的版本；我們還可以設置通知的形式，比如是強制性升級還是可取消的升級通知。

數據源原則的功能，難點在於參數的選擇——我們要盡可能多的讓運營同學在新建內容時，有更多的參數可以選擇填寫，這樣才能滿足他的靈活性， 畢竟這部分能力是官方向用戶發出聲音的能力。

來看看公眾號新建一篇圖文素材包含了那些參數：

可以試想一下，假如公眾號能允許我們在新建圖文素材時，增加小遊戲的引用，公眾號的玩法就會發生截然不同的變化，當然這需要面向用戶的產品做出許多的支撐才行。

控制性原則

控制性原則是指後臺操作人員能夠對用戶的部分信息進行修改。

是一種保護機制也是一種應急機制，當用戶發出了不好的內容時，我們能夠有所作為，而不是只能看著。

在保護內容生態的同時，當用戶執行了某些不可逆操作時，我們也需要有應急能力，來為用戶修改某些信息。

在一些小的產品里，甚至能夠直接修改用戶的賬戶或金幣余額，尤其是一些遊戲產品，這是為了更方面的打造“托”或者“特權賬戶”。

典型的控制性原則體現在黑名單、內容屏蔽、內容修改這三個功能。

同樣是以微信公眾號為例，我們可以在公眾號後臺設置黑名單，那這部分用戶將不能再向公眾號發信息，也不能發留言了。我們還可以將已經發布的文章刪除掉，這樣，這篇文章就無法再被查看了。

控制性原則的設計理念，在於保護和應急機制。

通常來講，這兩種機制的功能包含屏蔽、黑名單、刪除、修改，我們需要識別出面向用戶的產品里，哪些內容是需要被保護的，哪些內容是需要建立應急機制的。

盡管，控制性的功能是不常使用的功能。

實際上，我們並不希望這些功能被使用，但這些功能是必須存在的，當我們需要使用這些功能時，就表示出現了異常的狀況。此時，這些功能就變得非常的需要了。

內部設置原則

如果說，可視化原則的設計對象是我們看不見的信息，數據源原則的設計對象是新建內容，控制性原則的設計對象是用戶及用戶生產的內容，那麽內部設置原則的設計對象則是後臺系統本身。

最常見的內部設置原則是我們的權限系統，他與面向用戶的產品毫無關系。這部分功能的設計對象僅僅是明確操作者的權限範圍，同類型的功能還包括操作記錄等。

當然，後臺的賬號系統也是屬於內部設置原則。

後臺的賬號是無法被申請，被註冊的，這部分賬號的來源往往是管理員賬號生成的。一方面在設計系統時存在一個固定的超級管理員賬號，通常是admin賬號，這個賬號可以生成其他的子賬號，並為之賦予不同的權限。

企業郵箱是典型的案例，當我們入職一家較為成熟的企業時，都會按照我們的姓名或者工號生成一個獨立的企業郵箱賬號。

內部設置原則更多的是服務於後臺產品本身的功能，他和用戶，和我們面向用戶的產品沒有任何關系。

結尾

真正複雜的後臺系統非常稀少，在我們接觸後臺系統時，不需要太過緊張，也不需要太過恐慌，可以參照以上四個原則進行設計。

這四個原則是後臺設計的基礎原則，複雜的後臺系統也同樣是建立在對基礎的升級或者變化應用上，並不是全新的。

文章評論

匿名用戶

發布

全部評論：10

發布

後台明報出左事，入唔到想改改

4樓提及

---

okok

8樓提及

---

好似未得

後台默默做背後女人安仔攬Sammi完騷晒恩愛

豪裝後台鋪地毯

《長城》預告片出鏡多過麥迪文景甜後台勁　新片《金剛》拍貝兒

星二代後台集郵

國策透視：妖精都要講後台

送禮勤知唔知？邊個留低個獎喺後台