實踐提煉:面對大型B端項目,產品設計該如何展開?

25 評論 44377 瀏覽 326 收藏 9 分鐘

作者根據自己的工作經驗,總結了一些面對大型B端項目時可用的設計思路,希望可以給大家的工作帶來一些幫助。

ERP系統是典型的To B產品,擁有體量大、功能雜、專業強等特點。前段時間接觸了如此龐大系統中三個子系統的改版工作,從手足無措到冷靜思考,在無數磕磕絆絆中總結了一些面對大型B端項目時可用的設計思路。

因為項目復雜,此篇是整體設計思路的提煉及方法論的提出,具體的案例及方法論闡述后續會有更多文章來和大家共同探討。

完整思路如下:

一、明確項目背景:了解各方改版動機及期望

除了基本的5W1H,改版項目在了解項目背景時能獲取更多信息:現版本的反饋是什么?各個角色期望達到的目標是什么?

ERP項目中,客戶不等于用戶,所以多方的動機和期望我們都需要去了解,并以此推導產品設計方向。且因為滿足客戶需求應優先于提升用戶體驗,
所以對于多角色需求的亦需要權衡取舍。

了解了項目的基本情況后,開始進行需求的加工。

二、需求調研:不同的角色有不同需求

調研包括了需求加工的前三個部分:收集—挖掘—整理。

我們需要從輕易可得的用戶反饋、使用體驗,深度挖掘產品不易見的、更根本的問題,最終匯總整理出完整的需求表。

如何選擇有針對性的需求調研方法,我們通過三步驟來確定:你想知道的—誰最了解—選用方法。

針對型收集,即是找對人問對事。這樣在調研時,每一種方法的目的都很明確,關注點各有不同,既能得到較全面的信息,又不會在調研時迷失方向。

三、設計輸出:以設計目標為導向的解構—重構

設計輸出包括了需求加工的后三個部分:消化—改良—評審。

在已獲得的需求中,首先提取出需求關鍵詞并明確需求對象,一步一步推導出設計目標并得出接下來的設計策略。

在明確設計目標及策略后,開始通過“解構—重構—評估”對產品進行合理再設計。

1.解構:重在詳細全面梳理功能模塊,由淺入深理解功能定義。

在C端產品中,設計師同時也能是用戶,所以對于功能的理解相對容易。但B端產品的用戶往往是專業人員,產品是為實現某些業務服務的,我們可能從未接觸過其中的業務邏輯。所以一個合理的理解模型,能夠幫助設計師透徹理解復雜業務邏輯。

又由于ERP的難點在于業務邏輯及功能的多角色的互動,我們將以這兩個為突破點,進行解構。

這種模型我把它叫做拔蘿卜式理解,由專業詞匯開始,到凝練出業務目標結束,中間是由表及里、由淺及深地探索過程。

在梳理復雜業務流程時,僅憑東拼西湊的信息,可能會有信息遺漏的情況。此時依據想獲取的信息,適當的選用一些工具,可以提高我們的效率并保證一定程度上完整性。關于如何選擇適宜的工具,以后會再和大家探討~

2.重構:以設計目標為導向,由小到大,由內而外重構產品。

將所有涉及到的功能平鋪陳列,討論功能的合理性,再進行重組、刪減。

不同的功能下相同的功能模塊需要在邏輯及形式上保持統一,這也就意味我們在設計過程中建立適宜的規范更為重要了。

3.評審:以設計目標為評估標準,注重專家評審結果。

同時在方案輸出過程中,要定時進行方案評估。因為產品較強的專業性,在內部評審過交互問題后,還需要專家評審,此時的關注點應在業務邏輯的正確流暢,功能的完整精簡,所以此時不可圖方便,需要仔細地走查每一個功能,從定義到實現流程,是否符合行業習慣且滿足了專業要求。

四、原型測試:讓數據說話。

大體量產品反復修改的成本較高,所以保持盡可能小的改動可能性很重要。雖然方案已輸出,但如何能說明我們改版是有效的?原型測試中的數據也許能給我們這樣的底氣。

