本章聚焦于五個(gè)層次中的范圍層，闡述了為什么需要進(jìn)行范圍層的設(shè)計(jì)、范圍層需要完成什么設(shè)計(jì)。本篇筆記共4137字，預(yù)計(jì)需要7分鐘完成閱讀。

盡管作者將功能與內(nèi)容型產(chǎn)品拆分開來進(jìn)行介紹，但范圍層的設(shè)計(jì)，實(shí)質(zhì)都是三步驟：明確需求+說明功能+明確優(yōu)先級(jí)
無論是內(nèi)容需求還是功能需求，設(shè)計(jì)中的表現(xiàn)形式可能不同，都需要還原需求的背景，明確需求，找出真實(shí)問題，無論拿到的需求級(jí)別高或低、來源是一手還是二手。
定義需求后，我們需要進(jìn)行功能說明。功能型產(chǎn)品通常使用功能規(guī)格說明書來具體地描述出需要實(shí)現(xiàn)的功能特性，內(nèi)容型產(chǎn)品則需要給出內(nèi)容特性的具體說明，包括內(nèi)容的類型、組合方式、大小等 ，并且最好明確內(nèi)容更新的長期負(fù)責(zé)人。
在梳理出功能后，我們還需要結(jié)合戰(zhàn)略目標(biāo)與需求的可行性，判斷需求優(yōu)先級(jí)。

如果說戰(zhàn)略層聚焦于“我們?yōu)槭裁匆_發(fā)這個(gè)產(chǎn)品”，那么范圍層主要回答的是“我們要開發(fā)的是什么”，也就是產(chǎn)品應(yīng)該提供給用戶什么樣的內(nèi)容和功能。

在 決策者對(duì)產(chǎn)品戰(zhàn)略方向的思考 與 產(chǎn)品經(jīng)理對(duì)新功能的設(shè)計(jì) 中間，我們還需要一個(gè)范圍的設(shè)計(jì)，從而保證項(xiàng)目如期交付。

對(duì)于大多數(shù)的互聯(lián)網(wǎng)產(chǎn)品，完整的產(chǎn)品功能應(yīng)當(dāng)是分階段實(shí)現(xiàn)的。另外，即使是瀑布流開發(fā)，我們同樣需要考慮清楚哪些feature需要、哪些不需要。
缺乏范圍層設(shè)計(jì)的開發(fā)過程很容易陷入“范圍蠕動(dòng)”，最終得到一個(gè)混合各個(gè)階段功能、永遠(yuǎn)是beta版本的產(chǎn)品。

范圍層是什么、我們?yōu)槭裁匆M(jìn)行范圍層的設(shè)計(jì)

范圍層的設(shè)計(jì)中，我們需要

• 定義并描述清楚 feature
• 確定項(xiàng)目的范圍
  • 記錄所有需要做的事情
  • 并在這個(gè)基礎(chǔ)上設(shè)計(jì)日程安排(schedule)與里程碑(milestones)

定義范圍層的過程和結(jié)果都是有價(jià)值的。定義范圍層的過程中，我們可以進(jìn)一步細(xì)化產(chǎn)品、考慮潛在沖突；定義范圍層的結(jié)果可以為團(tuán)隊(duì)提供參考、幫助大家實(shí)現(xiàn)項(xiàng)目范圍的控制。

范圍層的定義，簡單來說就是，“明白我們現(xiàn)在該做什么、不該做什么”：

1. 讓團(tuán)隊(duì)明白，我們?cè)诮ㄔO(shè)什么產(chǎn)品
   1. 將項(xiàng)目的目標(biāo)同步給整個(gè)團(tuán)隊(duì)
      1. 最終產(chǎn)品不再是一個(gè)①只停留在產(chǎn)品經(jīng)理頭腦中的、②不斷變化的模糊概念
      2. 這個(gè)產(chǎn)品形象將具體、明確、可傳達(dá)，可以被團(tuán)隊(duì)內(nèi)的所有人認(rèn)知，也支持團(tuán)隊(duì)內(nèi)部的所有人參與
   2. 提高團(tuán)隊(duì)的協(xié)作效率
      1. 范圍層可以明確項(xiàng)目中需要完成哪些工作、定義好團(tuán)隊(duì)內(nèi)對(duì)一項(xiàng)工作的共同語言
      2. 明確要求后，我們可以更清晰地拆分內(nèi)容、分配責(zé)任，提高協(xié)作效率、保障產(chǎn)品質(zhì)量
