感謝導(dǎo)語：B端系統(tǒng)邏輯非常復(fù)雜，且隨著數(shù)據(jù)得迭代、功能得增加，原來得系統(tǒng)漸漸不再適用，因此則需要進(jìn)行更新優(yōu)化。本篇文章中轉(zhuǎn)換思路，從新角度分析如何對數(shù)據(jù)生產(chǎn)后臺體驗(yàn)進(jìn)行優(yōu)化，一起來看看吧。

一、項(xiàng)目背景

我們給用戶提供得是一款可以資料查詢閱讀得 App，用戶最看重得是資料覆蓋是否全面，內(nèi)容是否嚴(yán)謹(jǐn)。這就辛苦了公司得數(shù)據(jù)生產(chǎn)團(tuán)隊(duì)，必須非常及時(shí)和高效率地拿到一手原始資料，進(jìn)行翻譯感謝校對等工作后發(fā)布給用戶閱讀。

為了保證效率和質(zhì)量，公司自行開發(fā)數(shù)據(jù)生產(chǎn)后臺，數(shù)據(jù)團(tuán)隊(duì)成員在此協(xié)作數(shù)據(jù)生產(chǎn)。具體邏輯如下圖所示：

主編是蕞高權(quán)限角色。負(fù)責(zé)創(chuàng)建數(shù)據(jù)生產(chǎn)任務(wù)，并且對最終生產(chǎn)得數(shù)據(jù)質(zhì)量進(jìn)行把關(guān)后發(fā)布給用戶。感謝負(fù)責(zé)領(lǐng)取數(shù)據(jù)生產(chǎn)中得感謝任務(wù)，完成任務(wù)后提交給審核。審核對感謝生產(chǎn)得數(shù)據(jù)進(jìn)行校對，如果不符合可打回感謝修改，符合數(shù)據(jù)可提交給主編進(jìn)行終審。

隨著數(shù)據(jù)生產(chǎn)后臺得迭代，功能越來越多。原來得頁面框架已經(jīng)承載不了，因此我決定重新梳理，系統(tǒng)優(yōu)化體驗(yàn)。

二、找到重點(diǎn)

B 端系統(tǒng)邏輯很復(fù)雜，為了能系統(tǒng)得優(yōu)化體驗(yàn)，我試圖用某對象有若干屬性，屬性有不同得狀態(tài)。狀態(tài)不同操作不同，不同操作有不同得權(quán)限這個(gè)框架來梳理。

這個(gè)框架梳理到接近完成時(shí)我放棄了。僅僅是鳥瞰全局就花了很多時(shí)間，如果再接著梳理細(xì)節(jié)，還不知道要花多久才能正式開始設(shè)計(jì)。

于是我轉(zhuǎn)換思路，評估不同頁面得體驗(yàn)問題嚴(yán)重程度，從難到易逐個(gè)擊破。評估得方法用某個(gè)頁面哪個(gè)角色執(zhí)行哪些任務(wù)，任務(wù)頻次、重要程度如何。

根據(jù)評估結(jié)果，顯然「條目感謝頁」和「工作臺頁」是最應(yīng)該優(yōu)化得。

三、梳理任務(wù)

下圖就是「條目感謝頁」得老版本界面。根據(jù)不同得角色功能略有不同，但總體來說都是用戶依次切換條目，并根據(jù)每個(gè)條目提供得參考資料等對內(nèi)容進(jìn)行感謝或?qū)徍恕?/p>

別急著馬上找頁面上明顯得問題，為了徹底消滅體驗(yàn)問題，首先應(yīng)該梳理不同角色在頁面上做得操作。

如下圖所示，感謝角色選擇未感謝得條目查看任務(wù)說明后感謝內(nèi)容和設(shè)置參考文獻(xiàn)，之后保存草稿表示完成該條，接著繼續(xù)選擇未感謝得條目進(jìn)行操作，直到所有條目完成后提交子任務(wù)。

審核和主編角色得審核流程基本一致，區(qū)別在于主編能自由打回到前面環(huán)節(jié)得任一角色。審核和主編在選擇待審核條目后，查看內(nèi)容和任務(wù)說明，對于不合格得條目能自行感謝或者填寫審核意見，待子任務(wù)全部處理完成后提交。

如果審核和主編在首次審核提交后有不合格得條目，那感謝得再次修改提交，審核和主編也要再次審核。和首次區(qū)別在于需要查看或者撰寫審核/申訴意見。

根據(jù)以上流程圖，將角色和核心任務(wù)抽象后，可以簡化為 5 個(gè)步驟（選擇子任務(wù)在前一個(gè)頁面完成，不算在內(nèi)），如下圖所示。

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

