B端產品中工作流的交互設計

14 評論 13639 瀏覽 129 收藏 14 分鐘

B端產品的設計中經常會出現工作流的身影,有的流程復雜有的流程簡單。無論是簡單還是復雜,它的概念都是一樣的。工作流的概念定義的很復雜,更多是從技術層面出發,通俗點說就是根據一系列過程規則,將文檔、信息、任務在不同的執行者之間進行傳遞與執行。下面我將以一個相對簡單的財務報銷的工作流程,來介紹一下工作流中的交互設計是怎么做的

在開展交互設計之前我想說一說很多新手設計師都會踩的一個坑:做設計之前沒有充分了解需求。需求的溝通是交互設計師非常重要的一個能力(千萬不要以為交互設計師就是畫畫原型圖,我做項目時也是最反感項目經理什么需求都不說清楚就讓畫原型圖)。

需求和誰溝通?如果能接觸到客戶與客戶溝通當然最好,當然更多時候我們是與項目經理或產品經理溝通,我們必須有透過現象看到本質的能力。需求溝通的話題太大在這里就不再贅述,后續有時間再單獨聊一聊如何溝通需求。

我將以下面三個方面來闡述一下工作流中的交互設計該怎么做:

  1. 需求的確定與梳理。正如前面所說任何設計一定是建立在明確的需求之上的;
  2. 流程的梳理及信息架構的產出。流程的設計是交互設計中非常重要的部分,好的流程能夠讓用戶更容易完成任務。這也是我本次分享著重要講的部分;
  3. 原型的產出。簡單講述一下原型設計中要注意的問題。

一、需求的確定與梳理

在需求溝通的階段有的客戶(用戶)相對專業能夠很明確的闡述自己需要的功能,但是大多數客戶(用戶)只是能大概的講一下自己需要什么東西。至于具體細節他是不清楚的,這個時候我們需要根據需求自己去整理通過與客戶(用戶)的溝通盡可能的去了解用戶的使用場景,先設計一套方案然后和客戶(用戶)反復溝通直至確定最終的需求。

這里如果有條件的情況下盡量去做一個簡單的用戶調研,因為這樣會了解更多的用戶使用場景進而挖掘出用戶的潛在需求。

通過溝通我們了解并最終確定了到客戶的需求。

客戶最開始提出的需求是這樣的:

我們經過溝通交流進一步挖掘了一些潛在的需求,現在的需求是這樣的:

剛開始客戶的需求是申請人發起報銷申請,然后經過部門經理、分管副總、總經理、財務的審批,在審批中發現問題,可以駁回,如果審批通過,財務進行打款,整個流程形成閉環。

我們在了解到需求后結合自己的分析提出了幾個問題:

  1. 審批中被駁回的申請需要怎么處理;
  2. 如果申請人在提交申請后發現問題能否進行修改;
  3. 部門經理、分管副總、財務以及總經理是否也需要報銷申請。

在和客戶溝通后最終需求為:申請人發起申請、然后經過部門經理、分管副總、總經理、財務審批,審批通過后財務進行打款。被駁回的申請,申請人在修改后可以再次提交。如果申請人在提交申請后發現問題可以先進行撤回然后再修改并提交。部門經理、分管副總、財務、總經理有審批和發起申請兩種權限,畢竟他們也需要進行報銷。

經過溝通與梳理需求基本敲定了,當然這只是一個大的框架還有許多細節沒有考慮進去,這就是我們后面進行流程設計的時候需要做的事情了

二、梳理信息架構及流程設計

經過前面的需求溝通與梳理現在我們已經對需要設計的財務報銷系統有了一個大概的框架,接下來我們需要站在交互的角度去考慮并設計流程。前面為了讓大家直觀的了解需求我已經繪制了一個簡單的流程了,現在我們需要在此基礎上細化。

這個階段比較重要,因為這個階段的設計基本決定了我們的系統可用性和易用性,關乎用戶體驗,所以要花大量時間在這個階段思考、打磨。

首先從需求出發梳理出一個大概的流程,前面談需求的時候已經梳理過了,這里再貼出來:

這里有兩個流程圖,并不是說有兩套流程,流程都是一樣的,只不過是角色不同,后面再說。先看看我們梳理出的流程,功能點比較清晰,看上去似乎沒有什么問題,那么我們需要更深入的去思考了,站在用戶體驗的角度去思考,這個時候我們就要帶入一些使用場景了。

我們舉兩個比較通用的場景:

  1. 如果操作途中出現了異常情況(網絡異常、服務器異常);
  2. 用戶在使用途中因個人行為被迫中斷操作(嘗試挖掘用戶新的需求點)。

第一點的異常情況現在的流程中我們并沒有考慮到,那這里我們就要去思考了,異常情況有哪些,其實異常情況有很多這里我們只考慮幾種常見的情況:網絡異常;服務器異常。

(1)網絡異常

如果用戶在提交申請的過程中網絡出現異常該怎么處理。我們在輸入了很多表單內容上傳了一堆附件之后在提交的時候網絡出現異常了。如果不對這個環節進行設計的話,用戶辛苦輸入半天的內容直接沒有了,回頭還得再次輸入,這是一件很崩潰的事情。這個時候我們需要一些策略,對用戶輸入的內容進行緩存,即使用戶碰到網絡異常再返回的時候內容仍然在,這個體驗就很贊了。

