>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

文章來源：簡書    作者：某年某人

banner：william王萌

之前寫過一篇文章《像做發布會那樣做產品》，文中主要寫通過有意利用產品中的魅力需求來提高用戶滿意度，達到口碑宣傳的效果。而今天寫的文章與之類似，主要來寫產品設計中的通過對用戶使用場景的理解，將產品功能相互連接進行自然過渡，達到舒適的效果，在完成某些特定橋接的同時，兼顧人文關懷。

首先了解下用戶場景：

用戶場景的描述實際上是在構造一個完整的過程。一個場景里面包含了什么人，在什么狀態下，遇到了什么問題，他們如何操作，他們得到什么反饋。

用一個套路來表示，具體描述如下：

“在某某時間（when），某某地點（where），周圍出現了某些事物時（with what），特定類型的用戶（who）萌發了某種欲望（desire），會想到通過某種手段（method）來滿足欲望。”

when，where，with what這幾點信息其實統一地描述了需求產生的環境。

從這些環境信息可以分析出誘發需求的條件和需求產生時的環境條件。

用戶場景主要用來判斷需求的存在必要性，深刻理解產品需求，深入考慮用戶是如何使用產品的。用戶使用產品有哪些路徑以及在這些路徑上的實際使用場景是怎樣的。哪些是強場景，哪些是弱場景，在各場景下用戶目標是怎樣的，他們有怎樣的需求，哪些是強需求，哪些是弱需求……

本文只要關注通過對用戶使用場景的理解來優化產品設計，讓產品設計過渡自然，富有情感。而做到這些必須對產品流程、用戶目標足夠熟悉，同時對用戶心理也有所了解。

場景1、金山詞霸的默認檢測剪貼板

金山詞霸

打開金山詞霸后，如果它檢測到系統剪貼板有粘貼內容（且為英文），會自動提示已經檢測到您復制了以下內容，詢問是不是要點擊翻譯。這點功能在開發中并不難，但是很多查單詞的軟件都沒有這點，大多是在打開之后，在輸入框粘貼剛才從其他地方復制到的英文單詞，從流程上麻煩一個步驟。

分析用戶使用場景（前幾天我的真實場景）：

when:xxxxxxxxxxxx

who:xxxxx

where：xxxxxx

with what:手機瀏覽A軟件時，遇到了一個不認識的單詞，且該軟件不自帶翻譯功能

desire:想要打開一個B軟件查詢單詞意思

method：先在A軟件中復制單詞，準備打開B軟件粘貼到文字框進行查詢

這個是我的真實場景，當時我隨手下載了幾個詞典類的app,當打開金山詞霸的時候，發現他已經檢測到了我復制的單詞，無需我粘貼，點擊就可以查詢，當時略顯感動。因為它對使用詞典的流程有一個很清楚的認識，一般用戶都是從其他軟件復制單詞到詞霸中，并粘貼，在很多情況比如顛簸的公交車上，每一次操作都對用戶來說成本很大，那么它就直接去檢測你是系統內存中有沒復制過的英文內容，猜測這是你想查詢的單詞，在縮短了操作步驟的情況下，充滿人性關懷。

（注：最早我在學人機交互的時候，重點強調的是減少用戶操作成本，不過個人感覺現在大多交互設計感覺稍微偏離了本質，越來越像UI設計，朝著越炫、越酷的方向發展，這個小貼心的功能，讓我想起了人機交互最應該關注的點。）

場景2、新浪微博的下拉刷新-沒有更多內容-詢問是否前往熱門話題

刷新微博

在首頁下拉刷新時，如果沒有更新的內容，一般app會彈出一個toast框提示【沒有更多內容】,而新浪微博會首先彈出【你可能錯過的一條熱門微博】同時提示你去熱門微博玩玩。

同理這個可以和上面一樣進行用戶場景分析：

用戶以下拉刷新為method,本質的desire是獲取新的內容，以完成消磨時間的欲望。當沒有更新的內容的時候，我們可以通過其他方法完成用戶的desire,比如給他最新的熱門微博或者最熱的笑話段子，這樣一來可以幫用戶完成他的desire,二來可以幫產品的其他功能進行引流，照顧或者加重某些功能權重；三來讓用戶感覺產品很有人性、很懂用戶。

