編輯導語：B端系統邏輯非常複雜，且随着數據的叠代、功能的增加，原來的系統漸漸不再适用，因此則需要進行更新優化。本篇文章中作者轉換思路，從新角度分析如何對數據生産後台體驗進行優化，一起來看看吧。

一、項目背景

我們給用戶提供的是一款專業資料查詢閱讀的 App，用戶最看重的是資料覆蓋是否全面，内容是否嚴謹。這就辛苦了公司的數據生産團隊，必須非常及時和高效率地拿到一手原始資料，進行翻譯編輯校對等工作後發布給用戶閱讀。

為了保證效率和質量，公司自行開發數據生産後台，數據團隊成員在此協作數據生産。具體邏輯如下圖所示：

• 主編是最高權限角色。負責創建數據生産任務，并且對最終生産的數據質量進行把關後發布給用戶。
• 編輯負責領取數據生産中的編輯任務，完成任務後提交給審核。
• 審核對編輯生産的數據進行校對，如果不符合可打回編輯修改，符合數據可提交給主編進行終審。

随着數據生産後台的叠代，功能越來越多。原來的頁面框架已經承載不了，因此我決定重新梳理，系統優化體驗。

二、找到重點

B 端系統邏輯很複雜，為了能系統的優化體驗，我試圖用某對象有若幹屬性，屬性有不同的狀态。狀态不同操作不同，不同操作有不同的權限這個框架來梳理。

這個框架梳理到接近完成時我放棄了。僅僅是鳥瞰全局就花了很多時間，如果再接着梳理細節，還不知道要花多久才能正式開始設計。

于是我轉換思路，評估不同頁面的體驗問題嚴重程度，從難到易逐個擊破。評估的方法用某個頁面哪個角色執行哪些任務，任務頻次、重要程度如何。

根據評估結果，顯然「條目編輯頁」和「工作台頁」是最應該優化的。

三、梳理任務

下圖就是「條目編輯頁」的老版本界面。根據不同的角色功能略有不同，但總體來說都是用戶依次切換條目，并根據每個條目提供的參考資料等對内容進行編輯或審核。

别急着馬上找頁面上明顯的問題，為了徹底消滅體驗問題，首先應該梳理不同角色在頁面上做的操作。

如下圖所示，編輯角色選擇未編輯的條目查看任務說明後編輯内容和設置參考文獻，之後保存草稿表示完成該條，接着繼續選擇未編輯的條目進行操作，直到所有條目完成後提交子任務。

審核和主編角色的審核流程基本一緻，區别在于主編能自由打回到前面環節的任一角色。審核和主編在選擇待審核條目後，查看内容和任務說明，對于不合格的條目能自行編輯或者填寫審核意見，待子任務全部處理完成後提交。

如果審核和主編在首次審核提交後有不合格的條目，那編輯得再次修改提交，審核和主編也要再次審核。和首次區别在于需要查看或者撰寫審核/申訴意見。

根據以上流程圖，将角色和核心任務抽象後，可以簡化為 5 個步驟（選擇子任務在前一個頁面完成，不算在内），如下圖所示。

如果把步驟放在頁面上，除了左側主菜單占用太大面積，整個操作動線依次從上到下從左到右似乎沒什麼問題，但真是如此嗎？

四、确定問題

我們之所以用電腦而不是手機來做數據生産管理系統，是因為在電腦上有更大的屏幕來呈現内容，鍵盤鼠标精準快捷地操作也能提高效率。如果我們仔細分析每個步驟用戶的需求，就發現并沒有合理地利用電腦大屏幕的優勢。

對于步驟 1 選擇待處理條目而言，因為用戶要處理完所有條目後才能提交，因此最好能一目了然的知道哪些條目需要處理，哪些不需要。可以非常方便地選擇待處理的條目，用列表呈現更好。

對于步驟 2 查看附屬内容，絕大多數都是在對條目主體内容進行編輯之前查看，處理過程中偶爾需要打開看一眼。因此不需要一直展現占據空間。應該提供隐藏，這樣能給真正需要展示大量信息的步驟 3 處理主體内容留出更多空間。

五、優化方案

經過以上分析，最終得到「條目編輯頁」的優化方案。

1. 去掉全局導航，提供返回工作台按鈕。給用戶長時間處理條目的沉浸環境，也給真正需要展示的内容留出更多空間。
2. 提供工具欄。不同的角色有不同的操作，後續可能會增加其他操作。彈性的工具欄區域可以滿足以後的擴展。
3. 條目改為列表。顯示每個條目的狀态，幫助用戶一覽全局，快速選擇應該操作的條目。
4. 附屬内容可顯示或隐藏。将更多空間留給主體内容。

優化後的「條目編輯頁」與 Keynote 的界面神似，我在設計前并沒有想到去參考辦公軟件。

隻能說制作幻燈片的步驟抽象後和條目編輯的步驟幾乎一緻。另外如今的網頁早已不是純粹展示信息的地方，随着前端技術發展，大多數 SaaS 其實和本地軟件的交互、功能一樣複雜。所以網頁和本地軟件的邊界也越來越模糊。

「工作台」的優化相對來說更簡單。根據産品規劃，很長時間内我們都不會增加新的大模塊。左側導航優勢是利于擴展，但占用的面積過大。改成頂部導航後，留給主任務與子任務列表的空間更大，利于各種角色監視任務進度，或者選擇某個任務去執行。

六、結果反饋

該優化上線之後得到了數據生産團隊的誇獎，并且上線之後一年功能叠代沒有調整整體框架，說明我指定的框架擴展性不錯。

在經曆這個項目之前，我好久沒有做 B 端産品的設計。為了鍛煉我的 B 端設計技能，我特地沒有去網上看相關的設計經驗文章，或者找競品分析。學習别人的思路和方案難免也被别人的框架給固化。要知道不是每次都有競品可以分析，總會湧現出新的平台和産品類型，有能力應對新平台沒有競品的情況，才是真正厲害的設計師。

通過這個項目我掌握了不同角色的任務分析，用戶任務的抽象，根據步驟的需求和内容類型決定模塊的大小和控件。相信這些技能以後也可以複用在其他新型 B 端産品的設計。

作者：龍爪槐守望者，龍爪槐守望者

本文由 @龍爪槐守望者 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議

,

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

查看全部