2. 讓團(tuán)隊(duì)明白，我們(現(xiàn)階段)不需要做什么
   1. 避免產(chǎn)品的范圍不斷擴(kuò)張，導(dǎo)致項(xiàng)目和費(fèi)用預(yù)算的過度膨脹
      1. 在“可能性”浮現(xiàn)出來之后，我們需要進(jìn)行評(píng)估；有些功能看起來很棒，但我們應(yīng)該結(jié)合戰(zhàn)略考慮，這是不是我們?cè)撟龅氖?、是不是我們?dāng)下該做的事
   2. 收集那些“不需要馬上做”的想法，作為未來的潛在功能
      1. 既保證產(chǎn)品的當(dāng)下的進(jìn)度與交付，同時(shí)也不會(huì)錯(cuò)過一些“很棒但是不符合現(xiàn)階段”的點(diǎn)子

版本管理

如何進(jìn)行范圍層的設(shè)計(jì)

之前提到，范圍層主要是①定義需求，②描述feature，③確定項(xiàng)目的范圍。設(shè)計(jì)的過程也主要是圍繞這三個(gè)目標(biāo)來開展。

從范圍層開始，由于功能型與信息型產(chǎn)品的側(cè)重點(diǎn)不同，體驗(yàn)要素設(shè)計(jì)上會(huì)分別進(jìn)行設(shè)計(jì)，正如 Chapter 2 的用戶體驗(yàn)要素與模型中所介紹，“范圍層”也劃分為了功能規(guī)格和內(nèi)容需求兩部分。

不過，在范圍層的定義中，兩類產(chǎn)品所用的方法是相似的。

• 本質(zhì)上，內(nèi)容開發(fā)在范圍層的設(shè)計(jì)工作與功能型軟件開發(fā)是一樣的——功能型軟件收集需求并商議功能需求，內(nèi)容涉及這也需要考量資料的來源、決定哪些信息必須納入設(shè)計(jì)范圍內(nèi)
• 內(nèi)容需求常伴隨功能的需求，而功能需求也常常伴有內(nèi)容的需求。功能與內(nèi)容相輔相成，而非對(duì)立
  • 內(nèi)容需要通過內(nèi)容管理系統(tǒng)/CMS進(jìn)行管理，而設(shè)計(jì)者需要根據(jù)內(nèi)容的性質(zhì)來設(shè)計(jì)和調(diào)整CMS系統(tǒng)，例如對(duì)CMS系統(tǒng)進(jìn)行功能的增補(bǔ)、流程的優(yōu)化
  • 功能型產(chǎn)品也需要對(duì)內(nèi)容進(jìn)行設(shè)計(jì)，例如錯(cuò)誤提示(個(gè)人感覺，即使是功能產(chǎn)品也有大量需要管理的內(nèi)容，典型如用戶信息)

在“定義——描述——優(yōu)先級(jí)排序與范圍確定”三個(gè)目標(biāo)中，功能規(guī)格和內(nèi)容需求設(shè)計(jì)在“描述feature”環(huán)節(jié)（即后續(xù)的功能規(guī)格說明部分）的注意點(diǎn)會(huì)略有不同，在方法上沒有太大差異。

在后續(xù)內(nèi)容中，我們將使用”功能規(guī)格說明書“指代說明功能與內(nèi)容的文檔，并使用“特性"feature"”對(duì)功能和內(nèi)容進(jìn)行統(tǒng)一描述。

定義需求

需求是有層級(jí)的。需求既可以是整個(gè)產(chǎn)品級(jí)別的，例如品牌需求；需求也可以是對(duì)某個(gè)feature的一句簡短描述。需求的詳略程度常取決于項(xiàng)目的具體范圍。

