用戶體驗要素摘錄二

用戶體驗要素摘錄二

範圍層

在戰略層到範圍層，問題從「我們為什麼要開發這個產品？」到「我們要開發的是什麼？」

當整個事情還處於假設階段時

確定範圍層能迫使你去考慮現在的衝突和產品中一些粗略的點

我們能確定現在能解決哪些事情，而哪些必須要再遲一點才能解決。

在範圍層，定義產品能給整個團隊一個參考點

明確了這個項目要完成的全部工作

它也提供了一門用於討論這件事的共同語言。

定義好你的需求能保證在設計過程中不會出現模稜兩可的情況。

如何定義

一個好的方法就是：

用文檔記錄定義好的產品需求（寫下來）

原因一：這樣可以知道你在建設什麼？（明確）

詳細的記錄下你正在建設的內容，每一個人就會知道這個項目的目標是什麼

最終產品變成一個在企業內部每一個人都觸手可得的東西

然後按文檔往正確的方向走。

原因二：這樣你才知道你不需要什麼（評估）

許多功能看上去誘人，但有些不是必須的

當這些功能的想法以各種各樣的可能性浮現

用一個文檔記錄下倆

可以為你提供一個評估這些想法的架構

幫助你了解這些想法如何（是否）

滿足你當初所承諾要做的那些事

了解你「不需要什麼」也就意味著

知道哪些是你不需要馬上去做的東西

把這些傑出的想法收集起來，可以成為下一次版本的更新

持續管理這整個設計過程

功能和內容

（個人覺得功能和信息比較好）

在戰略層到範圍層

問題從「我們為什麼要開發這個產品？」

到「我們要開發什麼」

在這裡，分為「功能型產品」和「信息型產品」

功能型產品考慮的是功能需求規格

即哪些應該被當成軟體產品的「功能」以及相應的組合

在「信息型產品」中

我們考慮的是內容

這屬於編輯和營銷推廣的傳統領域

定義需求

（需求從哪裡來）

一些需求適用於整個產品，

品牌需求是最常見的一種；

某些技術需求；

比如：支持瀏覽器和操作某些系統

大部分時候，當人們說到某種需求時

他們想到是產品必須擁有的某種特性的一句簡短描述

需求的詳略程度：

取決於項目的具體範圍。

如果該項目的目標是完成一個複雜的子系統，那麼就需要有一個非常詳細明確的需求

即使這個項目對於整個項目來講非常小。

相反的一個大型項目

它的內容也許只是相似或相同性質的東西

（比如提供大量功能相似的產品說明書的PDF文件）

那麼內容需求只需要一般化就可以了

需求的來源：

從產品的直接影響人

決策者，用戶，同事等

第一

先問這些人

他們或許會有好的建議可以直接體現在產品上

第二

他們有時提出治標不治本的建議

可以深入探討這些建議，思考為什麼得出這樣的建議

有時候可以得到真正解決問題完全不同的需求（潛在需求）

第三

是人們不知道他是否需要什麼

在討論時，會突然想起偉大的構思，跑偏現在所做的產品

或者創建和設計產品最深入的人因為太了解產品，很少想像產品的新方向

針對第三種情況

可以讓公司各部門開發，營銷，設計等人一起談論一個產品

從自己不熟悉的角度來考慮產品並給予反饋

幫助人們多角度全方位地思考開發中的產品遇到的問題以及解決辦法，得到需求

需求定義也有硬體的需求

系統有什麼裝置，攝像頭，GPS等

這些因素都將會確立或限制產品功能的可能性

通過上訴方式討論出來的功能需求通常是

如何去除某些障礙的方法

如何才能讓這個過程對於用戶來說更加容易適合？

在上一章中，有個人物角色的技術

來幫助我們更好地理解用戶需求

在決定功能需求的時候

我們可以再次使用人物角色

把人物放到一個簡短的故事中

這樣的一個故事稱為「場景」

場景簡單描述了一個人物角色會如何完成任務

通過想像我們的用戶將會經歷怎樣的過程

找到能幫助他順利完成過程中的潛在需求

有時，也可以從競爭對手得到一些啟示

在完成相似的產品時，競爭對手是否找到一種特別有效的特性

能完成其中的某個戰略目標？

他們是如何權衡和調整我們所面對的那些問題的

即使不是產品的直接競爭對手也能提供豐富的潛在需求。

例如一些遊戲平台允許用戶創建自己人的社交群組

那麼在我們的數字錄像軟體上採用相似的特徵或建立類似的機制

也許就能給我們一定的競爭優勢，用來超越直接競爭對手。

功能規格說明

功能規格說明在項目實施過程中需要改變的時候

