profile

Soking

Soking 來信:撰寫產品需求文件 PRD 時的閱讀體驗七宗罪

Published about 1 month ago • 1 min read

哈囉,朋友

我遇過的軟體業產品經理通常都會覺得撰寫 PRD 是一件很痛苦的事情,書寫的過程痛苦、用來解釋給別人聽的時候痛苦,其實就連幾個月後重新看自己寫的規格文件,也挺痛苦的。

仔細評估背後的狀況,其實「書寫原則」混亂,造成文件的閱讀體驗差,是最主要的元兇。

以下想與你分享人們閱讀 PRD 過程中常見的問題,包括了:

  1. 缺乏敘事層級脈絡
  2. 只見增刪查改缺乏使用者意圖
  3. 混淆真人與系統角色
  4. 突然發明嶄新的詞彙
  5. 語意曖昧與廢話連篇
  6. 混搭倒裝句與副詞子句
  7. 描述機制需求時都在寫 UI 畫面

▋七宗罪之首:缺乏敘事層級脈絡 ▋

閱讀體驗糟糕的 PRD,第一條常見的狀況就是劈頭就進入細節,沒有告知閱讀的人這個細節從何而來。

例如第一行就寫了「開課三天前可退費。」

那麼閱讀的人就必須自己推理,有個概念叫做「開課」,然後看到了退費,那麼逆向思考一下,應該是先繳費了才能退費。

短短一行字就需要閱讀者自行推理、解壓縮兩個概念的脈絡,而這還是通俗易懂的產品服務領域,或許可以期待他人自行通靈成功。

如果這樣的描述發生在更專業的主題領域,例如「預審投單後七天內可臨時補單」,正常人都會放棄通靈,與其看文件不如開會講清楚。

書寫 PRD 的時候,需要安排一個順序進行「宣告」,讓每個抽象概念有層次的登場。

例如現在要寫關於「課程」的需求描述,那就先宣告如何建立課程、會有付費的概念,那麼才會寫到退費的業務邏輯。

▋七宗罪之二:只見增刪查改缺乏使用者意圖 ▋

第二種最常見的 PRD 書寫狀況,就是通篇描述都只有增刪查改,例如:

  • 營運人員可以新增課程
  • 營運人員可以瀏覽課程
  • 營運人員可以查詢課程
  • 營運人員可以編輯課程
  • 營運人員可以下架課程

也不能說這有寫錯,而是如果只有這樣程度的訊息量,那幹嘛需要寫需求文件?

開發團隊需要明確的了解使用者意圖,才能評估開發出來的功能或流程,能不能解決問題。

比起「營運人員可以新增課程。」

如果寫:「營運人員為學員媒合老師,預約課程。」

閱讀者第一時間會理解整件事情的意義,接下來更細部描述「預約課程」時需要的相關資料時,整件事情也有了脈絡。

甚至更進一步,開發這個功能的人,還可以幫忙想怎麼樣的預約與媒合流程可以讓使用者更方便,或者系統的其他部分應該要開發某些輔助機制,讓媒合的判斷品質提昇。

▋七宗罪之三:混淆真人與系統角色 ▋

第三個常見問題,許多 PRD 文件中會混淆「真實人物」與「系統角色」這兩種認知。

例如說,可能 PM 在需求訪談中,聽到了「請假流程會需要老闆 John 做最後的審核」,轉頭就在 PRD 寫下「John 對請假單進行最後審核」。

在實際開發中,若工程師真的按照此描述完美實現,反而會是一場悲劇。

首先是,如果公司現在是 10 個人,都是同一個 John 在審核,看起來沒問題,但這個公司只會有 10 個人嗎?

John 會不會有一天請了別人當人事主管,讓別人來審核?

這個軟體產品的相關權限,難道要綁定「John」這個人嗎?

產品服務當然要參考實際情境,但不能完全照搬。

在需求訪談的過程所聽到的人事物,除了名字本身(例如 John),還要了解背後的抽象意義(例如管理者),然後在撰寫 PRD 的時候,根據情境與業務邏輯的脈絡,對這些人事物進行適當的命名。

命名時需維持抽象程度,不能綁定在特定具體人事物上。

命名還要能幫助觀看者容易理解,具備明確的指向性。

▋七宗罪之四:突然發明嶄新的詞彙 ▋

閱讀 PRD 過程另外一個可怕的困擾,就是「語言不統一」。

同樣一件事情,在口語描述時喜歡稱為「開直播」。

在另外一個地方叫「一對一」。

換了一個情境時又稱呼為「課程」。

這三個描述都指向同一件事,寫入 PRD 當中就成為災難,搞不好最後做成三套東西。

對於同一件事情的命名來說,「課程」比「開直播」、「一對一」還好,因為課程的抽象意義可以同時涵蓋「開直播」(上課形式)、「一對一」(參與規則)。

另外,動詞的使用也需要固定。

例如僅僅一個課程,可能就會衍生出「安排課程」、「預約課程」、「建立課程」、「新增課程」⋯⋯等等五花八門的描述。

這些不同的動詞,對於閱讀 PRD 的人來說會造成困擾。