有的同學可能會覺得這個是技術層面的問題應該是開發去考慮的事情,這就大錯特錯了。除了少數有經驗的開發會去考慮這個問題,大多數開發是不會考慮的或者說他們更多只會按照需求清單進行開發,你沒提他可能也不會問。而恰恰這些地方就是體現一個系統易用性的重要細節。也是體現一個產品經理或者交互設計師設計能力的點。

(2)服務器異常

服務器異常同網絡異?;绢愃?,最大區別是網絡異常可能不在我們的控制范圍之內而服務器異常卻是我們不可推卸的責任。所以在這個時候我們除了要解決用戶內容緩存問題還需要安撫用戶的情緒,提出一個好的解決方案,比如告訴用戶嘗試刷新頁面,或者判斷是不是用戶操作導致的問題并進行提示引導,而不是直接丟給用戶一個404頁面。

第二點用戶在使用途中因個人行為被迫中斷操作

這個其實是從用戶使用場景出發去挖掘用戶潛在的需求點。比如說用戶正在錄入報銷內容,中途突然有重要電話過來了,或者臨時有重要任務需要處理,而這個時候用戶錄入了很多內容了他并不想放棄已經輸入的內容,這個時候該怎么辦?

如果不去做這個環節的設計會不會影響系統的可用性,當然不會,我們的核心流程是沒有問題的。

那會不會影響用戶的情緒呢?

可能會,為什么是可能,因為一部分用戶可能不在乎或者沒有這個意識。那如果我們在這里設計一個草稿箱是不是就能解決用戶這一痛點了呢,這對于提升用戶體驗很有幫助。

這些用戶潛在的需求點,只能通過帶入用戶場景,切實站在用戶易用性的角度去考慮問題你才能尋求突破。

再來說說角色問題

角色是工作流中最根本的一個環節,不同角色權限不同,流程也會有些差別。

前面提到過,這個報銷系統主要分為三個角色:員工、領導(部門經理、分管副總、總經理)、財務。

員工只有發起報銷申請的權限,領導有發起報銷和審批報銷單的權限。這里把部門經理、分管副總、總經理都劃為一個角色,因為他們的權限是一致的只不過在流程的節點上有先后關系,財務的權限比較特殊,從級別劃分上他不具備審批權。但是要行使審核權,就是檢查報銷信息和發票信息是否正確、屬實,但是在權限上他與領導角色是一致的這個是要特別注意的。

不同權限角色在流程設計上也會不同,所以設計流程時必須搞清楚角色權限問題。前面我們針對員工角色和領導角色分別設計了不同的流程,財務角色的流程和領導角色的流程是一致的。

這個報銷系統的設計是最基礎的工作流形式了,權限相對清晰,在實際工作中由于需求和應用場景不同,往往會很復雜。在設計的時候需要明確把角色權限控制的規則告知開發。

通過進一步的考慮分析,現在流程設計這個環節基本就完成了(不一定全面,任何設計都要結合實際的需求和業務場景)。

接下來是梳理信息架構了,有了流程和角色的設計,產出信息架構相對來說就比較簡單了,這里需要注意的是信息架構需要考慮的更細,有哪些角色不同角色分別對應什么頁面,頁面有哪些功能點都需要列出來

三、原型的產出

原型同樣是一個很重要的環節,因為它是連接上下游、可視化的呈現系統設計的一個重要載體,并且是設計、開發、測試工作的重要依據。所以原型的設計不能馬虎,必須面面俱到,把前面設計的流程和角色權限的規則體現出來,同時還要注意細節和流程的完整。

在前面梳理信息架構的時候實際上頁面的設計在我們腦海中已經有了一個雛形,原型的繪制只不過是時間問題。當然這里也不排除在繪制原型的過程中發現一些信息架構設計上的問題,可能需要同步整理修改。我個人習慣在繪制原型前簡單的畫一個草稿,這樣有利于梳理思路,發現問題時修改成本也會比較低。

以上是我對工作流中交互設計的一些理解,僅代表個人觀點不是行業準則,希望能對你有所幫助,也歡迎大家提出問題共同交流!

 

本文由 @鱷魚先生 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 謝謝

    回復
  2. 有畫好的原型圖嗎 也分享出來看下

    回復
    1. 嫖得理直氣壯!

      來自天津 回復
    2. 嫖得天經地義!

      來自江蘇 回復
  3. 原型圖最基本的一點:線盡量不要交叉

    來自湖北 回復
    1. 流程圖

      來自湖北 回復
  4. 這個流程設計強烈建議用泳道圖畫,把每個角色的每個動作歸屬定義清楚。 ??

    來自重慶 回復
  5. 有點東西 正好需要做個工作流 可以參考

    來自北京 回復
  6. 草稿箱也可以用緩存來解決啊,再做一個草稿箱性價比太低了吧

    回復
  7. 這不是產品經理做的事情嗎 需求溝通到話原型

    來自廣東 回復