確定需求優先順序，評估需求是否能滿足戰略目標以及實現的可行性
今天為大家更新《使用者體驗要素》的第四章——範圍層——確定需求優先順序
本小結關鍵詞：確定需求優先順序
主要觀點：確定需求優先順序，評估需求是否能滿足戰略目標以及實現的可行性
前兩節我們講了如何去定義需求，並如何寫好一個功能規格說明文件定，今天我們聊聊如何確定需求優先順序。
內容需求
很多時候我們說到的內容指的是文字。但是影象、音訊和視訊有時候有可能比其文字還要重要。這些不同型別的內容可以結合到一起，相互協作去滿足某一個需求。比如說，一個涵蓋了運動賽事的內容專題，它可能是一篇附有照片的文章以及視訊片段。定義出所有不同型別的內容，可以幫助你確定需要哪些資源來製作這些內容(或它們是否應該被提供)。
不要混淆某段內容的格式和它的目的。當我和管理層討論內容需求的時候，所聽到的第一件事往往是:“我們應該有FAQ ( Frequently Asked Questions:常見問題)。”但是“FAQ”這個詞僅僅指的是內容的格式：一個系列簡短的問題和回答。一個FAQ給予使用者的真正價值，在於它可以隨時提供使用者普遍需要的資訊。其他的內容需求也可以滿足同樣的目的；但是當關注點是格式時，目的本身就可能被遺忘。多半的結果是，FAQ忽略了這個詞彙中“常見”兩個字，內容設計者總是用其他一些問題的答案替代了能真正滿足FAQ需求的答案。
內容特性想要達到的規模，將對你所做出的使用者體驗決策產生極大的影響。內容需求應該提供每一個特性規模的大致預估：文字的字數、圖片的畫素大小、下載的檔案位元組、PDF或音訊檔案等相對獨立元素的大小等。這些大小的估計不一定要非常精確，大致相近即可。我們只收集最緊要的關鍵資料，用於設計適當的工具來管理內容。設計一個只有小縮圖圖片的產品，與設計一個提供原始尺寸圖片的產品是完全不一樣的；事先知道這些內容元素的大小，能讓我們在這個設計過程中做出最明智的決策。
儘可能早地確定某個人來負責每一個內容元素也是非常重要的。一旦某個內容特性被大家所認可，確定其對戰略目標是有效的，它都會不可避免地被當成一個好主意——只要是別人來負責建設和維護它。如果我們在沒有確定誰將會負責這些內容需求的情況下，過早過多地投入到開發流程中去，那麼最後我們得到的很可能就是一個千瘡百孔的產品，因為那些在假想階段人人都喜歡的特性，將在實際執行的時候變得非常沉重。
而這正是人們在確定需求的時候常常忘記的事情：內容是一件艱苦的工作。也許你可以找一些合作的資源來為網站的初次上線及時地準備好一些內容(或者，更有可能指定某個市場人員來完成這個工作)，但是誰來更新它們呢?內容(嗯，應該說，有效的內容)需要日常維護工作。如果在做內容規劃的時候，你認為它們只需要釋出一次，之後再也不用更新的話，那麼隨著時間的推移，這個網站就越來越難以滿足使用者的需求。
這就是為什麼你應該定義每一個內容特性的“更新頻率”的原因。更新頻率應該來自於你產品的戰略目標：從你的網站目標來看，你希望使用者多長時間來訪問一次?從你的使用者需求來看，他們希望多長時間更新一次資訊?無論如何，要記住，對於你的使用者而言較為理想的更新頻率(“我要馬上了解每一件事，24小時服務!”)也許對你的企業來說不切合實際。但你必須要確定一個頻率，它是介於你的使用者期望值和有效資源之間的一個合理的中間值。
如果你的網站是為各種擁有相異需求的使用者服務的，搞清楚哪些使用者想要哪種內容，能幫助你決定用什麼方式來呈現這些內容。“為孩子們準備的資訊”與“為他們的父母準備的資訊”是兩種完全不同的方式；而“為所有人準備的資訊”則應該是第三種處理方式。
對於那些已有大量內容的專案而言，很多關於內容的資訊都記錄在一個內容清單( content inventory)中。整理一個現有網站中所有內容的清單看上去像是一件枯燥無味的事——確實也是如此。但是整理出這個清單(它通常採用一種簡單的格式，即使是一個非常龐大的電子表格)是很重要的，其原因和我們必須要搞清楚具體需求一樣重要：這樣團隊中的每個人才能確切地知道他們設計使用者體驗需要做哪些工作了。
確定需求優先順序
收集潛在的需求或想法不是很困難。幾乎每一個經常接觸產品的人(不管他們是企業內部還是外部的人)都能說出至少一個“這個產品應該增加哪些特性”的某個想法。最棘手的部分是排列出哪些功能應該包含到你現在的這個專案中去。
在戰略目標和需求之間，你幾乎看不到一對一的簡單關聯。有時一個需求可以滿足多個戰略目標。同樣，一個戰略目標也常常關係到多個不同的需求。
由於專案範圍是建立在戰略層的基礎上的，因此我們應該去評估這些需求是否能滿足我們的戰略目標(無論是網站目標還是使用者需求)。除了這兩種目標，我們還要額外確定第三種範圍：實現這些需求的可行性有多大?
有些特性可能會因為技術上的侷限而無法實現，舉例子來說，現在還完全沒有辦法讓使用者能聞到網頁上的產品，無論他們是如何渴望這個功能。另外一些特性( 尤其是內容方面的)之所以不可行，則是因為它們需要很多資源去做(無論是人力還是財力)這超出了我們的能力範圍。而有時候，僅僅是因為時間不夠：這個特性需要花費3個月來完成，但是企業的管理層要求在兩個月以後上線。
如果是因為時間有限，那你可以把這個特性放到下一個版本或專案里程中。如果是資源有限，則技術或企業的變化有時能減少資源的負擔(但是重要的是，並不總是)，從而使某個特效能得以實現(無論如何，不可能的事情仍然不可能實現，這很遺憾)。
很少有功能是獨立存在的。甚至產品的內容也必須要依賴其他特性的支援，並告訴使用者怎樣最好地利用產品所提供的內容。這不可避免地導致了特性之間的衝突。有些特性要和其他的一起權衡，才能得到一個連貫的、統一的產品。舉例來說，一些使用者也許想要一步提交訂單的過程——但是網站所使用的、混亂的老資料庫無法適應這個需要。採用多個步驟的流程是更好的辦法，也許你也可以重新設計資料庫系統?這完全取決於你的戰略目標是什麼。
留意那些看上去有可能需要改變戰略的特性建議，它們在制定願景文件期間並不明顯。任何不符合當前專案的戰略目標的特性建議，都要通過範圍定義將其排除出去。但是如果有那麼一個特性，儘管它不在專案範圍之內，也超越了任何一個的限制條件，但聽起來仍然像一個不錯的想法，那麼此時你可能需要重要審視某些戰略目標。不管怎麼樣，如果你發現自己正在反覆審視戰略目標，那麼你極有可能是太早地進入了需求定義階段。
如果你的戰略計劃或願景文件在戰略目標的範圍內制定了令一個清晰的優先級別順序，那麼這些優先級別應該是決定是否採納人們所建議的相關特性的首要因素。有時候，兩個不同戰略目標之間的重要程度也會出現不是很清楚的情況。這時候，特性最後是否能納人專案範圍之中，往往取決於企業的政治局面。
當管理層談到戰略的時候，他們通常從某種產品特性開始，然後你不得不耐心地把他們引導到後面的戰略因素上去。由於管理層常常分不清特性和戰略，某些特性總是會佔據上風。因此需求的定義過程就變成了與這些管理層進行談判的過程。
控制談判的過程會非常困難。解決管理層之間的爭論的最好辦法是要求“制定戰略”。關注戰略目標，而不是各種實現這些目標的手段。當你面對的是一個總是把注意力放在某個戰略目標特徵上的高層決策者，如果你能向他保證他所關注的這個特徵可以用另一個方式來滿足的話，他就不會感覺自己的意見被忽略了。不過，說起來容易做起來困難。對決策者的需求表示認同，是解決特性衝突的關鍵。誰說技術人員不需要溝通技巧呢?