UX設計流程中，需求分析是絕大多數(shù)流程的開端。所以今天，我們先從產(chǎn)品分析作為切入點，進入到 UX 進階知識中的第一篇分享。

產(chǎn)品需求的認識

產(chǎn)品需求分析被念叨了很久，但是很少有人能真正搞明白我們在分析的是什么東西，以及作為一個和產(chǎn)品經(jīng)理工作內(nèi)容有交叉的知識點，有很多網(wǎng)上的分享只是照搬了他們的要求而已，但并不適用我們的工作。

所以在理解設計師所需的產(chǎn)品需求分析技能以前，我們要首先搞明白，產(chǎn)品需求本身是什么!

通常展開項目前，要先制定“需求”，即這次項目要做什么事情的具體指示，是要開發(fā)新功能、優(yōu)化操作流程、調整界面樣式，還是修改現(xiàn)有BUG。

只有有了項目的具體指示，我們才能去推進項目的執(zhí)行，約等于游戲中的“任務”，沒有任務你就只能在地圖中瞎跑。

產(chǎn)品經(jīng)理就是分發(fā)任務的 NPC，他們會將需求制作成相關的文檔，供團隊成員查閱或參考。

說起文檔，我們就要了解，產(chǎn)品提供的文檔包含了3種常見的類型：BRD、MRD、PRD。

1. BRD：

• Business Requirement Document 的縮寫，也叫商業(yè)需求文檔，是在開發(fā)產(chǎn)品前，對商業(yè)目標、戰(zhàn)略愿景進行分析和說明的文檔。

2. MRD：

• Market Requirement Document 的縮寫，也叫市場需求文檔，是針對面向市場范圍進行調研、統(tǒng)計、分析并得出結論的文檔。

3. PRD：

• Product Requirement Document 的縮寫，也叫產(chǎn)品需求文檔，是對所開發(fā)產(chǎn)品包含什么功能、邏輯進行具體描述的文檔。

這三層文檔是一個從宏觀到微觀的推導過程記錄，先從戰(zhàn)略層出發(fā)，描述大方向上要做的目標，再根據(jù)這個目標劃分出的市場范圍進行調研分析，找出應該提供什么樣的功能點才能符合市場的實際需要。

最后，在產(chǎn)品需求文檔內(nèi)，將產(chǎn)品包含的所有功能、邏輯詳細描述出來，比如一個退貨流程需要經(jīng)過哪些步驟，退貨成功和不成功的條件等等。

PRD 包含了我們這個版本中所需要做的具體工作內(nèi)容，而 BRD、MRD，是為什么要做這些產(chǎn)品功能的說明，這就是一套完整的產(chǎn)品需求說明所需包含的內(nèi)容。

BRD、MRD 這兩種文檔，出現(xiàn)的頻率并不高，通常也只在新產(chǎn)品立項、大版本調整的時候才會做。而 PRD 文檔則是我們主要接觸的內(nèi)容，需要深入了解。

產(chǎn)品需求PRD的具體認識

PRD 文檔作為產(chǎn)品需求說明的文檔，也可以理解成是一份產(chǎn)品說明書。它最大的作用就是以書面的形式，記錄下來產(chǎn)品要做成什么樣，避免口頭上的隨意性。

一份專業(yè)的 PRD 文檔中，通常會包含這些模塊：

• 版本信息
• 文檔目錄
• 版本概述
• 產(chǎn)品結構
• 功能說明

下面，我們分別對這些模塊進行簡單的講解，進一步了解 PRD 文檔的細節(jié)。

1. 版本信息

版本信息是這個文檔的有關 “屬性” 記錄，記錄由誰修訂撰寫，時間點，版本號，面向系統(tǒng)等等。

這個記錄是方便在后期回看以前的 PRD 時可以對上時間線或負責人，通常由一個簡單的表格來呈現(xiàn)，比如下面這樣。

2. 文檔目錄

文檔目錄則是整份文檔的索引目錄和內(nèi)容結構表現(xiàn)，對于一份比較完整的產(chǎn)品 PRD 來說，會有大量的信息層級和模塊，如果缺乏這個目錄，我們就很難從中快速翻到自己想要的模塊里。

