用戶故事描述了用戶想通過使用軟件達成的一些事，對於設計師而言，它們主要是提醒用戶目標以及組織和優先考慮每個屏幕怎樣設計的一種方式。
設計團隊坐下來分享新客戶的app的第一輪模型。隨著團隊成員提出自己的想法，很明顯，每個人對app是什麼以及應如何運行都有著截然不同的想法。會議很快變成了關於誰是對的，而不是什麼是對的討論。每個人都在捍衛自己的設計，沒有人在捍衛用戶。聽起來有點耳熟？在這種情況下，我們需要實施用戶故事。
如今，許多UI / UX專業人員發現自己在一個敏捷世界中工作。敏捷開發（和設計）過程快速發展；因此，我們需要能夠進行快速，有效協作的工具。這聽起來有些矛盾，但是有些工具可以幫助我們一起工作，而無需增加工作時長。
用戶故事是敏捷方法論1（Agile methodology）中特有的，當應用在UI設計流程時，它們為後續的設計階段提供了必要的基礎。精簡版的用戶故事幾乎不需要花費時間來實現，但是可以使項目保持正常運轉。
在移動應用程序開發公司CitrusBits，我們的UI設計團隊在開發過程中實施了用戶故事，我們發現它完成了三件主要的事情：
- 用戶故事保持產品用戶專註
- 用戶故事促進團隊成員間的合作
- 用戶故事防止特征蠕動2（feature creep）和設計死角（design dead-ends）
01 什麼是用戶故事
其核心就是，用戶故事描述了用戶想通過使用軟件達成的一些事。它們源於Agile andScrum開發策略的一部分，但對於設計師而言，它們主要是提醒用戶目標以及組織和優先考慮每個屏幕怎樣設計的一種方式。
一個用戶故事是一則很短的故事，實際上大概只有一句話，如模板：“作為一個用戶，我想……[用戶基本目標]。”
因為這些故事很簡短和具體，需要很多故事來覆蓋到所有的使用案例。事實上，我們試著把每個故事都講一遍，看它能被分解到什麼程度。
舉個例子，一個用戶故事可以從這開始：
“作為一個用戶，我想創建一個新的賬戶。”
但是創建一個新賬戶究竟包含哪些內容呢？用戶需要提交一個用戶名、密碼以及其他相關的信息。
每個單獨的動作需要一個與之相關的用戶故事，每個故事越具體，之後設計人員和開發人員的事情越容易。所以“創建一個新用戶”實際上可以進一步別分解：
“作為一個用戶，我想輸入一個新名字。”
“作為一個用戶，我想輸入一串密碼。”
“作為一個用戶，我想重新輸入我的密碼以便確認它。”
“作為一個用戶，我想提交這個信息並創建一個新賬戶。”
如果準確的做完這些，最終結果會是一長串的用戶故事，其中大部分我們將納入到最終產品。
在Citrusbits，我們最近為Quiksilver clothing開發了一款iPad app，該app能夠使攜帶其產品的商店跟蹤其當前庫存並輕鬆訂購新的和額外的產品。為了使它能夠看起來像一個相當易用的app，我們想了266條獨立故事。
02 保持用戶專註
作為一個設計師，在與項目相關者參與第一次會議時我就開始在腦海裡把佈局和配色方案拼接在一起。當我聽到他們的目標，瞭解到最終用戶時，我就能夠預想出這個app大概的樣子。在我們首先確定用戶故事時，我們不能本末倒置，我們應讓用戶故事決定設計，而不是讓設計決定用戶故事。
當為一款app頭腦風暴過所有用戶故事後，我們把它放到Google spreadsheet中，客戶可以向裡面添加任何感覺缺少的故事。一旦客戶和團隊認為我們已經涵蓋了所有基礎故事，我們便會為每個故事編號。當我們將數字用作簡潔的標簽來標識哪些線框所涵蓋的故事時，這些數字在項目後期特別有用。
這個表不僅提醒我們功能性，還使我們整個過程中與用戶聯繫在一起。每個用戶故事都經過專門設計以適應我們的最終用戶，從而確保我們能夠滿足他們的需求。在涉及約會app的項目中，這一點尤為明顯。
當我為“用戶個人資料”頁面建立線框圖時，最初，我認為在app中為“保存用戶”這一功能添加一個按鈕用來標記該用戶是合適的。然而，瀏覽“用戶個人資料”部分使我想起了用戶故事中的一個細節：“作為用戶，我想收藏另一個用戶。”
“保存”到“收藏”的改變是一個很小但是有價值的決定，“保存”一個用戶是冰冷、缺乏人情味兒的，而“收藏”則與用戶的約會心態保持一致。設計人員往往拘泥於技術之中，尤其是在功能性上工作了若干小時之後，而用戶故事則幫助我們提醒我們始終專註於用戶體驗，從而賦予app特色。
03 促進合作
一個UI設計通常有多個關心結果的相關人員。這個團隊可能包括客戶、設計師、程序員、其他許多職務，具體取決於組織規模大小。在很多方面，情況都與參加賽艇隊類似。為了贏得比賽，每個隊員必須以相同的速度和方向划槳。這並不意味著每個人對所有事都做出相同的選擇，這隻是意味著每個人都要專註於同一目標，知道如何融入團隊。
儘管我們在CitrusBits的流程遠非完美，但我們發現用戶故事可以使每個人保持一致。能夠使決策與用戶故事保持一致，從而使應用程序的目標清晰明瞭且定義明確。這降低了團隊合作的障礙，因為我們已經用簡短，具體的詞組確定了我們的集體目標。
用戶故事還使位於不同位置的團隊更容易進行協作：
當我們為位於舊金山的客戶開發trivia quiz app時，我們的灣區團隊有時會與客戶會面，討論該app的要求。他們創建了用戶故事,儘管在整個項目中對其進行了修改，並將它們放置到我們的Google雲盤中。
然後，作為洛杉磯團隊，我們將在創建線框並根據需要進行更改時參考用戶故事。如果不是這個過程，那麼該項目將花費更長的時間才能完成，並且將需要長時間的解釋，然而用大量微型用戶故事只需花費幾分鐘。
04 防止特征蠕動（feature creep）和設計死角（design dead-ends）
特征蠕動（featurecreep）是一個在UI設計期間經常出現的術語。它指的是想要繼續增加更多功能並擴大項目範圍的趨勢，無論是硬件還是軟件。
This Brand Camp strip perfectly summarizes scopecreep. Copyright 2005, Tom Fishburne
當然，隨著項目的進展，我們樂於接受不斷變化的需求。但是，如今我們拒絕在沒有用戶故事的情況下添加太多文本框，而這並不能解釋我們為什麼這個特定文本框很重要。在看到以前的項目失控，失去關註並未能實現其最初目標之後，我們決定對此採取強硬措施。
不久前，我們的客戶忽略了用戶故事——
我們正在為一家處理機密資產的公司開發一款app，他們想要一個管理員工之間通信的app。交流的主要方式（我們都同意）是使用文字消息和圖片的公司內部聊天平臺，我們將其記錄在用戶故事中。後來，客戶要求添加視頻，語音消息和位置共享。
為了變得“靈活”，我們嘗試將其應用到新的通信中，從而擴大了範圍並延遲了計劃，在所有這些努力之後，我們最終意識到添加這些內容對最終用戶沒有幫助。
儘管它們是整潔的功能，但最初的原則是創建一個將通訊簡化到最低限度的app，以促進團隊建設和合作，而無需使用內部Facebook。我們將他們帶回了用戶故事，並讓他們想起了該app的初衷，最後，我們能夠阻止特征蠕動並重回正軌。實驗可以產生一些奇妙的結果，但是如果產品不符合基本要求，那麼獨創性將毫無意義。
從錯誤中吸取教訓後，在使用Quicksilver（面向B2B公司的銷售app）時，我們始終嚴格遵守用戶故事。結果就是最終產品非常符合我們最初的設計，主要是因為我們已經完成了構建全面的用戶故事的前期工作。在此基礎上建立起來可以節省之後的工作，並使我們的工作井井有條，以用戶為中心。儘管項目的每次迭代都帶來了更多的用戶和客戶反饋，但該概念的核心仍然很牢固。
The product changed very little from inital designs tofinal product.
每個用戶故事對設計團隊和開發團隊都有一系列影響。儘管牢記技術限制總是好的，但它們被稱為“用戶故事”，而不是“開發人員故事”， “設計人員故事”。由於我們嘗試使用用戶故事來優先考慮用戶的觀點，因此更容易理解當前的問題並創建有用的最終產品。
05 下一步
在UI設計中嘗試用戶故事時，需要記住以下幾點：
- 在進行任何視覺設計之前，請識別出完整的用戶案例。抵制住直接進行設計的誘惑可能會節省時間，避免浪費大量精力。
- 對於每一個用戶故事，看看它是否能別分解為更小，更具體的故事。“Epics”可以很好地概述所需的功能，但不要太寬泛。儘早深入細節，並從一開始就解決可用性問題。
- 切勿把沒有相應用戶故事的設計元素放置到界面上。記錄每個元素的內容和原因能夠促進組織發展，並使向開發團隊的交接更加順暢。
- 敏捷方法論（agile methodologies）（也被稱為輕量級方法論，lightweight methodology），它是一組開發方法的統稱。隨著技術的迅速發展和經濟的全球化，軟件開發出現了新的特點，即在需求和技術不斷變化的情況下實現快節奏的軟件開發，這就對生產率提出了很高的要求。
- 特征蠕動(Feature Creep)(有時候也稱為需求漂移或者是範圍蠕動)是產品或項目的需要在除了最開始的預見之外，在開發過程中產生了新的要求的趨勢，它導致了剛開始沒有計划到的特征，對產品的質量和計劃帶來了風險。
原文鏈接：https://www.uxbooth.com/articles/user-stories-a-foundation-for-ui-design/
原作者：Tom Brinton
編譯作者：hubiabia；公眾號：插畫鴨
本文由 @hubiabia 翻譯發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議