因為閱讀的人會想很多細節,萬一「安排課程」跟「預約課程」需要不同的功能流程怎麼辦?

所以在 PRD 的撰寫中,對於同一件事情的名詞要固定,就連搭配的動詞也應該挑選合適的詞彙,從一而終,減少胡思亂想的空間。

▋七宗罪之五:語意曖昧與廢話連篇 ▋

有一種痛苦的 PRD 閱讀體驗,就是「聽君一席話,如聽一席話。」

我看了一大堆敘述,但我不知道我看了什麼。

例如:「課程預約成功後,課程就被預約。」

又或者:「符合規則的預約在預約時需要遵守規則。」

PRD 撰寫時,並不是寫越多文字量越好,更多的文字反而是消耗閱讀者的認知心力,造成負擔。

但寫 PRD 的人也經常備受指責,被批評沒有寫清楚。

此時產生的認知偏誤,就是「寫越多代表越仔細」(另外就是,PRD 文件常常是在加班腦袋不清楚的狀況下寫。)

PRD 上的每一段文字,指向要明確,例如宣告使用者意圖、定義理想結果、描述業務邏輯、補充邊緣情境等等。

比起寫下很多混亂的想法,PRD 的每一段文字應該是幫助閱讀者搞懂一些事情。

少即是多。

▋七宗罪之六:混搭倒裝句與副詞子句 ▋

還有一種不舒適的 PRD 閱讀體驗,就是每一段文字既冗長又充滿各種條件子句,要理解這樣的文字段落,閱讀者的腦袋要同時建立一個流程圖的想像。

如果要說明的東西就是這麼複雜,那為什麼不畫流程圖就好???

比起「可安排的老師,根據學員分級測驗結果挑選。」(倒裝句)

更適合的描述是「根據學員分級測驗結果,安排老師。」(直述句)

比起「預約課程時根據學員分級測驗提供教材,配合學員進修主題興趣與老師教學領域並以學生時段為主進行選擇。」

更適合的寫法是:

  • 為學員安排老師進行線上一對一教學
  • 根據學員分級測驗提供教材
  • 根據學員進修主題,配對老師的教學領域
  • 以學員可上課時段,媒合老師可排課班表

撰寫 PRD 時,建議用直述句進行說明,並將複雜的想法拆解為條列式,以一行一述為原則。

▋七宗罪最後一條:描述機制需求時都在寫 UI 畫面 ▋

有一種 PRD 的撰寫風格,像是在手把手教你怎麼操作軟體。

例如:

  • 點擊帳號欄位,輸入 Email
  • 點擊密碼欄位,輸入 8 - 16 字串長度,英數混合字元
  • 按下確認
  • 展開提示視窗

雖然看起來很認真有條理,但這種書寫體的問題更大。

首先是軟體的互動邏輯可能很複雜,沒辦法用這樣的列點描述方式釐清互動邏輯,還不如用流程圖來溝通。

其次是在沒有畫面的情況下描述 UI 介面,閱讀者的認知負擔也很大,要自行在腦海中想像,那還不如等你畫了 wireframe 再來討論。

▋結語

許多人覺得自己煞費苦心寫出精美的 PRD 沒人看,但閱讀者其實也很痛苦,因為看不懂。

文字的理解需要動用系統二的後設思考,會大量消耗認知心力,特別是像軟體需求溝通這麼困難的議題。

寫 PRD 不是在寫文學作品,重點在實用。

因此,簡單易懂、脈絡清晰、意圖明確的書寫原則,幫助閱讀者輕鬆理解,人家才看得下去。

以上都是我自己踩過的雷,分享給各位,希望能幫助釐清為什麼 PRD 沒人想看的痛苦。

by Soking

Soking

千綺創意設計 Co-Founder / 產品設計總監,目前經營軟體領域的體驗設計顧問公司,也從事 UX 教學,喜歡以工作坊形式,引導你體驗 UX 領域的專業知識。 工作聯絡:service@soking.cc

Read more from Soking

A 提供某種資訊給 B 在特定情境下使用,軟體服務往往長成這副德性。 B2B 軟體的設計情境中,通常可以找到對應領域的專家,與專家一起協作進行知識萃取,將任務步驟解析出來。 by Soking

4 days ago • 1 min read

PRD 模版可以照填就好?」、「我又不會寫程式,要怎麼樣才能讓工程師看懂?」等等。 SPEC 規格文件,就像是在寫一道菜的食譜,你要描述輸入哪些原料、使用什麼工具、按照什麼順序、注意哪些狀況,最後輸出什麼結果。 UX writing 撰寫 CTA 時的參考。 2024/2/12」,最大的問題在於別人可能猜測不出來你指的是什麼日期? 2024/2/12」 更好的寫法是「發佈日期:2024/2/12」 spec 就像在寫食譜,因此順序很重要。 Edge case),就是那些發生概率低,但可能造成機制出問題的事情。 9點之前不能預約」 9點」並不是鐵律。 9點之前不能預約」(快速實現,但不容易改動) 8 個 SPEC 書寫原則分享給你,也歡迎你轉寄分享給其他你覺得需要的朋友。 by Soking

18 days ago • 1 min read
Share this post