目錄是一個很常見的東西，我也就不截圖了。不過對于一份靠譜的 PRD 文檔來說，目錄應該是做成可以快速跳轉到指定位置的格式的，類似線上文檔工具自動生成的目錄。

3. 版本概述

版本概述是對這次項目做一個整體性的概括，包括改版的原因、工期、環(huán)境、人力資源介紹等等，最重要的，是在這個模塊羅列本次項目的實際需求項。

通過這種表格，可以幫助團隊成員快速建立對本次項目更新內(nèi)容的認知框架。

4. 產(chǎn)品結構

產(chǎn)品結構包含了頁面層級結構、信息結構、功能結構等類型，通常由思維導圖中的樹狀圖表現(xiàn)。

頁面層級結構圖就我們正常訪問的頁面從屬關系，也是最好理解的。

功能結構圖則是不管頁面怎么安排，就在 “范圍層” 的角度描述產(chǎn)品包含的核心功能和下級功能。

信息結構圖，則是在不同頁面中包含的 “模塊”、“字段” 有哪些，樹狀圖的最底層將不再是頁面單位，而是信息顆粒。

5. 功能說明

前面四條都是比較籠統(tǒng)的講解整個應用的信息，而在功能說明中，才包含我們應該如何具體進行設計、開發(fā)的信息。

功能說明通常會將前面需求條目中單獨羅列出來進行說明，這個說明是為了讓看的人能看懂，所以沒有任何限制，靠編寫者自由發(fā)揮。

常見的功能說明中，除了文字描述外，還要搭配大量的圖形和表格。例如應用原型進行注解、流程圖、泳道圖、關系圖等等。

功能說明占據(jù)了整份 PRD 的絕大多數(shù)篇幅，也是指導我們具體工作的內(nèi)容，看懂功能說明是每一個團隊成員職責，包括設計師也是。

當然，不同產(chǎn)品經(jīng)理的文檔書寫能力是不同的，要寫一份大家都能看的懂的文檔，是考驗撰寫者 “講人話” 的能力的。如果出現(xiàn)了無法理解的地方，就一定要記得和相關編寫者進行溝通。

設計師如何進行分析

有了一份 PRD，下一步，就是設計師進入分析的環(huán)節(jié)了。

常見的分享對設計師要掌握的需求分析能力有主次不分的問題，設計師的需求分析，不是搶產(chǎn)品經(jīng)理飯碗，制定需求內(nèi)容、劃分需求等級、評價需求價值。

在一個成熟的團隊中，PM 在制定 PRD 中必然也會處理這些工作，而設計師需要做的。是在需求評審、PRD 中，整理和設計有關的內(nèi)容，并制定后續(xù)的工作內(nèi)容。

PRD 并不是只寫給設計師看的，更多是給前后端開發(fā)當開發(fā)依據(jù)的說明，必然有一部分需求點是和設計師沒有關系的，比如 BUG 修復、算法推薦優(yōu)化、統(tǒng)計埋點等。

我們要根據(jù)多方面獲得的信息將涉及設計的需求整理出來，并羅列出一份明細，這份明細包含設計的頁面、模塊或者圖標。

然后，再對每條需求標記上相關的數(shù)量、優(yōu)先級、設計目標、時間要求、負責人等，作為一份設計項目清單，比如下圖這樣的表格。

一份清晰的設計項目清單，可以很好的幫助設計師團隊規(guī)劃工作安排，不至于整個過程手忙腳亂。

這個過程與其叫分析不如說是整理，而真正需要做專業(yè)分析的時候，是你發(fā)現(xiàn)了產(chǎn)品當前某些交互、體驗中的問題可以改進，向產(chǎn)品經(jīng)理提出建議。

或者，當你覺得某些產(chǎn)品需求不合理，影響產(chǎn)品的體驗，那你就可以通過一些專業(yè)的分析來制作一份說服產(chǎn)品經(jīng)理的報告，說服他們調整需求。

要牢記——決定需求制定的人是產(chǎn)品經(jīng)理，而不是設計師。

今天分享寫到這邊，在后面我還會更新更多和分析有關的專業(yè)理論和技巧。