從 0 開始搭建一套後臺管理系統，成本巨大，所以都會選擇一套成熟的元件庫，基於此，再堆疊業務邏輯。我們公司的元件庫基於 Ant Design。Ant Design 包含一套完整的後臺解決方案，不僅提供了 75 個元件，還開源了整套設計方案，配色、字型、圖示、佈局等，還分享了眾多的使用者體驗案例。官方基於 Ant Design 中的元件，還提供了一套開箱即用的中臺前端/設計解決方案：Ant Design Pro，更貼近於頁面研發，縮短開發時間。本文的很多最佳化思想，都來源於這兩套開源庫，不過也增加了很多自己的理解。
一、站在巨人的肩膀上
在將系統呈現給使用者之前，有必要用專業的眼光來為系統做一次初步的最佳化。下圖是基於上述 2 個庫整理的一張思維導圖，包含了一個管理後臺常用的幾個部分，完善這幾部分，可以讓使用者在使用系統時有較好的體驗，像圖表視覺化之類較為特殊的模組並沒有列出。
1）基礎結構
管理後臺的全域性結構比較固定，包括側邊頂部的 Logo、側邊選單、頂部選單、麵包屑導航。
側邊選單可以隱藏，若要有更好的體驗，還可以將寬度變為可自定義，例如左右拖動修改寬度。後臺使用者的頁面許可權也會集中到側邊欄，有許可權的展示，無許可權的隱藏。
在頂部選單中，不僅僅可以用於導航（修改資料、登出等），還可以增加快捷的檢索按鈕，例如輸入使用者 ID，得到一個彈框，展示使用者詳情，包括基礎資料、訂單、操作記錄、相簿、裝置等，將這些資訊聚合在一起，便於查詢。
當一個頁面中有比較多的內容時，可以用標籤頁來分離，一個標籤對應一個子頁面。
回到頂部，在比較長的頁面中比較實用，這個按鈕也應該是管理系統不可獲取的一個組成部分。
2）反饋
當使用者和系統需要互動時，就得為使用者在各個階段提供必要、積極、即時的反饋。但同時要避免過度反饋，以免給使用者帶來不必要的打擾，對於能夠及時看到效果的簡單操作，可以省略反饋提示，下面是一組反饋示例。
常見的結果反饋可以分為兩種：頂部全域性提示和對話方塊提示（上圖所示）。頂部全域性提示就是 Toast，比較輕度，過幾秒後會自動隱藏。而對話方塊提示就比較重，會終止使用者操作，用於傳遞非常重要的資訊。
表單的操作過程中可透過不同的校驗規則給使用者提供表單校驗提示（上圖所示），讓他們及時的糾正錯誤。在表單中，對於比較複雜的欄位，可以用氣泡卡片的方式提供補充說明（下圖所示）。
互動的操作過程中儘可能將狀態反饋給使用者，即時的響應會給使用者增加信賴感。在操作需要較長時間才能完成時，顯示該操作的當前進度和狀態。若載入時間較長，應提供取消操作。
當目標元素的操作需要使用者進一步的確認時，可以透過氣泡確認框在目標元素附近彈出浮層提示，以此來詢問使用者，常見於資料列表操作一列中的按鈕。
3）資料列表
資料列表在整個管理系統中佔比非常重，其結構也比較固定，最上邊是資料過濾（即查詢條件），然後是資料統計（可選項），再有是資料列表（即表格區域），其中還包含列表工具欄（新建、重新整理、排序等功能），後面是分頁欄（圖中沒有畫出），最後是批次操作。
在 Ant Design Pro 中有專門的元件實現查詢條件，內建查詢和重置兩個按鈕，當條件比較多時，還能自動隱藏。在下圖中，就能看到列表工具欄（貼在表格上邊），提供的是批次匯入、匯出資料、建立應用等，這些按鈕都可自定義。由於列表的欄位較多，還提供了左右滾動，並且第一列和最後一列固定。批次操作是固定在頁面底部的，並且會顯示選中的數量。
在列表的載入過程中，可以提供骨架屏過渡，載入完成後，顯示資料。當沒有資料時，要提供空狀態佔位，而不是空白一片。
資料載入完成後，在懸停時，可以為當前那一行增加底色辨識。
文字鏈的點選範圍受到文字長短影響，可以設定整個單元格為熱區，以便使用者觸發。
分頁器可以讓使用者清楚的知道自己所要瀏覽的內容有多少、已經瀏覽了多少、還剩餘多少。當資訊條目較多的時候，可以允許使用者自定義每頁的行數，以提高使用者檢視和檢索資訊的效率和靈活性，常與表格、卡片搭配使用。下圖展示了分頁器的各個部分，以及常用的功能。
上述是比較常見的資料列表，還有幾類比較特殊的資料列表。第一種是行內可編輯的表格，點選操作列的編輯後，只讀的列變為可操作的控制元件，比較快捷的編輯方式，適合欄位較少的列表。圖中最下面的新增一行資料，是一種的特殊的複製按鈕。
第二種是可拖動排序的表格，將滑鼠左鍵按住第一行的 icon，然後就能拖動這一行了。
第三種是卡片列表，展現形式與常規列表較為不同。在卡片中，可以根據業務側重元素，例如提供放大影像的功能。
4）表單
表單也是後臺系統中不可分割的一部分，現在很多時候不是單獨的頁面，而是資料列表的一部分。例如點選列表中的某個欄位出現浮層表單，浮層的形式可分兩種：彈框（Modal）和抽屜（Drawer），彈框適合欄位較少的表單，如下所示。
由於抽屜提供的空間比較多，因此能包含更多的欄位，如下所示。
除了浮層表單之外，對於較為複雜的表單，可以使用分步表單。將使用者需要填寫和確認的資訊按照線性流程組織，利用步驟條告知使用者完整的流程和進度，常常在最後提交前讓使用者再次確認資訊，並在流程結束後給與明確的結果反饋。
登入表單是一種比較特殊的表單，獨立於系統的基礎佈局結構。一般都會簡單點，只提供使用者名稱和密碼登入，省略簡訊登入。
常用的表單控制元件包括輸入框、單選框、多選框、下拉框等，這類都比較簡單，複雜的有上傳、資料聯動和複製等。檔案上傳可以用比較簡單的展現形式，如下所示。
而影像上傳因為需要預覽，所以得提供一塊預覽區域，常見的就是將按鈕區域放大。
還有一種拖動上傳，為了更好的體驗，在上傳的過程中，還需要實時更新進度條。
5）按鈕
按鈕雖然是一個小元素，但是它遍佈整個系統，哪都有它。對於按鈕，目前也有了一套成熟的設計規範，主要體現在樣式和互動兩方面。在下圖中，1 是次按鈕，2 是主按鈕，3 是文字按鈕，4 是圖示按鈕，5 是在按鈕中新增圖示。
主按鈕是主色填充，表示高強調，其餘按鈕的強調級別依次降低。
紅色用於警示使用者該操作存在風險，通常刪除按鈕會被賦予紅色。
在移動到按鈕位置時，需要有個聚焦效果，例如高亮。在點選按鈕時，需要有個過渡效果，例如增加陰影，確認點選成功。在通訊時，可以有個載入效果。
6）其它
響應式是為了讓後臺可以支援移動裝置的訪問，在沒有電腦的戶外情況下，也能瀏覽後臺，操作管理。
暗黑模式是一種體驗最佳化，比較適合夜晚辦公，也比較符合程式設計師的審美。在公司內部上線後，很快得到了業務方的肯定，還督促產品完善客戶端的夜間模式。
異常頁面也是後臺系統不可缺少的一部分，許可權不足提示 403，頁面不存在提示 404，伺服器錯誤提示 500 等。透過異常頁，可以解釋發生了什麼異常，為使用者提供相應的建議或操作，避免使用者感到迷失和困惑。
二、緊貼業務
雖然開源庫已經掃清了許多的體驗障礙，但是在實際業務中，還是會出現各類問題，集中體現在流程、功能、效能等方面。例如流程過於繁瑣，需要簡化；功能太少，需要補充；頁面太卡，難以操作等。不過在最佳化體驗之前，需要保證業務進度不受影響，換句話說，就是要有空閒的人力資源去做體驗最佳化這個工作。
1）解放生產力
解放生產力就是為了讓更多的人能參與到最佳化的工作中。我們團隊之前在開發管理後臺時，會先找一張類似的，然後複製一份，修改檔名稱，在此基礎上做改動。既然能複製，那就說明有很多共通之處，在整理 200 多張頁面後發現，幾種常規的佈局大概佔總頁面數的 80% 以上，只有很小一部分的頁面需要專門定製，那麼接下來就是抽象出常規佈局中所包含的元件。
模板元件呼之欲出，經過一週多時間的除錯，在組內開始推廣。在開發這套元件的時候，預留了許多回撥，可根據不同場景做自定義的邏輯。在模板元件上線後，就將頁面的開發從3天降低至1天以內，有些簡單頁面兩三個小時就能佈局完成。後續在瀏覽 Ant Design Pro 的元件庫時，發現我的模板元件與這些元件類似，但是功能更為的豐富完善，能夠適應更多複雜的場景。
這是一次非常典型的降本提效的經歷，除此之外，我們還在研發各類工具，讓各種業務走視覺化的配置，不用再單獨研發。例如一個將榜單活動配置化的工具，就是將常用的活動做成視覺化配置的形式，目的是減少開發和測試人力，將 2 天的研發時間壓縮至 2 小時。這個配置協調了 UI 組、產品組、測試組、前端組、資料組一起，制訂出了相關規範，已成功運營了幾十場活動。
給我們組自己減負，也是一個目標，那麼也需要開發許多趁手的工具。例如設計BFF 平臺，在研發完成後的一段時間才開始推廣，我們組比較慢熱，有段時間，新的業務介面基本都會走此平臺，線上已有 70 多個介面在穩定執行著。
為了提升管理後臺的開發效率，先後研發了後臺頁面視覺化編輯器（即低程式碼）第一版和第二版，第一版組員接受度並不理想，第二版已經上線了 2 個選單。不過，在使用體驗上並不理想，後續還需要迭代完善，才能真正使用。
當然，解放生產力和體驗最佳化大部分情況下是並行進行的，在進行一段時間後，獲取的收益將會非常高。
2）發現問題
接下來談談發現問題，像流程、功能、效能等問題都是在深度使用後臺系統後，才能遇到，因此想要發現這類問題，需要與相關人員交流。有條件的話，可以進行一對一的交流，提前通知後，讓他們準備下。因為是給他們解決實際問題，所以一般情況下，他們都會積極配合。當時一下子收到了幾十個問題反饋，經過整理後，修復比較容易實現的問題，諸如換個字型顏色、加個篩選條件、增加一列等。果斷上線後，效果非常好，對你來說是一個小改動，但對業務方來說，卻是實打實的提升工作倖福感。
另外一個發現問題的方法是發放滿意度問卷，相比上一個方法，受眾面更廣，成本更低。畢竟一對一是要抽出雙方時間的，不能頻繁使用。但相對來說，一對一耳聞目染的效果肯定是最好的。如果收到的是高質量的問卷，那麼收穫也是滿滿的。
問卷的題目形式包括單選和問答，不要包含太多的專業術語，通俗描述，答案也不一定要用標準的五級量表（非常滿意、滿意、一般、不滿意、非常不滿意），可以更具象地去描述答案，方便使用者選擇。例如：
- 對XX頁面不太滿意的原因是什麼？
- 開發人員誤解了需求
- 專案延期
- BUG太多不能用
- 其他
當選擇其他時，可以提供文字框，輸入具體原因。
除了在這類正式場景中獲取問題之外，在日常時刻，其實也可以發掘，例如聽到有人在抱怨 XX 功能太難用時，就可以去搭話了、某人在群聊中提到某功能有異常時等等。
有些體驗問題也可以自己去發掘，例如某個資料列表中的欄位由於太多，導致位置變形了，那麼你可以主動去增加左右捲軸。篩選條件太少，就增加幾個。日常也可以去觀察其他開源管理系統的功能，考慮是否可以增加到自己的系統中，提升體驗，響應式和暗黑模式就是在瀏覽其他系統時得到的靈感。
3）解決問題
解決問題的核心本質就是資源成本是否能負擔的起。某些比較重要的體驗問題，尤其是需要多端協調的，可以將其加到版本迭代中，這樣既能引起重視，也能安排一個固定時間分出資源來解決。
不過大部分時候，體驗最佳化上不了檯面，提不上日程，優先順序比其他需求要低很多。但好在管理後臺大部分是由我們全棧管理著，最佳化工作可以由我們自己承擔，不需要找人協作，可控性比較大。可以將那些最佳化見縫插針，逐個擊破。
有些最佳化難以徹底解決，只能在已有條件下做到最好。例如後臺有個稽核內容的功能，可以一次性提交 200 條記錄，在提交後，服務端會序列的做一系列的邏輯處理，那麼不可避免的就會讓介面響應會變慢。雖然在介面中，已經做了資料庫表的索引，以及儘可能的與資料庫少互動，包括一次性從資料庫中讀取多條記錄，將資料快取到 Redis 中等，但是再要最佳化，就得改變技術架構，成本會比較大，只能與業務方協商，暫時互相妥協。一般來說，隨著業務的迭代，架構也是要跟著調整的，但受限於各種客觀條件，有時候不得不擱置。
各個公司的業務都會有所不同，遇到的業務最佳化問題也會大相徑庭，並沒有銀彈，得根據實際情況分析，在現有資源的前提下，找到最優解（佔用的資源最少，得到的效果大家都能認可），這是一個平衡的過程，需要多多嘗試。