當你把用戶需求和產(chǎn)品目標轉(zhuǎn)變成產(chǎn)品應(yīng)該提供給給用戶什么樣的內(nèi)容和功能時镇饮，戰(zhàn)略就變成了范圍际歼。
一术羔、范圍層定義
項目范圍在做兩件事：這是一個有價值的過程，同時能產(chǎn)生有價值的產(chǎn)品寞焙。
1.過程的價值在于储狭，當整個事情還處在假設(shè)階段的時候，它能迫使你去考慮潛在的沖突和產(chǎn)品中一些粗略的點捣郊。我們能確定現(xiàn)在能解決哪些事情辽狈，而哪些必須要再遲一點才能解決。
2.產(chǎn)品的價值在于呛牲，被定義的這個產(chǎn)品給了整個團隊一個參考點刮萌，明確了這個項目中要完成的全部工作，它也提供了一門用于討論這件事情的共同的語言娘扩。定義好你的要求能保證在設(shè)計過程中不會出現(xiàn)模棱兩可的情況着茸。
用文檔來定義產(chǎn)品需求，這件事很麻煩琐旁，但是你必須要做涮阔。這是由于以下兩個主要原因：
原因1:這樣你才知道你正在建設(shè)什么
如果詳細地記錄下你正在建設(shè)的內(nèi)容，每個人就會知道這個項目的目標是什么旋膳，什么時候?qū)⑦_到這個目標澎语。最終產(chǎn)品不再是一個只停留在產(chǎn)品經(jīng)理頭腦里的不定型的圖像，它變成了一個在企業(yè)內(nèi)部的每一個級別的每一個人都觸手可及的東西验懊，人人都能參與進來擅羞。
原因2:這樣你才知道你不需要建設(shè)什么
許多功能聽上去都相當?shù)卣T人，但是它們對于項目的戰(zhàn)略目標并不是必需的义图。此外减俏，所有在項目開始如火如荼地迂進行時，關(guān)于功能的各種各樣的可能性都會浮現(xiàn)出來碱工。當這些想法出現(xiàn)的時候娃承，用一個文檔來記錄它們奏夫，可以為你提供一個評估這些想法的架構(gòu)，幫助你了解他們是如何（或是否）滿足你當初所承諾要做的那些事历筝。
當前難以滿足的需求酗昼，可以成為啟動下一個版本的基礎(chǔ)，這樣就能形成一個不斷循環(huán)的開發(fā)過程梳猪。
二麻削、功能和內(nèi)容
在范圍層，我們從討論戰(zhàn)略層面的抽象問題——“我們?yōu)槭裁匆_發(fā)這個產(chǎn)品春弥？”轉(zhuǎn)而面對一個新的問題：“我們要開發(fā)的是什么呛哟？”
在軟件開發(fā)中，范圍層確定的是全部的功能需求或功能規(guī)格匿沛。在項目初期扫责，這個詞表示需求，描述系統(tǒng)應(yīng)該做什么逃呼；在項目末期鳖孤，這個詞表示功能規(guī)格說明，描述系統(tǒng)真正完成了什么蜘渣。
1.內(nèi)容需求
內(nèi)容設(shè)計者要坐下來仔細考量各種資料的來源淌铐，然后才能決定哪些信息必須納入設(shè)計范圍之內(nèi)肺然。這種定義內(nèi)容需求的過程蔫缸，實際上與技術(shù)專家和董事會集體商議功能需求，并回顧已有的文檔記錄沒有本質(zhì)上的區(qū)別际起。兩者的意圖和方法是一樣的拾碌。
2.內(nèi)容管理系統(tǒng)
現(xiàn)在，真正的內(nèi)容常常是通過一個內(nèi)容管理系統(tǒng)來進行管理的街望。這些系統(tǒng)大小不一校翔，大的系統(tǒng)能根據(jù)眾多不同的數(shù)據(jù)來源動態(tài)生成頁面，龐大而復(fù)雜灾前；小的可以是一個很輕巧的工具防症，能以最高效的方式來優(yōu)化并管理各種類型的內(nèi)容專題。
三哎甲、定義需求
需求的詳略程度常常取決于該項目的具體范圍蔫敲。最用之不竭的需求源泉總是來自用戶本身。但更多的時侯炭玫，你的需求將來自與項目利益相關(guān)的同事—那些在企業(yè)中總想影響你的產(chǎn)品的人奈嘿。
獲得需求的幾種類型：
（1）首先，最顯而易見的是人們講述的吞加、他們想要的東西裙犹。
（2）有時候人們口中說出來的尽狠、所期望的特性其實并不是他們想要的，遇到問題時想出的解決辦法是行不通的叶圃，或者僅僅是治標不治本的辦法袄膏。通過與用戶探討這些建議，你有時候可以得出能真正解決問題的掺冠、完全不同的需求哩陕。
（3）當你讓人們討論新的需求和戰(zhàn)略目標時，他們有時會突然想起某個偉大的構(gòu)思赫舒，而根本忘記了那個正在維護中的產(chǎn)品悍及。這些通常會在頭腦風暴討論的時候出現(xiàn)，那正是與會者有機會參與和探討項目的可能性的時候接癌。
（4）讓一個工程師心赶、一個客服人員、一個營銷人員坐到一間會議室中談?wù)撏粋€產(chǎn)品缺猛，這會對大家都有啟發(fā)意義缨叫。聽取從自己不熟悉的角度出發(fā)來考慮的、對于產(chǎn)品的觀點荔燎，并給予反饋耻姥，可以鼓勵人們多角度全方位地思考開發(fā)中的產(chǎn)品遇到的問題以及解決辦法。
（5）不管你設(shè)計的產(chǎn)品在什么樣的設(shè)備上使用（或者我們正在設(shè)計的就是那個設(shè)備）我們的需求序列必須要考慮到硬件需求有咨。
（6）在決定功能需求的時候琐簇，我們可以使用用戶畫像，把我們的虛擬人物放到一個簡短的故事之中座享，描述了一個人物角色會如何完成這些用戶需求婉商。通過“想象我們的用戶將會經(jīng)歷什么樣的過程”，我們就可以找到能幫助他順利完成這個過程的潛在需求渣叛。
（7）我們也期望從競爭對手處得到一些啟示丈秩。任何一個在做同件事的企業(yè)基本上在試圖滿足同樣的用戶需求，同時也在試圖完成相似的產(chǎn)品目標淳衙。
四蘑秽、功能規(guī)格說明
我們需要的不是文檔有多厚或有多詳細，而是要足夠清楚和準確箫攀。功能規(guī)格說明不需要包含產(chǎn)品的每一個細節(jié)肠牲，只需要包含在設(shè)計或開發(fā)過程中出現(xiàn)有可能混淆的功能定義。同時功能規(guī)格說明也不需要展望產(chǎn)品未來的理想化狀態(tài)—只需要記錄在創(chuàng)建這個產(chǎn)品時已經(jīng)確定下來的決議匠童。
功能規(guī)格說明的幾條規(guī)則：
1.樂觀
描述這個系統(tǒng)將要做什么事去“防止”不好的情況發(fā)生埂材，而不是描述這個系統(tǒng)“不應(yīng)該”做什么不好的事情。
2.具體
盡可能詳細地解釋清楚狀況汤求，這是我們能決定一個功能是否被實現(xiàn)的最佳途徑俏险。
3.避免主觀的語氣
這是另外一種使需求“保持明確”和“避免歧義”的途徑—因而也避免了誤解的可能性严拒。
五、內(nèi)容需求
1.定義和范圍
很多時候我們說到的內(nèi)容指的是文本竖独。但是圖像裤唠、音頻和視頻有時候有可能比其文字還要重要。這些不同類型的內(nèi)容可以結(jié)合到一起莹痢，相互協(xié)作去滿足某一個需求种蘸。
2.注意事項
（1）不要混淆某段內(nèi)容的格式和的目，當關(guān)注點是格式時竞膳，目的本身就可偷可能被遺忘航瞭。多半的結(jié)果是FAQ（常見問題）忽略了這個詞匯中“常見”兩個字，內(nèi)容設(shè)計者總是用其他一些問題的答案替代了能真正滿足FAQ需求的答案坦辟。
（2）內(nèi)容特性想要達到的規(guī)模刊侯，將對你所做出的用戶體驗決策產(chǎn)生極大的影響。內(nèi)容需求應(yīng)該提供每一個特性規(guī)模的大致預(yù)估：文本的字數(shù)锉走、圖片的像素大小滨彻、下載的文件字節(jié)、PDF或挪蹭；音頻文件等相對獨立元素的大小等亭饵。這些大小的估計不一定要非常精確一大致相近即可。
（3）盡可能早地確定某個人負責每一個內(nèi)容元素也是非常重要的梁厉。如果我們在沒有確定誰將會負責這些內(nèi)容需求的情況下辜羊，過早過多地投入到開發(fā)流程中去，那么最后我們得到的很可能就是一個千瘡百孔的產(chǎn)品懂算，因為那些在假想階段人人都喜歡的特性只冻，將在實際執(zhí)行的時候變得非常沉重庇麦。
（4）從你的網(wǎng)站目標來看计技，你希望用戶多長時間來訪問一次？從你的用戶需求來看山橄，他們希望多長時間更新一次信息垮媒？無論如何，對于你的用戶而言較為理想的更新頻率（“我要馬上了解每一件事航棱，24小時服務(wù)睡雇！”）也許對你的企業(yè)來說不切合實際。但你必須要確定一個頻率饮醇，它是介于你的用戶期望值和有效資源之間的一個合理的中間值它抱。
（5）如果你的網(wǎng)站是為各為各種擁有相異需求的用戶服務(wù)的，搞楚哪些用戶想要哪種內(nèi)容朴艰，能幫助你決定用什么方式來呈現(xiàn)這些內(nèi)容观蓄。
（6）對于那些已有大量內(nèi)容的項目而言混移，很多關(guān)于內(nèi)容的信息都記一個內(nèi)容清單中。這樣團隊中的每個人才能確切地知道他們設(shè)計用戶體驗需要做哪些工作了侮穿。
六歌径、確定需求優(yōu)先級
有時一個戰(zhàn)略目標將產(chǎn)生多個需求（左圖）。另一方面亲茅，一個需求也可以實現(xiàn)多個戰(zhàn)略目標（右圖）回铛。
由于項目范圍是建立在戰(zhàn)略層的基礎(chǔ)上的，因此我們應(yīng)該去評估這些需求是否能滿足我們的戰(zhàn)略目標（無論是網(wǎng)站目標還是用戶需求）克锣。除了這兩種目標茵肃，我們還要額外確定第三種范圍：實現(xiàn)這些需求的可行性有多大？
需求實現(xiàn)的可行性
（1）如果是因為時間有限袭祟，那你可以把這個特性放到下一個版本或項目中免姿。如果是資源有限，則技術(shù)或企業(yè)的變化有時能減少資源的負擔榕酒，從而使某個特性能得以實現(xiàn)胚膊。
（2）很少有功能是獨立存在的，甚至產(chǎn)品的內(nèi)容也必須要依賴其他特性的支持想鹰，并告訴用戶怎樣最好地利用產(chǎn)品所提供的內(nèi)容紊婉。這不可避免地導致了特性之間的沖突。有些特性要和其他的一起權(quán)衡辑舷，才能得到一個連貫的喻犁、統(tǒng)一的產(chǎn)品。
（3）留意那些看上去有可能需要改變戰(zhàn)略的特性建議何缓。任何不符合當前項目的戰(zhàn)略目標的特性建議肢础，都要通過范圍定義將其排除出去 。不管怎么樣碌廓，如果你發(fā)現(xiàn)自己正在反復(fù)審視戰(zhàn)略目標传轰，那么你極有可能是太早地進入了需求定義階段。
（下一章預(yù)告：結(jié)構(gòu)層——交互設(shè)計與信息架構(gòu)）
