對(duì)于理論以及長(zhǎng)篇大論的需求文章來(lái)說(shuō)，人們更能記住故事發(fā)生的場(chǎng)景，通過(guò)簡(jiǎn)短但是詳盡的故事描述，讓程序員和設(shè)計(jì)師來(lái)理解，產(chǎn)品的用心良苦，從而達(dá)到，為用戶提供設(shè)計(jì)服務(wù)，而不是產(chǎn)品單方面的猜測(cè)。

讓我們來(lái)了解一個(gè)簡(jiǎn)單而又強(qiáng)大的工具，這是一種很好的設(shè)計(jì)方法，你可以在所有項(xiàng)目中應(yīng)用它，同時(shí)可以增強(qiáng)所有利益相關(guān)者的合作。

敏捷設(shè)計(jì)的核心部分是用戶需求也就是用戶故事。有很多關(guān)于 UX 和敏捷開發(fā)的文章，很多人都在喋喋不休地談?wù)撁艚蓍_發(fā)如何使用戶體驗(yàn)不友好，這兩種方法如何無(wú)法協(xié)同工作等等，并且很難適用于軟件項(xiàng)目，與其他學(xué)科合作很有挑戰(zhàn)性。雖然我們正在努力，但我們可能會(huì)對(duì)許多缺點(diǎn)說(shuō)“是”進(jìn)行妥協(xié)，而且我們不會(huì)在一篇文章中解決這些問(wèn)題。

今天我們關(guān)注的是一種簡(jiǎn)單快速的設(shè)計(jì)方法，稱為“用戶故事”，可以幫助您解決許多這些挑戰(zhàn)。

為什么？

• 用戶故事簡(jiǎn)短，具體且面向目標(biāo)。這是一句話，往往具有以下結(jié)構(gòu)：“作為一個(gè)，我想這樣”。
• 用戶故事是協(xié)作設(shè)計(jì)工具，期望所有項(xiàng)目利益相關(guān)者參與用戶故事的定義和排序。
• 用戶故事將項(xiàng)目的重點(diǎn)放在那些使用者角度。

這聽起來(lái)不是以用戶為中心的哲學(xué)和發(fā)展過(guò)程的核心嗎？然而，它是來(lái)自敏捷開發(fā)的工具。

那么，為什么不接受它們呢？

用戶故事：顯然是以用戶為中心

當(dāng)然，有些團(tuán)隊(duì)不進(jìn)行任何用戶研究，并根據(jù)他們的想法編寫用戶故事。雖然這不是最佳選擇，但它比考慮“我”要好得多。一點(diǎn)想象力可以創(chuàng)造奇跡，同時(shí)注意用戶與設(shè)計(jì)者的不一樣。只是為了強(qiáng)調(diào)這種思維方式的相關(guān)性，你可以向所有利益相關(guān)者，解釋一下像下面這樣的小方案。

“例如，如果你必須設(shè)計(jì)一個(gè)迎合音樂(lè)家的網(wǎng)站，他們可以選擇風(fēng)格和效果來(lái)幫助他們創(chuàng)作歌曲，你需要考慮很多類型的音樂(lè)家?？蛻粢筇峁┚哂懈鞣N效果的菜單。可能你會(huì)突然想到的是汽車音響的CD上的一首歌，拋棄這個(gè)想法吧，因?yàn)槟阆氲氖恰拔摇薄?/p>

相反，想一想：

• “我” 可以是任何專門研究一種或多種樂(lè)器的音樂(lè)家。如果你認(rèn)為“我”是一個(gè)沉重的搖滾吉他手，那就回去考慮一下鍵盤手，歌手，貝司手和鼓手……或者，也許是一位古典作曲家正在起草一部歌劇，并希望查看一些關(guān)于樂(lè)譜的想法。
• “我”也是任何類型的作曲家。這可能是輕松傾聽，電子化，或者是，精致，沉重的搖滾樂(lè)?；蛘?，它可能是一位古典主義者，他被委托為一部你未曾見(jiàn)過(guò)的電影編寫原聲帶。

太好了！現(xiàn)在我們已經(jīng)設(shè)法讓團(tuán)隊(duì)思考“更多的可能性”以適應(yīng)我們的用戶，我們能夠創(chuàng)造用戶故事。用戶故事的格式迫使我們站在他人的角度進(jìn)行思考，同時(shí)將他們的需求放在焦點(diǎn)上，對(duì)于同理心的工作，可以讓自己置于用戶的角度。

也許，有時(shí)候，我們不會(huì)根據(jù)實(shí)際數(shù)據(jù)做到這一點(diǎn)，但這是一個(gè)開始。也許通過(guò)這種微小的同理心練習(xí)，管理層和團(tuán)隊(duì)成員可能會(huì)理解出去尋找目標(biāo)用戶的必要性！

