當我們在進行互聯網或系統產品設計時,大多數產品經理都明白產品創意和交互設計的重要性。但是,如何將一個優秀的產品創意變為真正的產品,以何種方式體現交互設計之美,我們必須以嚴謹有序的方式進行產品設計。

在To B產品,特別是後台產品的設計工作中,即使這些產品通常邏輯比較複雜,但仍能遇到產品經理接到一個需求任務,上來就開始畫原型,做交互,樂此不疲。事實上,這種工作方法常常是不可取的。理清該需求的本質,並在產品設計中以合理和完善的方式去體現,才是第一要務。從此開始,我們應該拋棄一切不着邊際的幻想,從最冷靜和理性的角度來着手產品的設計工作。

第一步:剖析需求,提出問題

在做需求分析的時候,產品經理的一個大忌就是,拿來就做,不問問題。不問問題有兩種可能性:第一種可能性是需求已經提的很完善了,沒有什麼問題可以提;第二種可能性是需求分析不到位。

舉一個例子,曾經有一個業務部門需求是,將原本T+1的金融產品贖回到賬體驗改為T+0實時到賬。但是該需求並沒有提出具體的實現方式,只提出他們可以先墊一部分錢給投資者。我們在分析這個需求的時候,首先要明白,這個需求的第一要務是,無論如何,投資者應該在贖回的當前就拿到贖回款。

  • 衍生出的第一波待解決問題較為宏觀:
  • 一旦T+1變為T+0,原來的T+1產品是否還存在?
  • 是重新創建一個T+0的產品還是把原來T+1的產品改為T+0?
  • 這個T+0產品將會是系統中唯一的T+0產品還是未來多個同類型產品中的第一個?

這一波問題找到答案后,我們將會對T+0贖回這個業務的邊界有大致的了解。如果是孤例,那就是一個功能模塊級別的任務。如果將來會大規模開展,那我們應該從現在就開始考慮功能的擴展性(然而市場總是變化快,開始說只是先做做,後來要大批量上的情況也很多,這主要看產品經理自己的判斷是否準確了)。

第一波問題找到答案后,將會進入第二波問題的提出:

  • 這個業務將由哪幾個部門協同合作?
  • 誰領導,誰協同?
  • 資金從哪個賬戶出款,何時出款?
  • 是否有回款,什麼條件觸發回款?
  • 這些流程的各個節點,誰推進,誰審核,誰被通知?

這些問題答案就是是能夠完成產品設計的最關鍵素材,這個維度的問題應該問到不能再問的原子級別。問題是否問完的檢驗標準就是,產品經理是否自己能夠流暢的口述整個流程的信息流和資金流的流轉過程,有一處不明白,那一處就會成為實現時的坑。

第三波問題也非常重要,這個層次的問題主要在系統層面。例如:

  • 由哪幾個系統協同完成這個需求?
  • 系統和系統之間是如何交互的?
  • 數據一致性如何保證?
  • 一旦一個系統掛了,另一個系統如何回滾或容錯?

在這一波問題中,可能需要技術同事作為顧問,但問答並不需要太細,因為當前只是處在需求分析,並未上手設計。

三波問題,百分之七八十有了答案之後,我們可以寫出一個較粗的需求分析報告,給業務部門進行確認。哦,我知道很多產品經理說我哪有時間寫這玩意兒啊?沒錯,你可以不寫,但不能不想。

第二步:用例先行,框定邊界

如果有做後台的產品經理不知道用例,那是一個很大的遺憾。因為沒有用例,就沒有整個系統。簡而言之,只要能完成預先設定的用例,無論系統實現得多麼差,都起碼是一個合格的系統。

如何寫用例在這裏不多講,個人認為最好的參考資料是《大象-thinking in UML》。寫好用例的意義在於,劃分清楚,在當下需要實現的版本中,哪些需求是需要實現的,哪些不需要。這點很重要,如果不劃分清楚,很有可能出現在需求文檔的撰寫中,不斷加新需求,使版本計劃延期,版本功能變得不可控。

