2018-11-16
今天為大家更新《使用者體驗要素》的第四章——範圍層，功能規格和內容需求——功能規格說明
本小結關鍵詞：定義需求
主要觀點：無論什麼樣的需求，你需要定義的需求都可以分為這三個主要型別。
在範圍層，我們從討論戰略層面的抽象問題——“ 我們為什麼要開發這個產品?”——轉而面對一個新的問題：“我們要開發的是什麼?”，接下來我們就好好聊聊我們要開發的功能和內容是什麼。
功能和內容
如圖，在這裡，範圍層被“功能型產品”和“資訊型產品”分成兩個部分。在功能型產品方面，我們考慮的是功能需求規格( functional specifications)——哪些應該被當成軟體產品的“功能”以及相應的組合。在資訊型產品方面，我們考慮的是內容，這屬於編輯和營銷推廣的傳統領域。
內容和功能看去很像是兩個完全不同的事物，但是當它們在定義範圍層的時候，它們所用的方式是非常相似的。在本章中，我將使用一個詞“特性( feature)” 來同時表示軟體的功能和所提供的內容。
在軟體開發中，範圍層確定的是全部的功能需求或功能規格( functional specifications)。有些企業用這些術語來表示兩種不同的文件：在專案初期，這個詞表示需求，描述系統應該做什麼；在專案未期，這個詞表示功能規格說明，描述系統真正完成了什麼。在這種定義中，“功能規格”在“功能需求”確定之後才開始撰寫，同時將加入具體的實施細節。
但是大部分的時候，這兩個術語是可以互換的——事美上，有些人使用“功能需求規格”來表示他們的文件覆蓋了包括以，上兩者的內容。我將使用“功能規格說明書”來描述文件本身，而用“需求”來描述文件的內容。
本章所使用的詞彙大部分和軟體開發所使用的詞彙一樣。但是在這裡的概念同樣適用於內容開發。內容開發不會像軟體過程的需求收集一樣，總是那麼正式，但其基本原則是一樣的。內容設計者要坐下來仔細考最各種資料的來源，不管是一個資料庫還是滿滿一抽屜的剪報，然後才能決定哪些資訊必須納入設計範圍之內。這種定義內容需求(content requirements)的過程，實際上與技術專家和董事會集體商議功能需求，並回顧已有的文件記錄沒有本質上的區別。兩者的意圖和方法是一樣的。
內容需求常常伴隨著功能的需求。現在，真正的內容常常是通過一個內容管理系統(CMS)來進行管理的。這些系統大小不一，大的系統能根據眾多不同的資料來源動態生成頁面，龐大而複雜；小的可以是一個很輕巧的工具，能以最高效的方式來優化並管理各種型別的內容專題。你有可能會去購買一套專用的管理系統，或從眾多開放原始碼的備選方案中挑一個，甚至還想從零開始，自己做一個管理系統。不論用哪一種方式，在大部分情況下，你都必須對這個系統進行一些簡單的修補以適合你的企業和內容的需要。
內容管理系統必備的功能取決你將要管理的內容的性質。你是否需要維護多語言的文字內容?內容的基礎資料是否自帶格式?CMS就需要具有處理這些型別的內容元素的能力。你的每一篇新聞稿是否必須要通過六個執行副總裁和一個律師的稽核?CMS就需要在流程中支援這些型別的需求。你的內容元素是否要根據每一個使用者的喜好或訪問終端來動態地組合?那麼CMS就必須要能完成這一類高級別的複雜輸出。
類似地，功能需求或任何一種技術類產品也常常伴隨著內容的需求。在“個人喜好設定”的頁面中需要有使用說明嗎?需要有錯誤提示嗎?必須要有個專門的人來寫這些內容。每一次當我看到網頁上出現類似“無效輸人”的錯誤提示時，我就知道這種文字是出自開發工程師之手，併成為了最終產品，因為沒有人把這些錯誤提示納入內容需求中。而事實上，如果開發者能花一點點時間讓某些人看一看應用程式中的內容的話，無數的技術專案會因此得到極大的改善。
定義需求
一些需求適用於整個產品。品牌需求是最常見的一種：某些技術需求，比如支援瀏覽器和作業系統，是另一種。
另一些需求只適用於特殊的特性。大部分時候，當人們說到某種需求的時候，他們想的是產品必須擁有的、某種特性的一句簡短描述。
需求的詳略程度常常取決於該專案的具體範圍。如果該專案的目標是完成一個複雜的子系統，那麼就需要有一個非常詳細明確的需求，即使這個專案的範圍相對於整個網站來講非常小。相反地，一個大型專案，它的內容也許只是相似或相同性質的東西(比如提供大量功能相似的產品說明書的PDF檔案)，那麼內容需求只需要一般化就可以了。
最用之不竭的需求源泉總是來自使用者本身。但更多的時候，你的需求將來自與專案利益相關的同事一那些在企業中總想影響你的產品的人。
不管是哪種情況，去了解“人們在想什麼”的最佳途徑就是直接詢問他們。在第3章列出的使用者研究技術都可以用來幫助你更好地瞭解使用者，瞭解他們希望在你的產品上看到的特性的種類。
不管你是從企業內部的管理者，還是直接從使用者處獲得的幫助，來定義的這些需求， 這個過程中得到的需求將分成三個主要類別。首先，最顯而易見的是人們講述的、他們想要的東西。這中間有一部分是非常清晰的好想法，會通過各種途徑體現在最終產品上。
有時候人們口中說出來的、所期望的特性其實並不是他們想要的，當人們在某個過程或某個產品中遭遇到一些困難時，想象有某種解決辦法可以緩解這一困難，這對任何人來講都是很正常的反應。有時這個解決辦法是行不通的，或者僅僅是治標不治本的辦法。通過與使用者探討這些建議，你有時候可以得出能真正解決問題的、完全不同的需求。
在這個階段能得到的 第三種類型的需求是人們不知道他們是否需要的特性 。當你讓人們討論新的需求和戰略目標時，他們有時會突然想起某個偉大的構思，而根本忘記了那個正在維護中的產品。這些通常會在頭腦風暴討論的時候出現，那正是與會者有機會參與和探討專案的可能性的時候。
具有諷刺意味的是，那些很少去想象產品新方向的人，恰恰是參與建立和設計產品最深入的人。當你把所有的時間都投，入到維持現有產品時，你經常會忘掉哪些是真正的限制條件，而哪些是為了簡化產品而曾經做過的選擇。出於這個原因，彙集企業各個部門的成員或不同型別的使用者代表來進行頭腦風暴會議，是一種開啟設計者思路、讓他們考慮以前從未想到的可能性的、非常有效的工具。
讓一個工程師、一個客服人員、一個營銷人員坐到一會議室中談論同一個產品，這會對大家都有啟發意義。聽取從自己不熟悉的角度出發來考慮的、對於產品的觀點，並給予反饋，可以鼓勵人們多角度全方位地思考開發中的產品遇到的問題以及解決辦法。
不管你設計的產品在什麼樣的裝置上使用我們的需求序列必須要考慮到硬體需求。這個裝置有攝像頭嗎?有GPS嗎?有陀螺感應指標(一種用來測量或保持裝置座標資訊的裝置)嗎?這些因素都將會確立或限制產品功能的可能性。
通過這種方式討論出來的功能需求通常是得到如何去除某些障礙的方法。舉個例子來講，假設你有一個使用者已經決定要購買了——他們只是沒有決定是不是買你的產品，你設計的產品要怎樣才能讓這個過程(首先是選擇你的產品，然後買下它)對他們來講更容易呢?
在第3章，我們看到有一種叫作人物角色(personas)的技術，通過建立虛擬人物來幫助我們更好地理解使用者需求。在決定功能需求的時候，我們可以再次使用這些人物角色，把我們的虛擬人物放到一個簡短的故事之中，我們稱之為“場景(scenarios)”。一個場景是一個簡短的故事，簡單描述了一個人物角色會如何完成這些使用者需求。通過“想象我們的使用者將會經歷什麼樣的過程”，我們就可以找到能幫助他順利完成這個過程的潛在需求。
我們也期望從競爭對手處得到一些啟示。任何一個在做同一件事的企業基本上在試圖滿足同樣的使用者需求，同時也在試圖完成相似的產品目標。競爭對手是否找到一種特別有效的特性，能完成其中的某個戰略目標?他們是如何權衡和調整我們所面對的那些問題的?
即使不是產品的直接競爭對手也能提供豐富詢潛在看求例如一些遊戲平臺允許使用者建立自己人的社交群組，那麼在我們的數字錄影軟體，上採用相似的特性或建立類似的機制，也許就能給我們一 定的競爭優勢，用來超越直接競爭對手。
接下來，會為大家更新功能規格說明文件。敬請期待。