要學會，或建立一套規則

讓撰寫文檔的過程變得快速和簡便

使文檔隨著產品開發一起進行

文檔不能解決問題，定義可以

功能規格說明要記錄的是：

在創建產品時已經確定下來的決議

記下來

（如何寫好功能規格說明）

作者介紹了幾條通用規則

一是樂觀

例子：

這個系統不允許用戶購買沒有風箏線的風箏

替：如果用戶想買一個沒有線的風箏，這個系統應該引導用戶到風箏線線頁面。描述這個系統將要去做什麼事情去「防止」不好的情況發生，並給出解決方案

而不是「不應該」做什麼

二是具體

例：

最受歡迎的視頻應重點突出

問什麼才是最受歡迎的視頻，突出要怎麼突出？

替：

上一周被播放最多的視頻要顯示在列表的最前端

儘可能詳細解釋清楚狀況，這是我們能決定一個功能是否能實現的最佳途徑

避免主觀的語氣

例：

這個網站風格應該是時尚的，閃耀的

問：每個人對時尚和閃耀的定義不同，會產生的歧義

修改：

這個網站應該符合某一人物角色所期望的時尚和閃耀

依賴的是用戶的認同，無法更客觀界定的時尚和閃耀

替：

網站的外觀應該符合企業的品牌指南文檔（或者一個參考物的時尚和閃耀）

這樣得到一個清晰的指南

這裡是另一種使需求「保持明確」和「避免歧義」的途徑

我們也可以量化一些功能來避免主觀性

例如：

要求系統有高級別的執行能力

替：

要求系統至少要支持1000個用戶同時使用

內容需求

很多時候，我們說到的內容指的是文本

但圖像，音頻和視頻有時候也很重要

不同的內容結合到一起

相互協作去滿足某一個需求

定義出所有不同類型的內容

可以幫助你確定哪一些內容來製作（是否提供某內容）

內容功能和目的是主要的

不可偏重格式

本末倒置

內容需求應該提供每一個內容的大致預估

文本的字數，圖片的像素大小，下載的文件位元組

PDF或者音頻文件等相對獨立元素的大小等

這些是大致預估，不需要很精確

知道這些能讓我們在這個實際過程中做出明智的抉擇

儘早確定某個人來負責內容元素

這樣不會過早過多地投入到開發流程中

內容是需要更新的，這是日常維護工作

應該定義每一個內容的「更新頻率」

更新頻率來自於你產品的戰略目標

從你的網站目標來看，你希望用戶多長時間來訪問一次？

從你的用戶需求來看，他們需要多長時間更新一次？

以目標用戶確定內容

系統為需求相異的用戶服務，該清楚哪些用戶想要什麼內容

能幫助你決定用什麼方式呈現

對於有很多內容的項目而言

把內容的信息多記錄在一個內容清單中

（採用簡單的格式）

這樣團隊中的每一個人才能確切知道

他們設計用戶體驗的需要做那些工作

確定需求優先順序

收集潛在的需求或想法只是開始

在許多「這個產品應該增加哪些特性」中

最棘手的部分是排列出哪些功能最應該放到這個項目中去

由於項目範圍建立在戰略層之上

因此我們應該去評估這些需求是否能滿足我們的戰略目標

（系統目標還是用戶需求）

除了這兩種目標，我們還需要格外確定第三種範圍：

實現這些需求的可行性有多大？

一技術上的問題

（需要投入很多人力物力財力，超出範圍）

二時間不夠

（這個需求需要時間，這個可以放到下一個項目中）

很少功能是獨立存在的

甚至產品的內容必須要以來其他特性的支持

不可避免的發生不同特性之間的衝突

這種衝突要和其他的特性一起權衡，才能得到一個連貫的，統一的產品

例如：

一些用戶想要一步提交訂單的過程

但網站所使用的老資料庫無法適應這個需要

那麼採用多個步驟的流程是更好的辦法

也許你也可以重新設計資料庫系統

這完全取決於你的戰略目標

任何不符合項目戰略目標的特性建議

都要通過範圍定義將其排除出去

但有一個特性，聽起來不錯，但不在項目範圍之內

那麼你可能需要重新審視戰略目標

如果你發現自己反覆審視戰略目標

那麼極有可能過早進入了需求定義階段

有時候，兩個不同戰略目標之間的重要程度也會出現模糊的情況

這時候，特徵是否能納入項目範圍之中，往往取決於企業的政治局面

與管理層談戰略

但通常管理層會談很表面的東西

談判過程中會非常困難，及時把話題拉回來

對決策者的需求表示認同

是解決特性衝突的關鍵

技術人員也需要溝通的技巧