2017-4-12 濤濤
ERP系統(tǒng)是典型的To B產品，擁有體量大、功能雜、專業(yè)強等特點。前段時間接觸了如此龐大系統(tǒng)中三個子系統(tǒng)的改版工作，從手足無措到冷靜思考，在無數(shù)磕磕絆絆中總結了一些面對大型B端項目時可用的設計思路。
因為項目復雜，此篇是整體設計思路的提煉及方法論的提出，具體的案例及方法論闡述后續(xù)會有更多文章來和大家共同探討。
完整思路如下：
除了基本的5W1H，改版項目在了解項目背景時能獲取更多信息：現(xiàn)版本的反饋是什么？各個角色期望達到的目標是什么？
ERP項目中，客戶不等于用戶，所以多方的動機和期望我們都需要去了解，并以此推導產品設計方向。且因為滿足客戶需求應優(yōu)先于提升用戶體驗，所以對于多角色需求的亦需要權衡取舍。
了解了項目的基本情況后，開始進行需求的加工。
調研包括了需求加工的前三個部分：收集—挖掘—整理。
我們需要從輕易可得的用戶反饋、使用體驗，深度挖掘產品不易見的、更根本的問題，最終匯總整理出完整的需求表。
如何選擇有針對性的需求調研方法，我們通過三步驟來確定：你想知道的—誰最了解—選用方法。
針對型收集，即是找對人問對事。這樣在調研時，每一種方法的目的都很明確，關注點各有不同，既能得到較全面的信息，又不會在調研時迷失方向。
設計輸出包括了需求加工的后三個部分：消化—改良—評審。
在已獲得的需求中，首先提取出需求關鍵詞并明確需求對象，一步一步推導出設計目標并得出接下來的設計策略。
在明確設計目標及策略后，開始通過“解構—重構—評估”對產品進行合理再設計。
在C端產品中，設計師同時也能是用戶，所以對于功能的理解相對容易。但B端產品的用戶往往是專業(yè)人員，產品是為實現(xiàn)某些業(yè)務服務的，我們可能從未接觸過其中的業(yè)務邏輯。所以一個合理的理解模型，能夠幫助設計師透徹理解復雜業(yè)務邏輯。
又由于ERP的難點在于業(yè)務邏輯及功能的多角色的互動，我們將以這兩個為突破點，進行解構。
這種模型我把它叫做拔蘿卜式理解，由專業(yè)詞匯開始，到凝練出業(yè)務目標結束，中間是由表及里、由淺及深地探索過程。
在梳理復雜業(yè)務流程時，僅憑東拼西湊的信息，可能會有信息遺漏的情況。此時依據(jù)想獲取的信息，適當?shù)倪x用一些工具，可以提高我們的效率并保證一定程度上完整性。關于如何選擇適宜的工具，以后會再和大家探討～
將所有涉及到的功能平鋪陳列，討論功能的合理性，再進行重組、刪減。
不同的功能下相同的功能模塊需要在邏輯及形式上保持統(tǒng)一，這也就意味我們在設計過程中建立適宜的規(guī)范更為重要了。
同時在方案輸出過程中，要定時進行方案評估。因為產品較強的專業(yè)性，在內部評審過交互問題后，還需要專家評審，此時的關注點應在業(yè)務邏輯的正確流暢，功能的完整精簡，所以此時不可圖方便，需要仔細地走查每一個功能，從定義到實現(xiàn)流程，是否符合行業(yè)習慣且滿足了專業(yè)要求。
大體量產品反復修改的成本較高，所以保持盡可能小的改動可能性很重要。雖然方案已輸出，但如何能說明我們改版是有效的？原型測試中的數(shù)據(jù)也許能給我們這樣的底氣。
在一次測試中完成對所有要點的測試顯然是不切實際的，要使測試的意義最大化，我們要始終帶著明確的目的性去制定我們的測試規(guī)劃。有目的的設定任務，隨之選定相關參數(shù)，確定測試對象。在測試過程中，注意觀察，認真記錄。
測試結束后，數(shù)據(jù)整理和展現(xiàn)，可以讓我們更清晰直觀地看出測試結果及問題所在。例如我們在測試中得到了如下結果，可以初步判斷我們的設計在使用上是有可行的。
到這一步基本完成原型交付，但項目后期也需要持續(xù)推進。可能會不停有反饋及問題出現(xiàn)，隨時修改，保持更新。
ERP系統(tǒng)的復雜程度遠不是一篇文章所能承載，其中有很多值得思考的點，本篇僅作為大框架的概述，后期希望還能有機會和大家一起探討To B項目中需求調研適用的方法、如何在情境下選擇適用的設計工具等更實踐性的問題。
藍藍設計( www.devb.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務