本系列文章全部是筆者關(guān)于《用戶體驗要素——以用戶為中心的產(chǎn)品設(shè)計》一書所做出的概括總結(jié)壮吩，感興趣的讀者可以自己去查看書本
上篇地址：用戶體驗要素（二）：戰(zhàn)略層
1 我們?yōu)槭裁葱枰龇秶x？
很多時候我們有一個固定的工作流程，但是沒有日程安排嫉父，沒有里程碑，項目怎么也看不到盡頭馁启。因為根本沒有人知道這個項目的范圍养匈，所以也沒有人知道它會在什么時候結(jié)束坯癣。
產(chǎn)品或者網(wǎng)站的范圍定義是需要基于產(chǎn)品需求的瓶盛，這個需求需要落實在文檔而不是某個人的腦海里。
- 這樣你和團隊成員才知道你在建設(shè)什么
- 這樣你和團隊成員才知道你們不需要建設(shè)什么
同時示罗，范圍的確定能夠幫助我們有效的管理整個項目的進程惩猫，防止陷入某個可拍的范圍蠕動中。
2 范圍層到底是什么？
在戰(zhàn)略層绍绘，我們討論的是“我們?yōu)槭裁匆_發(fā)這個產(chǎn)品奶镶？”
而在范圍層，我們則需要探討“我們開發(fā)的是什么陪拘？”
如上圖所示厂镇，范圍層被“功能型產(chǎn)品”和“信息型產(chǎn)品”分成兩個部分。在功能型產(chǎn)品方面左刽，我們考慮的是功能規(guī)格——哪些應(yīng)當(dāng)被當(dāng)成軟件產(chǎn)品的功能以及相應(yīng)的組合捺信。在信息型產(chǎn)品方面，我們考慮的是內(nèi)容欠痴，屬于編輯和營銷推廣的傳統(tǒng)領(lǐng)域迄靠。
- 在軟件開發(fā)中，范圍層確定的是全部的功能需求或功能規(guī)格（function specifications）喇辽。在項目初期掌挚，我們定義功能需求，即這個軟件或者系統(tǒng)應(yīng)該做什么菩咨。而在項目末期疫诽，我們需要描述這個系統(tǒng)真正完成了什么。
- 內(nèi)容需求側(cè)通常伴隨著功能需求旦委，一般我們會用CMS系統(tǒng)來做內(nèi)容管理。
3 如何定義需求
從內(nèi)部管理者和用戶處獲得雏亚。這個過程中我們會得到三種類型的需求：
a. 人們講述的缨硝，他們想要的東西。
b. 人們在使用產(chǎn)品過程中遭受到某種困難罢低，通過他們說出來的實際上是他們本能想到的某些解決方法而不是真正的問題或者需求查辩。因此還需要的分析用戶說出的問題本質(zhì)胖笛，發(fā)掘本質(zhì)需求
c. 人們不知道他們是否需要的特性。通過用戶角色建模宜岛，幫助我們更好的理解用戶需求
從競爭對手處獲得一些啟示长踊，就是我們常說的競品分析。
4 確定需求的優(yōu)先級
主要兩點：
- 這個需求能否滿足我們的戰(zhàn)略目標(biāo)
- 實現(xiàn)這些需求的可能性有多大（時間上萍倡、資源上）
5 需求文檔
關(guān)于需求文檔身弊，作者提出了幾個準(zhǔn)則，筆者也覺得十分受用
Positive 描述系統(tǒng)應(yīng)該做什么列敲，而不是不應(yīng)該做什么
【錯誤】這個系統(tǒng)不允許用戶購買沒有風(fēng)箏線的風(fēng)箏
【正確】如果用戶想買一個沒有線的風(fēng)箏的話阱佛，這個系統(tǒng)應(yīng)該引導(dǎo)用戶到風(fēng)箏線頁面
Specific 盡可能的詳細
【錯誤】最受歡迎的視頻要重點標(biāo)注
【正確】上一周被播放最多的視頻要顯示在列表的最前端
Avoid Subject Language 避免主觀語氣。功能規(guī)格必須可驗證戴而，也就是說它必須要能被證明“這個需求有沒有被滿足”
【錯誤】這個網(wǎng)站的風(fēng)格應(yīng)該是時尚凑术，閃耀的
【正確】網(wǎng)站的外觀應(yīng)該符合企業(yè)的品牌指南文檔
最后筆者還想加一句，寫完需求文檔后最好站在團隊成員所意，或者一個對項目不怎么了解的角色角度去閱讀淮逊，看看你的需求文檔是否說的明白清楚，別人是否能看明白扶踊。
說到底泄鹏，需求文檔，是給別人看的姻檀，為的是方便別人的工作命满，而不是自己想法的筆記本。