需求最根本的來源是用戶，Chapter 3用戶需求部分介紹的用戶研究方法是獲取用戶需求的常用方法。但工作中，我們的需求來源常常是與項(xiàng)目利益相關(guān)的同事（業(yè)務(wù)部門的二手需求、ld需求等）。

無論我們得到的是從用戶還是其他干系人獲得的“需求”，我們都不能直接按照對(duì)方描述的解法來設(shè)計(jì)功能：
用戶口中的“我希望有一個(gè)xx功能”，往往是針對(duì)使用中的某個(gè)困難所設(shè)想的解決辦法。而這個(gè)“解決方法”①不一定可以真正解決問題，②不一定是最佳的解法，③不一定符合我們產(chǎn)品的戰(zhàn)略，④不一定符合我們產(chǎn)品近期迭代的目標(biāo)方向。
因此，正確的做法是，①和提出需求/功能的人進(jìn)一步探討，確定ta遇到的真實(shí)問題（還原場景和需求），②設(shè)計(jì)解決方案，③結(jié)合產(chǎn)品戰(zhàn)略考慮要不要做，④結(jié)合近期迭代計(jì)劃采取什么程度的方案。

另外，產(chǎn)品經(jīng)理應(yīng)該保持對(duì)陷入固定思維的警惕——當(dāng)我們將所有時(shí)間都投入到維護(hù)現(xiàn)有產(chǎn)品中時(shí)，我們難免會(huì)被局限于產(chǎn)品的現(xiàn)狀，忘記了哪些是真正的限制條件、哪些是曾經(jīng)為了簡化產(chǎn)品做出的選擇。
可以采用的方法包括：

1. 對(duì)需求和曾經(jīng)做出的選擇進(jìn)行管理，供后續(xù)查看與溯源
2. 適時(shí)進(jìn)行頭腦風(fēng)暴會(huì)議討論功能需求，成員可以是其他部門的干系人，或不同類型的用戶代表
   1. 來自其他視角的觀點(diǎn)可以幫助大家多角度、全方位地匯總產(chǎn)品問題、思考解決辦法
   2. 可以從技術(shù)、市場等視角提前發(fā)現(xiàn)問題，并設(shè)計(jì)解決方案
3. 使用personas+scenarios的方法，想象角色在場景下完成需求所需要經(jīng)歷的過程，從而檢查流程的完整性、發(fā)現(xiàn)潛在需求
4. 通過分析競爭對(duì)手的特性，倒推他們滿足的用戶需求或產(chǎn)品目標(biāo)，并作為我們權(quán)衡和調(diào)整問題的參考（包括競品是否推出特別有效的feature、競對(duì)如何權(quán)衡兩項(xiàng)指標(biāo)等等）；另外，非競對(duì)的其他類型產(chǎn)品也可能會(huì)啟發(fā)我們的思考

功能規(guī)格說明

人們往往對(duì)功能規(guī)格說明書抱有負(fù)面態(tài)度——程序員不愿意閱讀枯燥且冗長的說明，撰寫者也不愿意浪費(fèi)時(shí)間撰寫“沒人讀的文檔”。

但是，作為需求傳遞的文檔，功能規(guī)格說明書是有價(jià)值且必須存在的。

功能規(guī)格說明書“沒人讀”的一個(gè)重要原因是，產(chǎn)品在實(shí)施過程中往往會(huì)發(fā)生變化，因此讓人感覺“功能規(guī)格說明書并不會(huì)體現(xiàn)最終產(chǎn)品”，進(jìn)而感覺“功能規(guī)格說明書是無用的”。

解決“撰寫的功能規(guī)格說明書沒有價(jià)值”這個(gè)問題，正確的解法不是“不撰寫”，而是思考如何避免說明書與最終產(chǎn)品的差距，并且想辦法讓文檔的利用率提升

1. 文檔的撰寫應(yīng)當(dāng)與產(chǎn)品的開發(fā)過程相結(jié)合
   1. 讓撰寫的過程變得快速簡便，適時(shí)更新文檔，從而保證文檔與產(chǎn)品是相匹配的
