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

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

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

完整思路如下：

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

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

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

所以對于多角色需求的亦需要權衡取舍。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

到這一步基本完成原型交付，但項目后期也需要持續推進。可能會不停有反饋及問題出現，隨時修改，保持更新。

五、最后

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