產(chǎn)品心得|用講故事的方式設(shè)計管理后臺

5 評論 12387 瀏覽 142 收藏 9 分鐘

設(shè)計管理后臺時,對功能模塊的劃分和頁面的邏輯設(shè)計要求都非常高,一定不可以僅僅是簡單的模塊疊加。本文主要安利一種叫做OMS設(shè)計,來按用戶故事設(shè)計思路來設(shè)計用戶的使用場景。

B端產(chǎn)品是C端產(chǎn)品的根基,B端產(chǎn)品更貼近業(yè)務(wù),只有深入了解并熟悉業(yè)務(wù)的產(chǎn)品經(jīng)理才能做好B端產(chǎn)品。

本文安利一種好的設(shè)計方式,叫做OMS設(shè)計。

OMS設(shè)計是按用戶故事設(shè)計思路來設(shè)計用戶的使用場景,通常來講用戶故事,包括時間、人物、地點、事件。通俗講,管理系統(tǒng)需要做的事情,就是對確定的時間、確定的用戶、在確定的場景執(zhí)行確定的事件,或?qū)λ麄冞M(jìn)行管理。

管理后臺類產(chǎn)品,核心就是解決一個問題:“某時間某人使用某物做了某事“。

如圖所示:管理后臺的核心三要素:人、物、事。

人:權(quán)限管理(包括:角色設(shè)置、操作權(quán)限、數(shù)據(jù)權(quán)限)

人的管理和設(shè)計,主要解決這一問題:事件對誰觸發(fā)?是對所有用戶,特定的用戶?

能解決這個問題的方式就是權(quán)限管理,在講解權(quán)限管理之前,我們首先普及一個概念:

RBAC(Role-Based Access Control)即基于角色的訪問控制,是一種權(quán)限設(shè)計思想。在 RBAC 中,權(quán)限與角色相關(guān)聯(lián),用戶通過成為適當(dāng)角色的成員來獲得這些角色的權(quán)限。相較傳統(tǒng)的訪問控制(自主訪問、強制訪問)來說,RBAC 能更好的支持最小權(quán)限、責(zé)任分離和數(shù)據(jù)抽象等原則,極大地簡化了權(quán)限的管理。

  • 角色設(shè)置:如管理員、普通操作人員、游客等,是區(qū)分不同身份操作管理后臺的能力。通常管理員具有最高權(quán)限,能獲得所有操作,甚至是刪除成員;
  • 操作權(quán)限:基本包括增、刪、改、查四類。角色權(quán)限直接影響操作權(quán)限,不同角色具備不同的操作權(quán)限;
  • 數(shù)據(jù)權(quán)限:一般分為公共庫數(shù)據(jù)和私有數(shù)據(jù)(特指需要限制的數(shù)據(jù),如部分內(nèi)容不能全局可查看);

物:事務(wù)管理(業(yè)務(wù)流程圖、任務(wù)流程流、原型設(shè)計圖)

業(yè)務(wù)流程圖:是一種描述系統(tǒng)內(nèi)各單位、人員之間業(yè)務(wù)關(guān)系、作業(yè)順序和管理信息流向的圖表。

作用:涉及多角色之間的交互行為,以泳道圖方式梳理核心業(yè)務(wù)流程,明確不同環(huán)節(jié)節(jié)點不同角色用戶的操作及需要完成的任務(wù)。其作用是——表達(dá)清楚業(yè)務(wù)需求在產(chǎn)品線的各個階段中在各個功能模塊之間的流轉(zhuǎn)。

說明:待需求產(chǎn)生后,首先落地的流程說明。業(yè)務(wù)流程圖不是一層不變的,它隨著需求的逐步明確而逐漸調(diào)優(yōu)。業(yè)務(wù)流程圖是整個項目的核心,最后將成為整個項目的標(biāo)桿文件,物流是產(chǎn)品設(shè)計或技術(shù)框架都會以此為主要參考,所以梳理清晰業(yè)務(wù)流程對設(shè)計后臺管理系統(tǒng)非常重要。

當(dāng)用戶在前端觸發(fā)某一操作到期望看到的結(jié)果之間,會存在很多工作在后臺完成,這里所指的后臺通常來講就是管理系統(tǒng)。