2. 文檔重點(diǎn)不在于詳細(xì)，而在于清楚和準(zhǔn)確
   1. 功能規(guī)格說明不需要包括產(chǎn)品的每一個(gè)細(xì)節(jié)，只需要保證功能的清晰不混淆
   2. 當(dāng)前的文檔不需要展望產(chǎn)品未來的理想化狀態(tài)，只需要記錄目前已確定的決議

針對(duì)功能規(guī)格設(shè)計(jì)的幾個(gè)小 tips

這些與其說時(shí)給說明書的建議，更多的是針對(duì)設(shè)計(jì)本身的建議

1. be positive：文檔應(yīng)從正向去描述系統(tǒng)需要采取的措施(例如異常或邊界狀態(tài))，而不應(yīng)該簡單描述系統(tǒng)的禁用范圍
   例如，“系統(tǒng)不允許用戶購買沒有風(fēng)箏線的風(fēng)箏”，可以被替換為“當(dāng)用戶想購買沒有風(fēng)箏線的風(fēng)箏時(shí)，系統(tǒng)應(yīng)引導(dǎo)用戶至風(fēng)箏線界面”
2. be specific：文檔應(yīng)具體地對(duì)功能進(jìn)行詳細(xì)說明
   例如，“重點(diǎn)標(biāo)注出最受歡迎的視頻”不夠明確具體、缺乏對(duì)目標(biāo)和評(píng)判標(biāo)準(zhǔn)的定義，應(yīng)該修正為“在列表的最前端顯示上周播放數(shù)最高的視頻”
3. avoid subjective language：文檔應(yīng)避免出現(xiàn)主觀的描述說明——功能需求應(yīng)明確、無歧義、可驗(yàn)證，不會(huì)因?yàn)閭€(gè)人評(píng)判標(biāo)準(zhǔn)而偏移
   例如，“網(wǎng)站的風(fēng)格應(yīng)該是時(shí)尚閃耀亮眼的”，這就過于主觀了，每個(gè)人對(duì)時(shí)尚和亮眼的評(píng)判標(biāo)準(zhǔn)都是不同的，“這個(gè)網(wǎng)站應(yīng)符合郵遞員wayne所期望的時(shí)尚”就會(huì)變得可驗(yàn)證，而“網(wǎng)站的外觀應(yīng)符合企業(yè)的品牌指南文檔”將完全避免需求本身的主觀性。除了引用參考指南，我們還可以通過量化定義來避免需求的主觀性

針對(duì)內(nèi)容需求設(shè)計(jì)的幾個(gè)小 tips

個(gè)人認(rèn)為上述很多方法對(duì)內(nèi)容需求的定義與功能設(shè)計(jì)同樣有參考價(jià)值。例如，功能設(shè)計(jì)可能也不局限于真的設(shè)計(jì)出某個(gè)function，可能可以通過和站外信息聯(lián)動(dòng)解決需求等等

1. “內(nèi)容”不局限于文本，我們需要考慮所有所需內(nèi)容的類型
   1. 圖像、音頻、視頻也是內(nèi)容。需要提前確定好內(nèi)容的類型、設(shè)計(jì)呈現(xiàn)的組合方式、確定需要哪些資源
2. 設(shè)計(jì)內(nèi)容時(shí)不要混淆其格式和目的，關(guān)注內(nèi)容設(shè)計(jì)背后的真實(shí)需求
   比方說，內(nèi)容設(shè)計(jì)中常遇到一個(gè)需求-“我們應(yīng)當(dāng)有FAQ”。設(shè)計(jì)過程中如果只關(guān)注其格式(一系列簡短的問答)，我們很可能會(huì)遺忘其目的，最終只是做出了AQ，忽略了“常見”這個(gè)點(diǎn)；如果聚焦于真實(shí)需求，我們就會(huì)發(fā)現(xiàn)，F(xiàn)AQ的真實(shí)價(jià)值是“隨時(shí)提供用戶普遍需要的信息”，甚至我們可以不采用問答的格式（例如飛書多維表格使用頁內(nèi)icon+gif完成了教學(xué)和問題解答）