在一次測試中完成對所有要點的測試顯然是不切實際的,要使測試的意義最大化,我們要始終帶著明確的目的性去制定我們的測試規劃。有目的的設定任務,隨之選定相關參數,確定測試對象。在測試過程中,注意觀察,認真記錄。

測試結束后,數據整理和展現,可以讓我們更清晰直觀地看出測試結果及問題所在。例如我們在測試中得到了如下結果,可以初步判斷我們的設計在使用上是有可行的。

到這一步基本完成原型交付,但項目后期也需要持續推進??赡軙煌S蟹答伡皢栴}出現,隨時修改,保持更新。

五、最后

ERP系統的復雜程度遠不是一篇文章所能承載,其中有很多值得思考的點,本篇僅作為大框架的概述,后期希望還能有機會和大家一起探討To B項目中需求調研適用的方法、如何在情境下選擇適用的設計工具等更實踐性的問題。

 

作者:三水采田,微信公眾號:三水與設計

本文由 @三水采田 原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 受益匪淺,感謝樓主分享

    來自廣東 回復
  2. ERP,通俗來講就是人財物的管理,全程圍繞“財”~“物”這兩個環節,進行數據的流通轉換,穿插進對應的人來完成中間環節產生的一系列成本費用,最后得出多個維度的報表。
    通常來說有兩種類型,一種是商用,一種是內部管理的,其中商用的又分定制型的和通用版的,內部管理則是和專用的一樣,作者這里提及的是PM的設計的思路,每一個行業,每一個公司對應的管理方案和管理需求都是不一樣的,這就需要更多的看清需求的本質,這樣才能設計出通用的軟件,不過這個erp的設計,大框架上的設計沒問題了,剩下的就是進行細節的處理了,那個環節也是磨死人的節奏,還有中間人員的進出,感覺設計一個erp(從需求到上線),不下于打一場持久戰,少則1年,多則幾年十幾年都會有。

    來自廣東 回復
  3. 您好,想問一下從項目開始到設計完成,一共花費了多少時間?分別是怎么安排的呢?

    來自浙江 回復
  4. 我也想問圖是使用什么工具畫出來的?

    來自北京 回復
    1. keynote

      來自北京 回復
  5. 贊一個樓主總結得清晰明了的方法論。能否加個微信或QQ交流下?

    來自山東 回復
  6. 很棒!請問下,圖是使用什么工具畫出來的?

    來自北京 回復
    1. 用的keynote哈

      來自北京 回復
  7. 感謝樓主的方法論,我也要加微信(注明:我是妹子 ?? )

    來自四川 回復
  8. 個人公眾號 三水與設計,沒找到那? 難得有人聊TOB之ERP

    來自四川 回復
  9. 1、ERP體系龐大到你忙人摸象, 2、單個系統模塊功能縱向的深度,以及橫向“三流信息”與其他模塊數據,單據流轉鏈式嵌入緊密,上下游系統模塊互為一體,才可輸出每個節點,及最后成果。

    來自四川 回復
    1. 是的,之前只是接觸改版項目,最近做新系統時對您所說兩點也深有感觸。如果方便的話,要不我添加您?

      來自北京 回復
    2. 私信下,

      來自四川 回復
    3. 好的,,

      來自四川 回復
    4. 老司機回答的很有深度,雖然我沒有做過ERP系統,但是做的其他系統也有如此體會。

      來自四川 回復
    5. 我現在也在做erp軟件的改版,現在已經深刻體會到你說的第一點了

      來自上海 回復
    6. 實踐的體會,共勉,在路上就好

      來自四川 回復
  10. 贊一個樓主總結得清晰明了的方法論。能否加個微信或QQ交流下?

    來自四川 回復
    1. 好的啊~方便的話我加您?也可以關注個人公眾號 三水與設計,發送的我都會看到~??

      來自北京 回復
    2. 我也要微信,樓主

      來自福建 回復
    3. 嗯嗯 不好意思啊剛看見 已經在公眾號上發給你了~嘻嘻

      來自北京 回復
    4. 樓主,微信?加一下

      來自北京 回復
  11. 學習了。期待更多分享

    來自陜西 回復
    1. 嗯嗯 感謝閱讀 也期待能和大家多些討論,共同進步~ ??

      來自北京 回復