第三步:按角色分模塊,按功能分模板,按模板做頁面

後台產品的原型設計,在很多人眼中,似乎不那麼注重交互,就是一堆“某某管理”的操作頁面。我們見到的大多數國產後台產品,例如各種OA系統,流程管理後台,ERP後台,數據管理後台等,大多數做的潦草而匪夷所思。

說到這裏,不禁想岔開一下:

  • 為什麼我國美食世界聞名,高端廚具還是用德國的?
  • 為什麼我國是中醫文化的發祥地,現在高端漢方化妝品還是唯韓國馬首是瞻?

還有很多的為什麼,如果說國防實力或航天科技方面需要國家財力的支持,那麼在民用品的創新設計方面,我們也不優秀,這似乎應該是一個社會問題。

那麼,我們應該如何來做頁面級的功能設計呢?只有一條宗旨,降低學習成本,提高使用效率

假設該產品已經沿用多年,除非有顯著的簡化和易用性新設計,一般不應改變原有交互邏輯,不管你覺得該邏輯有多麼白痴。原因很簡單,這個產品的使用者很有可能是一些初中都沒畢業的客服中心人員,很有可能是一些很少跟電腦打交道的人,他們並不是我們這樣天天研究各種互聯網產品的人,當我們做好原型之後,應該自己模擬用戶去試試,到底能不能完成既定工作,而不是沉浸在自己應用了各種所謂高端的交互設計概念的飄飄然中不可自拔。

接下來,繼續進入正題。

在模塊設計時,為什麼會有“這個管理”、“那個管理”模塊,到底是誰在管理,管理的目的是什麼?這個模塊的工作之前(前置流程)是什麼?做完這個模塊的工作之後(後置流程)是什麼?這些都需要考慮清楚。

個人的建議是以一個或一類角色的工作作為一個大型的模塊,以該類角色中不同的分工作為子模塊來處理。這樣一來,這類角色可以集中處理工作,而不需要在整個系統的不同模塊之間跳來跳去的這裏點點,那裡點點,一不小心就忘了操作。

這裏也舉個簡單的例子。

見過有些產品設計,將某些業務的申請和審核做在一張頁面里,我個人是很反對這種設計的。這種設計的第一個壞處是,這倒逼了技術實現必需將權限設定到按鈕級,增加了工作量;第二個壞處是,對於操作員和審核員,無法區別展示不同內容,大家看到的信息必須是完全一樣的,畢竟你們共享了一張頁面,因此擴展性也是差的。

再說說按功能分模板。

每張頁面都有它自己的功能,沒有一張頁面是什麼功能也沒有的。一般頁面的功能可以粗略的分為:綜合展示頁面(dashboard類頁面)、表單工單類頁面-即填入一些數據並保存的頁面、列表類入口頁面-即展示數據表格並帶有一些索引鏈接的頁面(例如產品列表,投資者列表等)、數據查詢類頁面-即帶有搜索區和結果區的頁面、詳情主頁類頁面-即展示某個對象全部數據的頁面(例如個人資料、賬戶詳情等)。除此之外,彈窗也有一些模板,在這裏不一一列舉。

如果我們能夠預設一些模板,並在頁面設計中盡量復用這些模板,不但可以節省我們的工作時間,也可以讓用戶的學習成本進一步降低,因為對大多數人來說,觸類旁通比完全從頭開始學習容易得多。

當然,這是一個循序漸進的過程,我們自己應該在一次次的產品迭代中,也對我們的頁面模板庫進行迭代,不斷重新整合、分拆,以適應新的業務和進一步優化原有業務。

當我們完成了以上三步,可以說大部分的產品設計工作已經完成,但是這僅僅是設計階段,這些工作還不能達到可以提交開發的階段。

下一篇開始寫產品自測。

 

本文由 @echo回聲 原創發佈於人人都是產品經理。未經許可,禁止轉載。