理想情況下，作為用戶研究員，您應(yīng)該在用戶故事的定義上起帶頭作用。您可以將您的角色（我們創(chuàng)建的虛構(gòu)用戶）和用戶場(chǎng)景帶到用戶故事會(huì)話中，并為所有利益相關(guān)者構(gòu)建正確的框架。如果沒(méi)有用戶研究階段，只需確保收集盡可能多的現(xiàn)有項(xiàng)目信息。這可以來(lái)自日志或分析，來(lái)自客戶支持，來(lái)自計(jì)算機(jī)研究，競(jìng)爭(zhēng)分析等。在我們音樂(lè)網(wǎng)站的互動(dòng)場(chǎng)景中，我們很幸運(yùn)的是客戶告訴我們，他是主要為電視節(jié)目中的音樂(lè)處理的鍵盤手。

作為用戶體驗(yàn)設(shè)計(jì)師，您是項(xiàng)目開發(fā)期間用戶的“聲音”。嘗試用盡可能多的現(xiàn)實(shí)環(huán)境進(jìn)行思考，并將這個(gè)“用戶聲音”翻譯成用戶故事，以便每個(gè)人都記住它。

用戶故事簡(jiǎn)單易懂

如果你來(lái)自“舊學(xué)?！?，你可能還記得用戶用例。也許用戶故事會(huì)提醒你關(guān)于你用戶的一切。好吧，雖然有一些相似之處，但差異性使得用戶故事更好。

用例具有特定的語(yǔ)法和結(jié)構(gòu)，因此，并非每個(gè)人都參與定義它們，只有負(fù)責(zé)定義要求或功能規(guī)格的團(tuán)隊(duì)或負(fù)責(zé)人才能編寫。用例是客戶端（有時(shí)是用戶和開發(fā)團(tuán)隊(duì)）之間的橋梁，因此，促進(jìn)“輪胎擺動(dòng)”模型，我們看到會(huì)發(fā)生什么……

在上圖的模型中，我們發(fā)現(xiàn)了每個(gè)人對(duì)于用戶的需求解析出現(xiàn)了一些可怕的錯(cuò)誤！但用戶故事以其簡(jiǎn)潔和專注，提供了避免此類情況的完美方式。參與團(tuán)隊(duì)的任何人都可以參與其中。他/她只需要了解特定語(yǔ)法的相關(guān)性：

• 作為一個(gè) 。角色指的是做出行動(dòng)和受益的人。
• 我想要 。這是執(zhí)行的動(dòng)作。
• 以便 。它是用戶從操作中獲得的附加值。

通過(guò)這個(gè)簡(jiǎn)短的陳述，用戶故事可以縮短學(xué)習(xí)時(shí)間！如果您來(lái)自參與式設(shè)計(jì)方法，您還可以讓用戶參與用戶故事的撰寫。

用戶故事是協(xié)作的

正如我們之前所說(shuō)，您作為用戶體驗(yàn)設(shè)計(jì)師的目標(biāo)是促進(jìn)最終用戶的具體，現(xiàn)實(shí)和共享的愿景，用戶故事是你最好的盟友。由于它們的可訪問(wèn)性和靈活性，您可以使用它們來(lái)構(gòu)建公共語(yǔ)言和項(xiàng)目所涉及的常見(jiàn)心理模型。因此，您可以讓所有利益相關(guān)者 – 客戶，管理層，團(tuán)隊(duì)成員 – 使用相同的語(yǔ)言，并專注于用戶以及項(xiàng)目正在嘗試實(shí)現(xiàn)的目標(biāo)。

用戶故事促進(jìn)了項(xiàng)目討論方式的轉(zhuǎn)變，我們不再關(guān)注解決方案和功能。我們專注于“真實(shí)”用戶能夠?yàn)樘囟康亩Φ哪繕?biāo)，我們沒(méi)有一個(gè)可疑的抽象功能列表，我們將項(xiàng)目的最終目標(biāo)集中在如何讓用戶做具體和有形的事情上。

用戶故事講述的是現(xiàn)在和未來(lái)

用戶故事通常寫在Post-its上，起初，Post-it的數(shù)量可能是壓倒性的，但它比永無(wú)止境的需求文檔更易于管理！

