"對於理論以及長篇大論的需求文章來說，人們更能記住故事發生的場景，通過簡短但是詳盡的故事描述，讓程序員和設計師來理解，產品的用心良苦，從而達到，為用戶提供設計服務，而不是產品單方面的猜測。
對於理論以及長篇大論的需求文章來說，人們更能記住故事發生的場景，通過簡短但是詳盡的故事描述，讓程序員和設計師來理解，產品的用心良苦，從而達到，為用戶提供設計服務，而不是產品單方面的猜測。
讓我們來了解一個簡單而又強大的工具，這是一種很好的設計方法，你可以在所有項目中應用它，同時可以增強所有利益相關者的合作。
敏捷設計的核心部分是用戶需求也就是用戶故事。有很多關於 UX 和敏捷開發的文章，很多人都在喋喋不休地談論敏捷開發如何使用戶體驗不友好，這兩種方法如何無法協同工作等等，並且很難適用於軟件項目，與其他學科合作很有挑戰性。雖然我們正在努力，但我們可能會對許多缺點說“是”進行妥協，而且我們不會在一篇文章中解決這些問題。
今天我們關注的是一種簡單快速的設計方法，稱為“用戶故事”，可以幫助您解決許多這些挑戰。
為什麼？
- 用戶故事簡短，具體且面向目標。這是一句話，往往具有以下結構：“作為一個，我想這樣”。
- 用戶故事是協作設計工具，期望所有項目利益相關者參與用戶故事的定義和排序。
- 用戶故事將項目的重點放在那些使用者角度。
這聽起來不是以用戶為中心的哲學和發展過程的核心嗎？然而，它是來自敏捷開發的工具。
那麼，為什麼不接受它們呢？
用戶故事：顯然是以用戶為中心
當然，有些團隊不進行任何用戶研究，並根據他們的想法編寫用戶故事。雖然這不是最佳選擇，但它比考慮“我”要好得多。一點想象力可以創造奇蹟，同時注意用戶與設計者的不一樣。只是為了強調這種思維方式的相關性，你可以向所有利益相關者，解釋一下像下面這樣的小方案。
“例如，如果你必須設計一個迎合音樂家的網站，他們可以選擇風格和效果來幫助他們創作歌曲，你需要考慮很多類型的音樂家。客戶要求提供具有各種效果的菜單。可能你會突然想到的是汽車音響的CD上的一首歌，拋棄這個想法吧，因為你想的是“我”。
相反，想一想：
- “我” 可以是任何專門研究一種或多種樂器的音樂家。如果你認為“我”是一個沉重的搖滾吉他手，那就回去考慮一下鍵盤手，歌手，貝司手和鼓手……或者，也許是一位古典作曲家正在起草一部歌劇，並希望查看一些關於樂譜的想法。
- “我”也是任何類型的作曲家。這可能是輕鬆傾聽，電子化，或者是，精緻，沉重的搖滾樂。或者，它可能是一位古典主義者，他被委託為一部你未曾見過的電影編寫原聲帶。
太好了！現在我們已經設法讓團隊思考“更多的可能性”以適應我們的用戶，我們能夠創造用戶故事。用戶故事的格式迫使我們站在他人的角度進行思考，同時將他們的需求放在焦點上，對於同理心的工作，可以讓自己置於用戶的角度。
也許，有時候，我們不會根據實際數據做到這一點，但這是一個開始。也許通過這種微小的同理心練習，管理層和團隊成員可能會理解出去尋找目標用戶的必要性！
理想情況下，作為用戶研究員，您應該在用戶故事的定義上起帶頭作用。您可以將您的角色（我們創建的虛構用戶）和用戶場景帶到用戶故事會話中，併為所有利益相關者構建正確的框架。如果沒有用戶研究階段，只需確保收集儘可能多的現有項目信息。這可以來自日誌或分析，來自客戶支持，來自計算機研究，競爭分析等。在我們音樂網站的互動場景中，我們很幸運的是客戶告訴我們，他是主要為電視節目中的音樂處理的鍵盤手。
作為用戶體驗設計師，您是項目開發期間用戶的“聲音”。嘗試用盡可能多的現實環境進行思考，並將這個“用戶聲音”翻譯成用戶故事，以便每個人都記住它。
用戶故事簡單易懂
如果你來自“舊學校”，你可能還記得用戶用例。也許用戶故事會提醒你關於你用戶的一切。好吧，雖然有一些相似之處，但差異性使得用戶故事更好。
用例具有特定的語法和結構，因此，並非每個人都參與定義它們，只有負責定義要求或功能規格的團隊或負責人才能編寫。用例是客戶端（有時是用戶和開發團隊）之間的橋樑，因此，促進“輪胎擺動”模型，我們看到會發生什麼……
"對於理論以及長篇大論的需求文章來說，人們更能記住故事發生的場景，通過簡短但是詳盡的故事描述，讓程序員和設計師來理解，產品的用心良苦，從而達到，為用戶提供設計服務，而不是產品單方面的猜測。
讓我們來了解一個簡單而又強大的工具，這是一種很好的設計方法，你可以在所有項目中應用它，同時可以增強所有利益相關者的合作。
敏捷設計的核心部分是用戶需求也就是用戶故事。有很多關於 UX 和敏捷開發的文章，很多人都在喋喋不休地談論敏捷開發如何使用戶體驗不友好，這兩種方法如何無法協同工作等等，並且很難適用於軟件項目，與其他學科合作很有挑戰性。雖然我們正在努力，但我們可能會對許多缺點說“是”進行妥協，而且我們不會在一篇文章中解決這些問題。
今天我們關注的是一種簡單快速的設計方法，稱為“用戶故事”，可以幫助您解決許多這些挑戰。
為什麼？
- 用戶故事簡短，具體且面向目標。這是一句話，往往具有以下結構：“作為一個，我想這樣”。
- 用戶故事是協作設計工具，期望所有項目利益相關者參與用戶故事的定義和排序。
- 用戶故事將項目的重點放在那些使用者角度。
這聽起來不是以用戶為中心的哲學和發展過程的核心嗎？然而，它是來自敏捷開發的工具。
那麼，為什麼不接受它們呢？
用戶故事：顯然是以用戶為中心
當然，有些團隊不進行任何用戶研究，並根據他們的想法編寫用戶故事。雖然這不是最佳選擇，但它比考慮“我”要好得多。一點想象力可以創造奇蹟，同時注意用戶與設計者的不一樣。只是為了強調這種思維方式的相關性，你可以向所有利益相關者，解釋一下像下面這樣的小方案。
“例如，如果你必須設計一個迎合音樂家的網站，他們可以選擇風格和效果來幫助他們創作歌曲，你需要考慮很多類型的音樂家。客戶要求提供具有各種效果的菜單。可能你會突然想到的是汽車音響的CD上的一首歌，拋棄這個想法吧，因為你想的是“我”。
相反，想一想：
- “我” 可以是任何專門研究一種或多種樂器的音樂家。如果你認為“我”是一個沉重的搖滾吉他手，那就回去考慮一下鍵盤手，歌手，貝司手和鼓手……或者，也許是一位古典作曲家正在起草一部歌劇，並希望查看一些關於樂譜的想法。
- “我”也是任何類型的作曲家。這可能是輕鬆傾聽，電子化，或者是，精緻，沉重的搖滾樂。或者，它可能是一位古典主義者，他被委託為一部你未曾見過的電影編寫原聲帶。
太好了！現在我們已經設法讓團隊思考“更多的可能性”以適應我們的用戶，我們能夠創造用戶故事。用戶故事的格式迫使我們站在他人的角度進行思考，同時將他們的需求放在焦點上，對於同理心的工作，可以讓自己置於用戶的角度。
也許，有時候，我們不會根據實際數據做到這一點，但這是一個開始。也許通過這種微小的同理心練習，管理層和團隊成員可能會理解出去尋找目標用戶的必要性！
理想情況下，作為用戶研究員，您應該在用戶故事的定義上起帶頭作用。您可以將您的角色（我們創建的虛構用戶）和用戶場景帶到用戶故事會話中，併為所有利益相關者構建正確的框架。如果沒有用戶研究階段，只需確保收集儘可能多的現有項目信息。這可以來自日誌或分析，來自客戶支持，來自計算機研究，競爭分析等。在我們音樂網站的互動場景中，我們很幸運的是客戶告訴我們，他是主要為電視節目中的音樂處理的鍵盤手。
作為用戶體驗設計師，您是項目開發期間用戶的“聲音”。嘗試用盡可能多的現實環境進行思考，並將這個“用戶聲音”翻譯成用戶故事，以便每個人都記住它。
用戶故事簡單易懂
如果你來自“舊學校”，你可能還記得用戶用例。也許用戶故事會提醒你關於你用戶的一切。好吧，雖然有一些相似之處，但差異性使得用戶故事更好。
用例具有特定的語法和結構，因此，並非每個人都參與定義它們，只有負責定義要求或功能規格的團隊或負責人才能編寫。用例是客戶端（有時是用戶和開發團隊）之間的橋樑，因此，促進“輪胎擺動”模型，我們看到會發生什麼……
在上圖的模型中，我們發現了每個人對於用戶的需求解析出現了一些可怕的錯誤！但用戶故事以其簡潔和專注，提供了避免此類情況的完美方式。參與團隊的任何人都可以參與其中。他/她只需要瞭解特定語法的相關性：
- 作為一個 。角色指的是做出行動和受益的人。
- 我想要 。這是執行的動作。
- 以便 。它是用戶從操作中獲得的附加值。
通過這個簡短的陳述，用戶故事可以縮短學習時間！如果您來自參與式設計方法，您還可以讓用戶參與用戶故事的撰寫。
用戶故事是協作的
正如我們之前所說，您作為用戶體驗設計師的目標是促進最終用戶的具體，現實和共享的願景，用戶故事是你最好的盟友。由於它們的可訪問性和靈活性，您可以使用它們來構建公共語言和項目所涉及的常見心理模型。因此，您可以讓所有利益相關者 – 客戶，管理層，團隊成員 – 使用相同的語言，並專注於用戶以及項目正在嘗試實現的目標。
用戶故事促進了項目討論方式的轉變，我們不再關注解決方案和功能。我們專注於“真實”用戶能夠為特定目的而努力的目標，我們沒有一個可疑的抽象功能列表，我們將項目的最終目標集中在如何讓用戶做具體和有形的事情上。
用戶故事講述的是現在和未來
用戶故事通常寫在Post-its上，起初，Post-it的數量可能是壓倒性的，但它比永無止境的需求文檔更易於管理！
用戶故事具有恰當的詳細程度。在更抽象的層面上，我們有“epics”。在敏捷開發中，“epics”用於所需功能的高級概述。因此，他們收集了一組用戶故事。如果您正在構建親和關係圖，則epics將是一組常見用戶故事的名稱。 Epics使項目中的每個人都可以從許多用戶的角度看待設計，那麼任何不合理的方面都可以顯示出來。用戶是否需要“嘗試”未經計劃或計劃得好的東西也可以通過此得以驗證。
用戶故事必須足夠具體，以便項目團隊可以在衝刺期間選擇並處理它們。在此之前，團隊應該從一開始就深入研究細節並解決可用性問題。作為用戶界面設計師，您應該成為項目團隊的一員，並與開發人員合作，使用戶故事真實可用。
用戶故事的簡單語言有助於每個人瞭解每個sprint中正在構建的內容，所有利益相關者都可以查看他們的關注點和需求是如何得到解決的。因此，用戶故事非常適合設置階段和定義項目範圍，它們也是定義後續步驟的理想選擇。因為它們處於完美的粒度級別（即完美的細節級別），所以當項目遭遇特殊變動時，用戶故事可以幫助你更好地看清一切。
選擇
用戶故事一開始是作為敏捷和SCRUM開發方法的一部分，作為用戶體驗設計師，我們需要擁抱它並使用這種簡單的方法來實現我們自己的“好處”，這對於用戶而已也是很好的設計方法！
用戶故事為設計人員提供了創建用戶的真實，具體和共享理念所需的一切：
- 用戶故事基於用戶目標; 因此，他們可以專注於產品的核心用戶；
- 用戶故事是易於訪問和管理的; 因此，它們促進利益相關者和團隊成員之間的協作；
- 用戶故事有助於從一開始就創建“項目心理模型”。
通過一個非常簡單和具體的結構，用戶故事可以幫助項目專注於許多方面，例如：以用戶為中心，以目標為中心，以及在每個階段應該實施什麼內容，如何選擇和拋棄。
敏捷開發是一種很好的以用戶為中心的設計方法，不單單是因為它可以為我們提供研究和計劃的一個更好的方向，同時他還可以幫助我們構建以及創造出項目中每一個可能性的轉折點，用戶故事為我們提供了在最重要的用戶研究和用戶需求方面的一個可靠的理解和體會。
個人感想
我作為一名產品經理，當我去開啟一個項目，進行背景以及功能點的解說是，我通常會採用用戶故事的方法來敘述整一套的用戶流程，同時我也希望我的團隊這麼去做。對於理論以及長篇大論的需求文章來說，人們更能記住故事發生的場景，通過簡短但是詳盡的故事描述，讓程序員和設計師來理解，產品的用心良苦，從而達到，為用戶提供設計服務，而不是產品單方面的猜測。
建議大家可以多采用 Persona 以及 Scenerio 來為更多人講述你設計的產品的初衷。只有當你成功的說服了別人，人們才會願意為此埋單。
本文翻譯自：《User Stories: As a [UX Designer] I want to [embrace Agile] so that [I can make my projects user-centered]》
本文由@ vivi 翻譯發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自Unspalsh, 基於CC0協議
"