場景3、Google主頁的斷網狀態-游戲模式

google頁恐龍彩蛋

同樣也是一個真實的場景，前日公司停網，因為斷網很多工作不能進行，程序員同事也是這樣（技術性休息），百般無聊坐等來網，突然發現旁邊一個哥們玩起了google首頁的恐龍游戲，圍觀了不少其他同事，請原諒我也是第一次才知道原來可以這樣。

場景分析（省略who where when)：

with what:上班時候突然之間公司斷網，一直刷新google首頁看是否正常

desire:在等待的過程中，找點事情打發時間，但是不能被老板發現偷懶

method：找一些隱蔽的娛樂活動

正被大家熟知，www.baidu.com是一個大家用來測網絡是否正常的一個流行工具，任何時候只要有人（不管是小白還是大神）要想知道自己網絡是否暢通，大多時候是訪問百度的主頁，如果能刷出內容則說明網絡通暢。可以猜測google在外國也有這項光榮的使命，就算在國內，斷網的時候，我們也會通過查看google來了解情況，而在這個等待或者說異常的過程中，如果有什么事情能消遣并隨時幫助第一時間了解狀態那就再好不過，最好的方式就是在google的斷網頁面完成，于是google用小游戲來進行過渡，會讓焦急等待的用戶轉移注意力，但始終停留在google首頁，相當聰明。

場景4、超越iRate的評價方案

各種要好評

先說說iRate是什么？iRate是現在普遍在使用的一個開源的用戶評分sdk,iRate可以判斷：『在第幾次打開客戶端的時候，載入完成客戶端之后顯示此去評分的彈窗】（當然還有很多其他的方法）本質是用iRate中一段時間內第幾次打開app來判斷該用戶是不是活躍用戶，然后將去評分的信息彈給這批活躍用戶，活躍用戶比起一般用戶對app依賴性大，感情深，喜歡程度高，去評分的轉換率高。這個是目前最流行的模式，大部分app應該在用這個，在github上也有2000多個stars，不過這中方法難免會打斷用戶的正常操作，或者讓用戶感覺有點死皮賴臉強買強賣的感覺。

有沒有一個更好的方案？我設想的用戶場景：

with what:在當用戶利用app核心功能完成某項操作到一個點時，或者獲得某個榮譽時（這個時候是用戶對app的價值最肯定的時候，或者說是最高興的時候）

desire:看到這個感覺app幫助很大，或者很高興，不去評價對不起app開發人員

method:彈出提示框，提示app已經幫助用戶完成xxx,節省xxxx,在app中獲得xxxx，引導去評分

每一個app都有自己的不同觸發點，情況因app而議：

ex：音樂類app：當下載累計500首歌曲的時候，觸發事件，彈出：【這是您的第500首免費歌曲，趁著下載的空，去評個分吧！】

ex：最近我們在做一款打榜的軟件，有一個打榜的功能，我準備這樣觸發：

當用戶打榜連續3次獲得榜首的時候，小秘書發送祝賀消息：‘爺，您最近連續三次是榜首，小秘書幫你裝了三次逼，要不去給我評個分？’

我YY的場景本質是告訴用戶app幫你完成了什么或者給你帶來了歡樂，是某個事件點上觸發的，而不是生硬的判斷你是打開app多少次，然后用卑微的聲音求你去給評分，記住千萬不要求，身份要平等，你要堅信你的app對用戶帶來的價值，評分是他們應該做的，當然前提是你app能確實幫助用戶解決問題。

備注：做產品的時候，需要多考慮考慮用戶的使用場景。用戶哪些時候會使用應用，是工作的時候？走路的時候？用戶經常在哪些地點會用，在辦公室？地鐵里？包括用戶使用應用的平臺、情緒，以及用戶的網絡情況，這些都可能影響到你對產品的設計，要迎合用戶的使用姿態。

互聯網er的早讀課 2015-08-23 08:43:53