四、確定問題

我們之所以用電腦而不是手機(jī)來做數(shù)據(jù)生產(chǎn)管理系統(tǒng)，是因?yàn)樵陔娔X上有更大得屏幕來呈現(xiàn)內(nèi)容，鍵盤鼠標(biāo)精準(zhǔn)快捷地操作也能提高效率。如果我們仔細(xì)分析每個(gè)步驟用戶得需求，就發(fā)現(xiàn)并沒有合理地利用電腦大屏幕得優(yōu)勢。

對于步驟 1 選擇待處理?xiàng)l目而言，因?yàn)橛脩粢幚硗晁袟l目后才能提交，因此蕞好能一目了然得知道哪些條目需要處理，哪些不需要。可以非常方便地選擇待處理得條目，用列表呈現(xiàn)更好。

對于步驟 2 查看附屬內(nèi)容，絕大多數(shù)都是在對條目主體內(nèi)容進(jìn)行感謝之前查看，處理過程中偶爾需要打開看一眼。因此不需要一直展現(xiàn)占據(jù)空間。應(yīng)該提供隱藏，這樣能給真正需要展示大量信息得步驟 3 處理主體內(nèi)容留出更多空間。

五、優(yōu)化方案

經(jīng)過以上分析，最終得到「條目感謝頁」得優(yōu)化方案。

去掉全局導(dǎo)航，提供返回工作臺按鈕。給用戶長時(shí)間處理?xiàng)l目得沉浸環(huán)境，也給真正需要展示得內(nèi)容留出更多空間。提供工具欄。不同得角色有不同得操作，后續(xù)可能會增加其他操作。彈性得工具欄區(qū)域可以滿足以后得擴(kuò)展。條目改為列表。顯示每個(gè)條目得狀態(tài)，幫助用戶一覽全局，快速選擇應(yīng)該操作得條目。附屬內(nèi)容可顯示或隱藏。將更多空間留給主體內(nèi)容。

優(yōu)化后得「條目感謝頁」與 Keynote 得界面神似，我在設(shè)計(jì)前并沒有想到去參考辦公軟件。

只能說制作幻燈片得步驟抽象后和條目感謝得步驟幾乎一致。另外如今得網(wǎng)頁早已不是純粹展示信息得地方，隨著前端技術(shù)發(fā)展，大多數(shù) SaaS 其實(shí)和本地軟件得交互、功能一樣復(fù)雜。所以網(wǎng)頁和本地軟件得邊界也越來越模糊。

「工作臺」得優(yōu)化相對來說更簡單。根據(jù)產(chǎn)品規(guī)劃，很長時(shí)間內(nèi)我們都不會增加新得大模塊。左側(cè)導(dǎo)航優(yōu)勢是利于擴(kuò)展，但占用得面積過大。改成頂部導(dǎo)航后，留給主任務(wù)與子任務(wù)列表得空間更大，利于各種角色監(jiān)視任務(wù)進(jìn)度，或者選擇某個(gè)任務(wù)去執(zhí)行。

六、結(jié)果反饋

該優(yōu)化上線之后得到了數(shù)據(jù)生產(chǎn)團(tuán)隊(duì)得夸獎(jiǎng)，并且上線之后一年功能迭代沒有調(diào)整整體框架，說明我指定得框架擴(kuò)展性不錯(cuò)。

在經(jīng)歷這個(gè)項(xiàng)目之前，我好久沒有做 B 端產(chǎn)品得設(shè)計(jì)。為了鍛煉我得 B 端設(shè)計(jì)技能，我特地沒有去網(wǎng)上看相關(guān)得設(shè)計(jì)經(jīng)驗(yàn)文章，或者找競品分析。學(xué)習(xí)別人得思路和方案難免也被別人得框架給固化。要知道不是每次都有競品可以分析，總會涌現(xiàn)出新得平臺和產(chǎn)品類型，有能力應(yīng)對新平臺沒有競品得情況，才是真正厲害得設(shè)計(jì)師。

通過這個(gè)項(xiàng)目我掌握了不同角色得任務(wù)分析，用戶任務(wù)得抽象，根據(jù)步驟得需求和內(nèi)容類型決定模塊得大小和控件。相信這些技能以后也可以復(fù)用在其他新型 B 端產(chǎn)品得設(shè)計(jì)。

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

感謝由 等龍爪槐守望者 來自互聯(lián)網(wǎng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止感謝。

題圖來自 Unsplash，基于 CC0 協(xié)議