簡單快速的設(shè)計(jì)方法:用戶故事(場景)
對于理論以及長篇大論的需求文章來說,人們更能記住故事發(fā)生的場景,通過簡短但是詳盡的故事描述,讓程序員和設(shè)計(jì)師來理解,產(chǎn)品的用心良苦,從而達(dá)到,為用戶提供設(shè)計(jì)服務(wù),而不是產(chǎn)品單方面的猜測。
讓我們來了解一個簡單而又強(qiáng)大的工具,這是一種很好的設(shè)計(jì)方法,你可以在所有項(xiàng)目中應(yīng)用它,同時可以增強(qiáng)所有利益相關(guān)者的合作。
敏捷設(shè)計(jì)的核心部分是用戶需求也就是用戶故事。有很多關(guān)于 UX 和敏捷開發(fā)的文章,很多人都在喋喋不休地談?wù)撁艚蓍_發(fā)如何使用戶體驗(yàn)不友好,這兩種方法如何無法協(xié)同工作等等,并且很難適用于軟件項(xiàng)目,與其他學(xué)科合作很有挑戰(zhàn)性。雖然我們正在努力,但我們可能會對許多缺點(diǎn)說“是”進(jìn)行妥協(xié),而且我們不會在一篇文章中解決這些問題。
今天我們關(guān)注的是一種簡單快速的設(shè)計(jì)方法,稱為“用戶故事”,可以幫助您解決許多這些挑戰(zhàn)。
為什么?
- 用戶故事簡短,具體且面向目標(biāo)。這是一句話,往往具有以下結(jié)構(gòu):“作為一個,我想這樣”。
- 用戶故事是協(xié)作設(shè)計(jì)工具,期望所有項(xiàng)目利益相關(guān)者參與用戶故事的定義和排序。
- 用戶故事將項(xiàng)目的重點(diǎn)放在那些使用者角度。
這聽起來不是以用戶為中心的哲學(xué)和發(fā)展過程的核心嗎?然而,它是來自敏捷開發(fā)的工具。
那么,為什么不接受它們呢?
用戶故事:顯然是以用戶為中心
當(dāng)然,有些團(tuán)隊(duì)不進(jìn)行任何用戶研究,并根據(jù)他們的想法編寫用戶故事。雖然這不是最佳選擇,但它比考慮“我”要好得多。一點(diǎn)想象力可以創(chuàng)造奇跡,同時注意用戶與設(shè)計(jì)者的不一樣。只是為了強(qiáng)調(diào)這種思維方式的相關(guān)性,你可以向所有利益相關(guān)者,解釋一下像下面這樣的小方案。
“例如,如果你必須設(shè)計(jì)一個迎合音樂家的網(wǎng)站,他們可以選擇風(fēng)格和效果來幫助他們創(chuàng)作歌曲,你需要考慮很多類型的音樂家??蛻粢筇峁┚哂懈鞣N效果的菜單??赡苣銜蝗幌氲降氖瞧囈繇懙腃D上的一首歌,拋棄這個想法吧,因?yàn)槟阆氲氖恰拔摇薄?/p>
相反,想一想:
- “我” 可以是任何專門研究一種或多種樂器的音樂家。如果你認(rèn)為“我”是一個沉重的搖滾吉他手,那就回去考慮一下鍵盤手,歌手,貝司手和鼓手……或者,也許是一位古典作曲家正在起草一部歌劇,并希望查看一些關(guān)于樂譜的想法。
- “我”也是任何類型的作曲家。這可能是輕松傾聽,電子化,或者是,精致,沉重的搖滾樂?;蛘撸赡苁且晃还诺渲髁x者,他被委托為一部你未曾見過的電影編寫原聲帶。
太好了!現(xiàn)在我們已經(jīng)設(shè)法讓團(tuán)隊(duì)思考“更多的可能性”以適應(yīng)我們的用戶,我們能夠創(chuàng)造用戶故事。用戶故事的格式迫使我們站在他人的角度進(jìn)行思考,同時將他們的需求放在焦點(diǎn)上,對于同理心的工作,可以讓自己置于用戶的角度。
也許,有時候,我們不會根據(jù)實(shí)際數(shù)據(jù)做到這一點(diǎn),但這是一個開始。也許通過這種微小的同理心練習(xí),管理層和團(tuán)隊(duì)成員可能會理解出去尋找目標(biāo)用戶的必要性!
理想情況下,作為用戶研究員,您應(yīng)該在用戶故事的定義上起帶頭作用。您可以將您的角色(我們創(chuàng)建的虛構(gòu)用戶)和用戶場景帶到用戶故事會話中,并為所有利益相關(guān)者構(gòu)建正確的框架。如果沒有用戶研究階段,只需確保收集盡可能多的現(xiàn)有項(xiàng)目信息。這可以來自日志或分析,來自客戶支持,來自計(jì)算機(jī)研究,競爭分析等。在我們音樂網(wǎng)站的互動場景中,我們很幸運(yùn)的是客戶告訴我們,他是主要為電視節(jié)目中的音樂處理的鍵盤手。
作為用戶體驗(yàn)設(shè)計(jì)師,您是項(xiàng)目開發(fā)期間用戶的“聲音”。嘗試用盡可能多的現(xiàn)實(shí)環(huán)境進(jìn)行思考,并將這個“用戶聲音”翻譯成用戶故事,以便每個人都記住它。
用戶故事簡單易懂
如果你來自“舊學(xué)?!?,你可能還記得用戶用例。也許用戶故事會提醒你關(guān)于你用戶的一切。好吧,雖然有一些相似之處,但差異性使得用戶故事更好。
用例具有特定的語法和結(jié)構(gòu),因此,并非每個人都參與定義它們,只有負(fù)責(zé)定義要求或功能規(guī)格的團(tuán)隊(duì)或負(fù)責(zé)人才能編寫。用例是客戶端(有時是用戶和開發(fā)團(tuán)隊(duì))之間的橋梁,因此,促進(jìn)“輪胎擺動”模型,我們看到會發(fā)生什么……
在上圖的模型中,我們發(fā)現(xiàn)了每個人對于用戶的需求解析出現(xiàn)了一些可怕的錯誤!但用戶故事以其簡潔和專注,提供了避免此類情況的完美方式。參與團(tuán)隊(duì)的任何人都可以參與其中。他/她只需要了解特定語法的相關(guān)性:
- 作為一個 。角色指的是做出行動和受益的人。
- 我想要 。這是執(zhí)行的動作。
- 以便 。它是用戶從操作中獲得的附加值。
通過這個簡短的陳述,用戶故事可以縮短學(xué)習(xí)時間!如果您來自參與式設(shè)計(jì)方法,您還可以讓用戶參與用戶故事的撰寫。
用戶故事是協(xié)作的
正如我們之前所說,您作為用戶體驗(yàn)設(shè)計(jì)師的目標(biāo)是促進(jìn)最終用戶的具體,現(xiàn)實(shí)和共享的愿景,用戶故事是你最好的盟友。由于它們的可訪問性和靈活性,您可以使用它們來構(gòu)建公共語言和項(xiàng)目所涉及的常見心理模型。因此,您可以讓所有利益相關(guān)者 – 客戶,管理層,團(tuán)隊(duì)成員 – 使用相同的語言,并專注于用戶以及項(xiàng)目正在嘗試實(shí)現(xiàn)的目標(biāo)。
用戶故事促進(jìn)了項(xiàng)目討論方式的轉(zhuǎn)變,我們不再關(guān)注解決方案和功能。我們專注于“真實(shí)”用戶能夠?yàn)樘囟康亩Φ哪繕?biāo),我們沒有一個可疑的抽象功能列表,我們將項(xiàng)目的最終目標(biāo)集中在如何讓用戶做具體和有形的事情上。
用戶故事講述的是現(xiàn)在和未來
用戶故事通常寫在Post-its上,起初,Post-it的數(shù)量可能是壓倒性的,但它比永無止境的需求文檔更易于管理!
用戶故事具有恰當(dāng)?shù)脑敿?xì)程度。在更抽象的層面上,我們有“epics”。在敏捷開發(fā)中,“epics”用于所需功能的高級概述。因此,他們收集了一組用戶故事。如果您正在構(gòu)建親和關(guān)系圖,則epics將是一組常見用戶故事的名稱。 Epics使項(xiàng)目中的每個人都可以從許多用戶的角度看待設(shè)計(jì),那么任何不合理的方面都可以顯示出來。用戶是否需要“嘗試”未經(jīng)計(jì)劃或計(jì)劃得好的東西也可以通過此得以驗(yàn)證。
用戶故事必須足夠具體,以便項(xiàng)目團(tuán)隊(duì)可以在沖刺期間選擇并處理它們。在此之前,團(tuán)隊(duì)?wèi)?yīng)該從一開始就深入研究細(xì)節(jié)并解決可用性問題。作為用戶界面設(shè)計(jì)師,您應(yīng)該成為項(xiàng)目團(tuán)隊(duì)的一員,并與開發(fā)人員合作,使用戶故事真實(shí)可用。
用戶故事的簡單語言有助于每個人了解每個sprint中正在構(gòu)建的內(nèi)容,所有利益相關(guān)者都可以查看他們的關(guān)注點(diǎn)和需求是如何得到解決的。因此,用戶故事非常適合設(shè)置階段和定義項(xiàng)目范圍,它們也是定義后續(xù)步驟的理想選擇。因?yàn)樗鼈兲幱谕昝赖牧6燃墑e(即完美的細(xì)節(jié)級別),所以當(dāng)項(xiàng)目遭遇特殊變動時,用戶故事可以幫助你更好地看清一切。
選擇
用戶故事一開始是作為敏捷和SCRUM開發(fā)方法的一部分,作為用戶體驗(yàn)設(shè)計(jì)師,我們需要擁抱它并使用這種簡單的方法來實(shí)現(xiàn)我們自己的“好處”,這對于用戶而已也是很好的設(shè)計(jì)方法!
用戶故事為設(shè)計(jì)人員提供了創(chuàng)建用戶的真實(shí),具體和共享理念所需的一切:
- 用戶故事基于用戶目標(biāo); 因此,他們可以專注于產(chǎn)品的核心用戶;
- 用戶故事是易于訪問和管理的; 因此,它們促進(jìn)利益相關(guān)者和團(tuán)隊(duì)成員之間的協(xié)作;
- 用戶故事有助于從一開始就創(chuàng)建“項(xiàng)目心理模型”。
通過一個非常簡單和具體的結(jié)構(gòu),用戶故事可以幫助項(xiàng)目專注于許多方面,例如:以用戶為中心,以目標(biāo)為中心,以及在每個階段應(yīng)該實(shí)施什么內(nèi)容,如何選擇和拋棄。
敏捷開發(fā)是一種很好的以用戶為中心的設(shè)計(jì)方法,不單單是因?yàn)樗梢詾槲覀兲峁┭芯亢陀?jì)劃的一個更好的方向,同時他還可以幫助我們構(gòu)建以及創(chuàng)造出項(xiàng)目中每一個可能性的轉(zhuǎn)折點(diǎn),用戶故事為我們提供了在最重要的用戶研究和用戶需求方面的一個可靠的理解和體會。
個人感想
我作為一名產(chǎn)品經(jīng)理,當(dāng)我去開啟一個項(xiàng)目,進(jìn)行背景以及功能點(diǎn)的解說是,我通常會采用用戶故事的方法來敘述整一套的用戶流程,同時我也希望我的團(tuán)隊(duì)這么去做。對于理論以及長篇大論的需求文章來說,人們更能記住故事發(fā)生的場景,通過簡短但是詳盡的故事描述,讓程序員和設(shè)計(jì)師來理解,產(chǎn)品的用心良苦,從而達(dá)到,為用戶提供設(shè)計(jì)服務(wù),而不是產(chǎn)品單方面的猜測。
建議大家可以多采用 Persona 以及 Scenerio 來為更多人講述你設(shè)計(jì)的產(chǎn)品的初衷。只有當(dāng)你成功的說服了別人,人們才會愿意為此埋單。
本文翻譯自:《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)載
題圖來自Unspalsh, 基于CC0協(xié)議
作為譯文而言,翻譯水平無可指責(zé),但原作是有上下文、有與這篇譯文不同的閱讀群體的,你應(yīng)當(dāng)考慮到這些差異,會點(diǎn)進(jìn)來看這篇文章的大部分應(yīng)該是希望了解并學(xué)習(xí)“用戶故事”這種設(shè)計(jì)方法,而不是來看“用戶故事很好用”,大家并不知道它是什么樣子的。這篇譯文描述了用戶故事的特質(zhì)和優(yōu)點(diǎn),卻沒有具體案例,實(shí)在不適合單獨(dú)閱讀。譯者可以看下站內(nèi)同樣介紹用戶故事的幾篇文章的結(jié)構(gòu)對比下。
好的,謝謝。
首先感謝分享。其次文章結(jié)構(gòu)上確實(shí)有些難以理解,太多的理論和優(yōu)點(diǎn)介紹,但我看完之后無法認(rèn)識到用戶故事具體是什么樣子的。建議放幾個實(shí)際案例和對應(yīng)的用戶故事,以便于不知道什么是“用戶故事”的讀者理解,而不只是告訴已經(jīng)知道“用戶故事”的讀者這是個好東西。
目測作者是設(shè)計(jì)轉(zhuǎn)產(chǎn)品,我猜的可對?
為什么這么說呢
因?yàn)楣た票尘暗漠a(chǎn)品在年復(fù)一年與程序員的較量中已經(jīng)會發(fā)現(xiàn),就算他們不理解你的場景,只要按流程圖、交互原型、數(shù)據(jù)流圖實(shí)現(xiàn)功能,就肯定錯不了~與其花心思講故事,不如畫圖性價比高
花心思講故事,其實(shí)是為了讓程序員更好地去理解使用場景,以及實(shí)現(xiàn)的目標(biāo)。流程圖,原型圖都是一種方式,去硬生生地把一件東西還原。就好像你看書一樣,說了很多理論,你好像懂了,其實(shí)還不如一個故事來的簡單。
團(tuán)隊(duì)合作大型項(xiàng)目講究明確職能邊界,標(biāo)準(zhǔn)工具就是能起到這個作用,擺一個故事在哪,研發(fā)跑偏了算誰的呢?絕大多數(shù)都是為了工資去工作的,并不會積極去理解項(xiàng)目,只想完成任務(wù)而已,講故事太理想化
感覺作者的邏輯有點(diǎn)亂,說的全是大道理
請問能否具體指出一下?
說了一大推廢話,不知道說些啥,舉幾個貼切的例子,通俗易懂點(diǎn),你這用戶體驗(yàn)極差
其實(shí)整個的核心就是:
– 作為一個 。角色指的是做出行動和受益的人。
– 我想要 。這是執(zhí)行的動作。
– 以便 。它是用戶從操作中獲得的附加值。
去敘述用戶場景,其實(shí)文中,作者是有舉例的,但是并不多。文中可能沒有提及太多的例子,所以造成了你覺得廢話連篇,可能是我翻譯的不夠到位,或者你可以看一下原文。看看是否對你會有更大的幫助?謝謝