用戶故事具有恰當(dāng)?shù)脑敿?xì)程度。在更抽象的層面上，我們有“epics”。在敏捷開發(fā)中，“epics”用于所需功能的高級(jí)概述。因此，他們收集了一組用戶故事。如果您正在構(gòu)建親和關(guān)系圖，則epics將是一組常見(jiàn)用戶故事的名稱。 Epics使項(xiàng)目中的每個(gè)人都可以從許多用戶的角度看待設(shè)計(jì)，那么任何不合理的方面都可以顯示出來(lái)。用戶是否需要“嘗試”未經(jīng)計(jì)劃或計(jì)劃得好的東西也可以通過(guò)此得以驗(yàn)證。

用戶故事必須足夠具體，以便項(xiàng)目團(tuán)隊(duì)可以在沖刺期間選擇并處理它們。在此之前，團(tuán)隊(duì)?wèi)?yīng)該從一開始就深入研究細(xì)節(jié)并解決可用性問(wèn)題。作為用戶界面設(shè)計(jì)師，您應(yīng)該成為項(xiàng)目團(tuán)隊(duì)的一員，并與開發(fā)人員合作，使用戶故事真實(shí)可用。

用戶故事的簡(jiǎn)單語(yǔ)言有助于每個(gè)人了解每個(gè)sprint中正在構(gòu)建的內(nèi)容，所有利益相關(guān)者都可以查看他們的關(guān)注點(diǎn)和需求是如何得到解決的。因此，用戶故事非常適合設(shè)置階段和定義項(xiàng)目范圍，它們也是定義后續(xù)步驟的理想選擇。因?yàn)樗鼈兲幱谕昝赖牧６燃?jí)別（即完美的細(xì)節(jié)級(jí)別），所以當(dāng)項(xiàng)目遭遇特殊變動(dòng)時(shí)，用戶故事可以幫助你更好地看清一切。

選擇

用戶故事一開始是作為敏捷和SCRUM開發(fā)方法的一部分，作為用戶體驗(yàn)設(shè)計(jì)師，我們需要擁抱它并使用這種簡(jiǎn)單的方法來(lái)實(shí)現(xiàn)我們自己的“好處”，這對(duì)于用戶而已也是很好的設(shè)計(jì)方法！

用戶故事為設(shè)計(jì)人員提供了創(chuàng)建用戶的真實(shí)，具體和共享理念所需的一切：

• 用戶故事基于用戶目標(biāo); 因此，他們可以專注于產(chǎn)品的核心用戶；
• 用戶故事是易于訪問(wèn)和管理的; 因此，它們促進(jìn)利益相關(guān)者和團(tuán)隊(duì)成員之間的協(xié)作；
• 用戶故事有助于從一開始就創(chuàng)建“項(xiàng)目心理模型”。

通過(guò)一個(gè)非常簡(jiǎn)單和具體的結(jié)構(gòu)，用戶故事可以幫助項(xiàng)目專注于許多方面，例如：以用戶為中心，以目標(biāo)為中心，以及在每個(gè)階段應(yīng)該實(shí)施什么內(nèi)容，如何選擇和拋棄。

敏捷開發(fā)是一種很好的以用戶為中心的設(shè)計(jì)方法，不單單是因?yàn)樗梢詾槲覀兲峁┭芯亢陀?jì)劃的一個(gè)更好的方向，同時(shí)他還可以幫助我們構(gòu)建以及創(chuàng)造出項(xiàng)目中每一個(gè)可能性的轉(zhuǎn)折點(diǎn)，用戶故事為我們提供了在最重要的用戶研究和用戶需求方面的一個(gè)可靠的理解和體會(huì)。

個(gè)人感想

我作為一名產(chǎn)品經(jīng)理，當(dāng)我去開啟一個(gè)項(xiàng)目，進(jìn)行背景以及功能點(diǎn)的解說(shuō)是，我通常會(huì)采用用戶故事的方法來(lái)敘述整一套的用戶流程，同時(shí)我也希望我的團(tuán)隊(duì)這么去做。對(duì)于理論以及長(zhǎng)篇大論的需求文章來(lái)說(shuō)，人們更能記住故事發(fā)生的場(chǎng)景，通過(guò)簡(jiǎn)短但是詳盡的故事描述，讓程序員和設(shè)計(jì)師來(lái)理解，產(chǎn)品的用心良苦，從而達(dá)到，為用戶提供設(shè)計(jì)服務(wù)，而不是產(chǎn)品單方面的猜測(cè)。

建議大家可以多采用 Persona 以及 Scenerio 來(lái)為更多人講述你設(shè)計(jì)的產(chǎn)品的初衷。只有當(dāng)你成功的說(shuō)服了別人，人們才會(huì)愿意為此埋單。

本文翻譯自：《User Stories: As a [UX Designer] I want to [embrace Agile] so that [I can make my projects user-centered]》

本文由@ vivi 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unspalsh, 基于CC0協(xié)議