以貨運行業(yè)為例:

業(yè)務(wù)流程圖在產(chǎn)品規(guī)劃階段完成,任務(wù)流程圖在產(chǎn)品設(shè)計之前完成,二者存在先后順序,通常是有了業(yè)務(wù)流程圖之后,再開始著手處理任務(wù)流程圖。

任務(wù)流程圖:用戶在業(yè)務(wù)流程中完成了某一項任務(wù),可以通過頁面流程圖來梳理清晰此階段主要是圍繞著核心業(yè)務(wù)流程進(jìn)行拓展,形成直線任務(wù)和完善細(xì)節(jié)。

梳理任務(wù)流的思路類似講一個故事,譬如:我們是如何解決這個問題的?解決問題的流程是什么?

有了任務(wù)流程圖之后,就可以開始產(chǎn)品體驗設(shè)計,將任務(wù)點一個個拆分為功能模塊,然后根據(jù)功能模塊直接的邏輯順序,組合成交互設(shè)計稿,也就是我們熟知的原型設(shè)計。

原型設(shè)計圖:原型設(shè)計階段,主要工作內(nèi)容為業(yè)務(wù)流程圖設(shè)計、邏輯結(jié)構(gòu)圖、功能結(jié)構(gòu)圖設(shè)計、界面低保真原型設(shè)計,確認(rèn)產(chǎn)品的界面布局、用戶用例、交互設(shè)計,同時交付需求規(guī)格說明書?!对诋a(chǎn)品經(jīng)理眼里,「最敏捷」的產(chǎn)品設(shè)計流程》一文中,有比較詳細(xì)的解釋,可以參考。

事:行為管理(操作路徑、行為數(shù)據(jù))

當(dāng)我們明確了不同用戶不同權(quán)限,不同權(quán)限做可操作不同功能之后,就需要進(jìn)一步回答如下的問題:你要用戶干什么?告知用戶某個信息后需要用戶確認(rèn)知曉,還是希望用戶通過你的信息傳遞完成一個具體的動作執(zhí)行?

回答以上問題的過程就是完成行為管理,設(shè)計用戶操作路徑的過程。這一過程中就可以采集到用戶的行為數(shù)據(jù),通過行為數(shù)據(jù)我們可以分析用戶真實的操作場景,并挖掘到業(yè)務(wù)流程及任務(wù)流程中尚未找到的需求點,從而進(jìn)一步的完善我們的管理系統(tǒng)。

如圖所示:管理后臺一般包括三大部分,頂導(dǎo)航、左導(dǎo)航、內(nèi)容區(qū)域。左側(cè)導(dǎo)航,通常結(jié)構(gòu)為1-2級,盡量不超過3級,子層級可通過下拉菜單方式展開。

小Q來總結(jié)

一個產(chǎn)品的產(chǎn)生到用戶使用,類似我們做一道美味佳肴給客戶。后廚如同管理后臺,是一個產(chǎn)品最核心的業(yè)務(wù)及流程的承載,呈現(xiàn)給客戶的菜品如同前端產(chǎn)品的展示,最終經(jīng)由后廚的精心制作達(dá)到色香味具全。

因此,當(dāng)我們設(shè)計管理后臺的時候,業(yè)務(wù)明晰、邏輯明確是首要任務(wù)。管理后臺一般相對復(fù)雜,很多業(yè)務(wù)流程都是多線程穿插,而不是單線程的。

因此,產(chǎn)品經(jīng)理設(shè)計管理后臺時,對功能模塊的劃分和頁面的邏輯設(shè)計要求都非常高,一定不可以僅僅是簡單的模塊疊加。

#專欄作家#

Mandy權(quán),微信公眾號:小Q聊產(chǎn)品,人人都是產(chǎn)品經(jīng)理專欄作家,善于資訊、教育、平臺類產(chǎn)品設(shè)計與分析。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自 Pexels ,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. ????你在說啥

    來自廣東 回復(fù)
  2. 求流程圖是用什么軟件畫出來的?

    來自上海 回復(fù)
    1. 目測是AXURE

      來自廣東 回復(fù)
    2. keynote

      回復(fù)
    3. 目測是AUXURE

      來自廣東 回復(fù)