設計師如何進行業務分析

在4月初回歸了團隊,開始接手新的業務,根據平時看的書以及其他設計師的設計沉澱了解到,作為交互設計師對業務的了解程度是非常重要的,好的設計師剛開始接到產品經理給的需求時不會急著畫交互稿做設計,而是花費很多時間及精力去分析梳理業務,甚至有時候會幫助PD一起來整理業務邏輯。如果一個設計師在給其他人員講自己的設計方案(尤其是對上級),被問及「這裡是怎麼考慮的」、「為什麼是這些功能邏輯」等業務上的問題而不知道如何回答時,就會顯得非常得不專業。

還有一些設計師尤其是像我這種沒什麼實戰經驗的新人,沒有形成系統化的分析方法,在進行業務分析時,就會比較碎片化,拿著這樣的分析結果進行設計以及和其他成員交流起來就非常困難。在此,經過學習大牛們的設計套路,分析整理了一套業務分析流程,用以指導以後的項目。

1.了解項目背景

了解項目背景很重要,因為你在後續時間需要和多人多次描述你的項目,我現在接手的一個項目業務邏輯非常複雜,而且之前也沒接觸過這類平台的項目,所以PD很耐心地跟我講解這個項目的由來、原因、展望等等,進行多次充分溝通,這樣在後續跟其他同學描述你的項目時(尤其是上級)就可以很清楚的複述出來。做好前期的溝通工作對後續項目的進展也有很大的幫助。

一般來說,項目背景主要是:

1為什麼做why:為什麼要做這個項目,有什麼原因導致需要做?用戶有什麼需求沒有滿足需要做?現在的產品存在某些問題需要解決?還是即將迎來XX節日需要做這樣的活動?用戶為什麼要來使用這個產品?等等

2給誰做who:目標用戶是誰?誰來使用這個產品?誰能看到這個產品?產品涉及的各方人員有哪些?等等

3做什麼what:產品具有哪些功能?能給用戶帶來哪些價值?等等

4怎麼做how:用戶如何使用這些功能?這些功能如何實現?以及項目的排期是怎樣的?等等

2.定位業務目標和設計目標

理解了項目背景後,設計師需要定位出業務目標和設計目標,《五導家設計法》中對兩者的定義是:

1業務目標:用[某策略]給目標用戶帶來[某價值],以實現[某變現方式]。

2設計目標:用[某設計策略]給目標用戶帶來[某價值],以助力[某變現方式]。

我個人覺得這個定義已經屬於哲學層面的概念,理解起來還是比較抽象和複雜的,我自己讀過很多遍這段內容但在分析時還是很難運用起來,而且很多項目其實只有一個總體的目標並不會細化到這樣的顆粒度。於是我去我們平台查閱了一些設計師的分析部分內容,整理組織一下發現大致的信息是這樣的:

接著繼續細化其中的規律整理得出兩個目標的描述方式:

業務目標

主要是這幾部分,可以組合其中一部分作為業務目標,例如:

1.以XX策略為用戶提供利益點提高用戶在網站平台的上線佔有率

2.通過XX功能為用戶滿足便捷搜索需求,從而提升用戶在網站平台的使用效率實現XX目標

設計目標

案例中的設計目標其實結構和業務目標基本一致,由於自己的實踐經驗以及能找到的分析案例有限,所以只說個人的理解:設計目標是相對業務目標更加具體化的策略和實現方式。其描述方式同樣可以使用上面總結出來的套路,例如:

1.用戶1通過XX功能進行設定活動目標和XX方式,並在必要時進行XX操作,以幫助完成目標。

2.用戶2在XX平台進行活動配置,並查看實時效果,進行評估和驗收。

3.場景化業務流程

PD在給設計師描述項目時,一般會講解業務的流程圖,常常比較複雜,且涉及各方資源模塊的內容。這些內容可以幫助我們更好更快地理解整個項目的情況,但在設計分析時,一方面業務流程中的很多內容與設計無關,太多內容會對設計師的判斷產生干擾,以致找不到設計環節需要關注的核心信息;另一方面業務流程圖缺少一些細節內容或沒有涉及每一個需要考慮的元素,造成最後產出方案時的設計缺失。所以在了解完業務後設計師需要以用戶的角度來場景化業務流程。通過梳理細化流程圖,設計師也可以更好的理解項目並查漏補缺每一個元素,以幫助PD進行項目核心信息判斷及風險預估。

像我最近的項目中,業務流程複雜,涉及很多後端、演算法的功能模塊,甚至一些線下的人肉操作模塊。涉及三方人員(後台管理人員、商家和平台),所以我就分用戶按場景進行流程分析梳理,列出所有的操作路徑以及各種狀態,一方面檢查每一個元素幫助自己理解業務,另一方面也常常能發現一些核心問題,並反饋給PD溝通,得到「這是個好問題,我怎麼沒想到」,「你理解地很到位」這樣的讚賞。

PD給的業務流程:

設計師進行再梳理後的用戶操作流程:

1.基本流程

2.用戶1 操作流程

3.用戶2操作流程

4.找出項目的核心信息

需要羅列出來的項目核心信息主要包括:

1用戶背景:用戶有哪些特徵(基本特徵和行為特徵)?產品的使用經驗?

2功能類型:產品有哪些功能類型?各種功能之間有何聯繫及限制?

3關鍵功能:最核心的功能是什麼?操作是否便捷?

4關鍵場景:最關鍵的使用場景是什麼?這個場景的特徵有哪些?會有哪些影響因素?

5運行機制等:產品功能、演算法、技術的運行機制是怎樣的?(這個雖然是技術上的內容,但是設計師也需要了解清楚,以便設計的方案更接地氣)

做這樣的工作有以下好處:

一方面,可以和PD共同確立項目設計的重點,檢驗自己對項目的理解是否與PD一致,便於後續能夠做出出彩的地方。有時候甚至可以圈定大家各自工作的職責範圍及重點。

另一方面,在與項目組其他不了解業務的人員進行溝通時,也會更加方便,將帶有這樣分析內容的設計方案交付給他們能助其更容易理解並抓住重點。

5.記錄問題點

記錄分析業務中的問題點,與PD討論確定下來,並且一定要達成一致!這樣在與別人交流方案時,當他們問及同樣的問題就可以輕而易舉地解答並說服他們。

以上內容純屬個人觀點,如有不合理之處歡迎指正~

推薦閱讀:

如何寫產品需求文檔(PRD)?
適用於移動端產品的浪子PRD文檔V1.0
Axure如何生成適配手機屏幕的APP原型
敏捷開發的PRD文檔該怎麼寫

TAG:交互设计 | PRD | 需求文档 |