向國外設計師學習之如何專注於用戶的核心任務

 　　一款產品在初創時間通常有相對核心的一個目標，隨著產品的逐漸發展和迭代，如何依然專注於用戶的核心任務呢?

　　我們可以通過三個步驟展開：1)確定用戶的核心任務;2)采用用戶故事來表達這些任務和目標;3)圍繞用戶故事來設計軟件。

　　red routes核心任務

　　1、 什麼是 red routes

　　在倫敦，有紅線的路叫做red routes。他們是倫敦的重要交通動脈，倫敦運輸部做了他們所能做的一切事情，來保證這些路線的清晰。

　　軟件也有 red routes，他們就是軟件的關鍵“用戶行為路徑user journey”，也就是用戶完成核心任務的行為路徑/操作路徑。

　　2、red routes 核心任務 的重要性

　　每個應用都有一小部分重磅的、核心的任務，來達成一個巨大的價值;當然也同樣有較大一部分不那麼重要的任務，他們可以削弱核心任務的價值。成功的開發團隊，堅持不懈地專注於提升用戶核心任務的可用性。比如： Dropbox，專注於讓分享文件更簡單。

　　如果沒有red routes，可能會出現下圖的界面，混雜著各種各樣的信息。對於開車的司機來說，他們的主要任務是看清楚前面的路，但顯然圖中的設計干擾了用戶去完成他們的主要任務。

　　(汽車表盤)

　　如果沒有核心任務，瑞士軍刀可能做成大雜燴，最終任何一個用途都用起來異常困難、事與願違。

　　(瑞士軍刀)

　　3、red routes在用戶體驗設計中有何作用？

　　red routes 幫助你專注於由首要人物角色確認的“最重要的場景”、為最常見的用例設計。

　　red routes 產生了可操作性的結果。我們能做的就是讓用戶坐在我們的系統前，請他們使用我們的系統完成某個特定的目標(從red routes開始)，然後看他們如何操作、他們經過了那麼地方、他們遇到了哪些障礙、他們犯了哪些錯誤。優化、修復這些問題之後，系統將會變得更加易用。

　　red routes讓用戶更容易、花更少的時間做出選擇。根據hick’s law 席克定律，如果給用戶越多的選擇，他們就要花更多的時間來做決定。如果不專注 red routes，就可能像iTunes一樣，用戶不知道該怎麼用，既給用戶帶來干擾、又降低了使用效率，浪費時間和開發成本。

　　4、如何確定red routes核心任務？

　　步驟1：確定常見的、關鍵的任務

　　步驟2：根據兩個關鍵點“有多少用戶會做這個任務”、“有多頻繁的做這個任務”，將列舉的任務放置在這樣的坐標當中(這會讓你感知哪些是有價值的)

　　以車載導航系統為例，它的red routes是什麼呢?如下圖，根據縱軸——使用頻率、橫軸——使用的用戶數 來分布常見的、關鍵的任務，由此可確定右上角的幾項是需要重點關注的功能，也就是“核心任務”。

　　(確定核心任務)

　　在快速實踐這種“確定red routes”的方法時，我們還需要注意幾個tips ：

　　1)在確定常見的、關鍵的任務時，可以采用頭腦風暴的方式，描述10個red routes，每張便簽紙上寫一個。

　　2)描述的這10個red routes核心任務，來自“使用產品的首要人物角色”的關鍵任務(要關注首要人物角色的任務，而不是你以為的任何人都想做的事)

　　3)這些任務是一系列的行動，所有請用“動詞”開頭。

　　用戶故事 user story

　　1、用戶故事的作用

　　兩個用戶，他們有相同的用戶需求red routes——找一家酒店、預訂一個航班。但是他們有不同的使用情境，一位是與伴侶的一次浪漫的旅游，另一位則是兩天的商務出差。

　　盡管用戶需求相同，但不同的使用情境將改變你幫他們達成目標/完成任務的方式。用戶故事，就是一種將使用情境納入到你的任務中的方式。

　　2、用戶故事的表達方式

　　用戶故事，是敏捷開發的一個關鍵組成，它有一個特殊的結構——“作為一個用戶，我想要…，所以我能…” 。其中關鍵元素有 user用戶、task任務、goal目標。因為用戶故事通常寫在卡片上，所以也叫做故事版。

　　以前面提到的預訂酒店的需求為例，將一些使用場景嵌入到故事當中，就可以這樣表達：

　　1)作為一個商戶出差者，我想找到有商戶中心的酒店，這樣我能遠程工作

　　2)作為一個旅游者，我想找到房間的圖片，這樣我能和我的伴侶擁有一個浪漫的周末

　　3)作為一個旅游代理，我想到處我的歷史預訂記錄，這樣我能為我的顧客開具發票

　　3、怎樣從red routes 核心任務 到user story 用戶故事？

　　課程介紹了兩個正例、一個反例：

　　(核心任務 and 用戶故事)

　　我們可以重點看看反例，它描述的任務task是”我想了解怎麼計算我的繳稅代碼”，目標goal是“這樣我能確認我在使用正確的繳稅代碼”。

　　事實上，這樣的用戶故事限制了解決方案，也並不是真實的用戶的初衷。真實用戶的任務task是“我想要繳納正確數額的稅”，目標goal是“這樣我能擁有我應該有的錢，並且避免預期之外的稅金”。

　　對於這個反例，修改前後的用戶故事如下：

　　(用戶故事修改前後)

　　小貼士：在red routes中挑選2-3個更為重要的，來建立用戶故事並寫在卡片上，不需要為所有的任務創建用戶故事。

　　4、 怎樣測試一個用戶故事是否合適/正確？

　　1)這件事，是真實的用戶希望說的?

　　2)這件事，可以幫助你設計或者更為優先的處理嗎?

　　3)它不必要的限制了可能的解決方案嗎?( 專注於目標，而不是具體的步驟、簡單的實現方式)

　　4)你有好的證據嗎?( 比如，來自情境調研中真實用戶的故事)

　　這篇筆記就到這裡啦!

　　歡迎關注作者的微信公眾號：