3. 在設(shè)計(jì)內(nèi)容、明確內(nèi)容需求時(shí)，我們需要給出每個(gè)特性的規(guī)模的大致預(yù)估，因?yàn)閮?nèi)容特性的大小將會(huì)對(duì)設(shè)計(jì)中的決策產(chǎn)生巨大影響
   典型如，如果使用的圖片素材普遍為高清晰度img，那么可能需要考慮性能問題以及交互優(yōu)化方案了。
4. 內(nèi)容特性的交付通常不是一次性的
   1. 內(nèi)容特性的執(zhí)行可能比策劃更重要。假想階段看起來很不錯(cuò)的內(nèi)容特性，有可能會(huì)因?yàn)閷?shí)際執(zhí)行中出現(xiàn)的問題而效果不佳——除了初次上線外，我們還需要策劃后續(xù)的內(nèi)容更新，從而保證網(wǎng)站長期滿足用戶需求
   2. 設(shè)計(jì)時(shí)應(yīng)對(duì)每一個(gè)內(nèi)容特性的“更新頻率”進(jìn)行定義。更新頻率取決于產(chǎn)品的戰(zhàn)略目標(biāo)，并結(jié)合用戶期望和有效資源取一個(gè)合理的值
   3. 設(shè)計(jì)時(shí)最好指定內(nèi)容特性和元素的負(fù)責(zé)人，保證對(duì)應(yīng)的內(nèi)容需求可以得到建設(shè)和維護(hù)
5. 當(dāng)網(wǎng)站的用戶存在不同的需求時(shí)，網(wǎng)站應(yīng)當(dāng)為不同的用戶角色準(zhǔn)備不同的內(nèi)容和呈現(xiàn)方式，例如涉及到讀者、寫手兩種角色的小說網(wǎng)站可能需要分化處理內(nèi)容
6. 內(nèi)容需求量較為龐大時(shí)，建議整理內(nèi)容清單(content inventory)

確定需求優(yōu)先級(jí)

在定義需求和功能規(guī)格說明兩個(gè)步驟中，我們完成了對(duì)潛在的需求以及特性思路的收集。在這之后，我們需要確定需求的優(yōu)先級(jí)，并為“目前項(xiàng)目中應(yīng)包含的功能”劃定一個(gè)明確的范圍。

需求的優(yōu)先級(jí)主要取決于兩大方面——是否滿足戰(zhàn)略目標(biāo)&需求的可行性。
戰(zhàn)略目標(biāo)也就是Chapter 3：戰(zhàn)略層-產(chǎn)品目標(biāo)和用戶需求。我們需要評(píng)估需求是否可以滿足網(wǎng)站目標(biāo)或用戶需求。戰(zhàn)略目標(biāo)和需求可能時(shí)多對(duì)多的關(guān)系。

在審視需求、確定優(yōu)先級(jí)的過程，一定要關(guān)注戰(zhàn)略目標(biāo)：

• 不符合當(dāng)前項(xiàng)目的戰(zhàn)略目標(biāo)的特性均需要被排除
  • 在這個(gè)基礎(chǔ)上，如果與戰(zhàn)略不符的“好點(diǎn)子”反復(fù)出現(xiàn)、甚至引發(fā)我們對(duì)戰(zhàn)略的反復(fù)審視，那么，我們可能需要回到戰(zhàn)略層重新確定
• 戰(zhàn)略目標(biāo)的優(yōu)先級(jí)可以成為需求優(yōu)先級(jí)的首要參考因素

可行性的評(píng)估包括①在當(dāng)前的科技背景下，需求是否可實(shí)現(xiàn)，②當(dāng)前階段的資源是否可以支持。由于時(shí)間等資源而無法實(shí)現(xiàn)的特性可以被放在后續(xù)的版本更新中。

另外，feature間往往存在依賴關(guān)系，不能孤立考慮單個(gè)需求。