用戶故事描述了用戶想通過使用軟件達(dá)成的一些事，對于設(shè)計(jì)師而言，它們主要是提醒用戶目標(biāo)以及組織和優(yōu)先考慮每個(gè)屏幕怎樣設(shè)計(jì)的一種方式。

設(shè)計(jì)團(tuán)隊(duì)坐下來分享新客戶的app的第一輪模型。隨著團(tuán)隊(duì)成員提出自己的想法，很明顯，每個(gè)人對app是什么以及應(yīng)如何運(yùn)行都有著截然不同的想法。會議很快變成了關(guān)于誰是對的，而不是什么是對的討論。每個(gè)人都在捍衛(wèi)自己的設(shè)計(jì)，沒有人在捍衛(wèi)用戶。聽起來有點(diǎn)耳熟？在這種情況下，我們需要實(shí)施用戶故事。

如今，許多UI / UX專業(yè)人員發(fā)現(xiàn)自己在一個(gè)敏捷世界中工作。敏捷開發(fā)（和設(shè)計(jì)）過程快速發(fā)展；因此，我們需要能夠進(jìn)行快速，有效協(xié)作的工具。這聽起來有些矛盾，但是有些工具可以幫助我們一起工作，而無需增加工作時(shí)長。

用戶故事是敏捷方法論¹（Agile methodology）中特有的，當(dāng)應(yīng)用在UI設(shè)計(jì)流程時(shí)，它們?yōu)楹罄m(xù)的設(shè)計(jì)階段提供了必要的基礎(chǔ)。精簡版的用戶故事幾乎不需要花費(fèi)時(shí)間來實(shí)現(xiàn)，但是可以使項(xiàng)目保持正常運(yùn)轉(zhuǎn)。

在移動(dòng)應(yīng)用程序開發(fā)公司CitrusBits，我們的UI設(shè)計(jì)團(tuán)隊(duì)在開發(fā)過程中實(shí)施了用戶故事，我們發(fā)現(xiàn)它完成了三件主要的事情：

1. 用戶故事保持產(chǎn)品用戶專注
2. 用戶故事促進(jìn)團(tuán)隊(duì)成員間的合作
3. 用戶故事防止特征蠕動(dòng)²（feature creep）和設(shè)計(jì)死角（design dead-ends）

01 什么是用戶故事

其核心就是，用戶故事描述了用戶想通過使用軟件達(dá)成的一些事。它們源于Agile andScrum開發(fā)策略的一部分，但對于設(shè)計(jì)師而言，它們主要是提醒用戶目標(biāo)以及組織和優(yōu)先考慮每個(gè)屏幕怎樣設(shè)計(jì)的一種方式。

一個(gè)用戶故事是一則很短的故事，實(shí)際上大概只有一句話，如模板：“作為一個(gè)用戶，我想……[用戶基本目標(biāo)]?！?/p>

因?yàn)檫@些故事很簡短和具體，需要很多故事來覆蓋到所有的使用案例。事實(shí)上，我們試著把每個(gè)故事都講一遍，看它能被分解到什么程度。

舉個(gè)例子，一個(gè)用戶故事可以從這開始：

“作為一個(gè)用戶，我想創(chuàng)建一個(gè)新的賬戶?！?/p>

但是創(chuàng)建一個(gè)新賬戶究竟包含哪些內(nèi)容呢？用戶需要提交一個(gè)用戶名、密碼以及其他相關(guān)的信息。

每個(gè)單獨(dú)的動(dòng)作需要一個(gè)與之相關(guān)的用戶故事，每個(gè)故事越具體，之后設(shè)計(jì)人員和開發(fā)人員的事情越容易。所以“創(chuàng)建一個(gè)新用戶”實(shí)際上可以進(jìn)一步別分解：

“作為一個(gè)用戶，我想輸入一個(gè)新名字?！?/p>

“作為一個(gè)用戶，我想輸入一串密碼?！?/p>

“作為一個(gè)用戶，我想重新輸入我的密碼以便確認(rèn)它?！?/p>

“作為一個(gè)用戶，我想提交這個(gè)信息并創(chuàng)建一個(gè)新賬戶。”

如果準(zhǔn)確的做完這些，最終結(jié)果會是一長串的用戶故事，其中大部分我們將納入到最終產(chǎn)品。

在Citrusbits，我們最近為Quiksilver clothing開發(fā)了一款iPad app，該app能夠使攜帶其產(chǎn)品的商店跟蹤其當(dāng)前庫存并輕松訂購新的和額外的產(chǎn)品。為了使它能夠看起來像一個(gè)相當(dāng)易用的app，我們想了266條獨(dú)立故事。

02 保持用戶專注

作為一個(gè)設(shè)計(jì)師，在與項(xiàng)目相關(guān)者參與第一次會議時(shí)我就開始在腦海里把布局和配色方案拼接在一起。當(dāng)我聽到他們的目標(biāo)，了解到最終用戶時(shí)，我就能夠預(yù)想出這個(gè)app大概的樣子。在我們首先確定用戶故事時(shí)，我們不能本末倒置，我們應(yīng)讓用戶故事決定設(shè)計(jì)，而不是讓設(shè)計(jì)決定用戶故事。

當(dāng)為一款app頭腦風(fēng)暴過所有用戶故事后，我們把它放到Google spreadsheet中，客戶可以向里面添加任何感覺缺少的故事。一旦客戶和團(tuán)隊(duì)認(rèn)為我們已經(jīng)涵蓋了所有基礎(chǔ)故事，我們便會為每個(gè)故事編號。當(dāng)我們將數(shù)字用作簡潔的標(biāo)簽來標(biāo)識哪些線框所涵蓋的故事時(shí)，這些數(shù)字在項(xiàng)目后期特別有用。

這個(gè)表不僅提醒我們功能性，還使我們整個(gè)過程中與用戶聯(lián)系在一起。每個(gè)用戶故事都經(jīng)過專門設(shè)計(jì)以適應(yīng)我們的最終用戶，從而確保我們能夠滿足他們的需求。在涉及約會app的項(xiàng)目中，這一點(diǎn)尤為明顯。

當(dāng)我為“用戶個(gè)人資料”頁面建立線框圖時(shí)，最初，我認(rèn)為在app中為“保存用戶”這一功能添加一個(gè)按鈕用來標(biāo)記該用戶是合適的。然而，瀏覽“用戶個(gè)人資料”部分使我想起了用戶故事中的一個(gè)細(xì)節(jié)：“作為用戶，我想收藏另一個(gè)用戶?！?/p>

“保存”到“收藏”的改變是一個(gè)很小但是有價(jià)值的決定，“保存”一個(gè)用戶是冰冷、缺乏人情味兒的，而“收藏”則與用戶的約會心態(tài)保持一致。設(shè)計(jì)人員往往拘泥于技術(shù)之中，尤其是在功能性上工作了若干小時(shí)之后，而用戶故事則幫助我們提醒我們始終專注于用戶體驗(yàn)，從而賦予app特色。

03 促進(jìn)合作

一個(gè)UI設(shè)計(jì)通常有多個(gè)關(guān)心結(jié)果的相關(guān)人員。這個(gè)團(tuán)隊(duì)可能包括客戶、設(shè)計(jì)師、程序員、其他許多職務(wù)，具體取決于組織規(guī)模大小。在很多方面，情況都與參加賽艇隊(duì)類似。為了贏得比賽，每個(gè)隊(duì)員必須以相同的速度和方向劃槳。這并不意味著每個(gè)人對所有事都做出相同的選擇，這只是意味著每個(gè)人都要專注于同一目標(biāo)，知道如何融入團(tuán)隊(duì)。

盡管我們在CitrusBits的流程遠(yuǎn)非完美，但我們發(fā)現(xiàn)用戶故事可以使每個(gè)人保持一致。能夠使決策與用戶故事保持一致，從而使應(yīng)用程序的目標(biāo)清晰明了且定義明確。這降低了團(tuán)隊(duì)合作的障礙，因?yàn)槲覀円呀?jīng)用簡短，具體的詞組確定了我們的集體目標(biāo)。

用戶故事還使位于不同位置的團(tuán)隊(duì)更容易進(jìn)行協(xié)作：

當(dāng)我們?yōu)槲挥谂f金山的客戶開發(fā)trivia quiz app時(shí)，我們的灣區(qū)團(tuán)隊(duì)有時(shí)會與客戶會面，討論該app的要求。他們創(chuàng)建了用戶故事,盡管在整個(gè)項(xiàng)目中對其進(jìn)行了修改，并將它們放置到我們的Google云盤中。

然后，作為洛杉磯團(tuán)隊(duì)，我們將在創(chuàng)建線框并根據(jù)需要進(jìn)行更改時(shí)參考用戶故事。如果不是這個(gè)過程，那么該項(xiàng)目將花費(fèi)更長的時(shí)間才能完成，并且將需要長時(shí)間的解釋，然而用大量微型用戶故事只需花費(fèi)幾分鐘。

04 防止特征蠕動(dòng)（feature creep）和設(shè)計(jì)死角（design dead-ends）

特征蠕動(dòng)（featurecreep）是一個(gè)在UI設(shè)計(jì)期間經(jīng)常出現(xiàn)的術(shù)語。它指的是想要繼續(xù)增加更多功能并擴(kuò)大項(xiàng)目范圍的趨勢，無論是硬件還是軟件。

This Brand Camp strip perfectly summarizes scopecreep. Copyright 2005, Tom Fishburne

當(dāng)然，隨著項(xiàng)目的進(jìn)展，我們樂于接受不斷變化的需求。但是，如今我們拒絕在沒有用戶故事的情況下添加太多文本框，而這并不能解釋我們?yōu)槭裁催@個(gè)特定文本框很重要。在看到以前的項(xiàng)目失控，失去關(guān)注并未能實(shí)現(xiàn)其最初目標(biāo)之后，我們決定對此采取強(qiáng)硬措施。

不久前，我們的客戶忽略了用戶故事——

我們正在為一家處理機(jī)密資產(chǎn)的公司開發(fā)一款app，他們想要一個(gè)管理員工之間通信的app。交流的主要方式（我們都同意）是使用文字消息和圖片的公司內(nèi)部聊天平臺，我們將其記錄在用戶故事中。后來，客戶要求添加視頻，語音消息和位置共享。

為了變得“靈活”，我們嘗試將其應(yīng)用到新的通信中，從而擴(kuò)大了范圍并延遲了計(jì)劃，在所有這些努力之后，我們最終意識到添加這些內(nèi)容對最終用戶沒有幫助。

盡管它們是整潔的功能，但最初的原則是創(chuàng)建一個(gè)將通訊簡化到最低限度的app，以促進(jìn)團(tuán)隊(duì)建設(shè)和合作，而無需使用內(nèi)部Facebook。我們將他們帶回了用戶故事，并讓他們想起了該app的初衷，最后，我們能夠阻止特征蠕動(dòng)并重回正軌。實(shí)驗(yàn)可以產(chǎn)生一些奇妙的結(jié)果，但是如果產(chǎn)品不符合基本要求，那么獨(dú)創(chuàng)性將毫無意義。

從錯(cuò)誤中吸取教訓(xùn)后，在使用Quicksilver（面向B2B公司的銷售app）時(shí)，我們始終嚴(yán)格遵守用戶故事。結(jié)果就是最終產(chǎn)品非常符合我們最初的設(shè)計(jì)，主要是因?yàn)槲覀円呀?jīng)完成了構(gòu)建全面的用戶故事的前期工作。在此基礎(chǔ)上建立起來可以節(jié)省之后的工作，并使我們的工作井井有條，以用戶為中心。盡管項(xiàng)目的每次迭代都帶來了更多的用戶和客戶反饋，但該概念的核心仍然很牢固。

The product changed very little from inital designs tofinal product.

每個(gè)用戶故事對設(shè)計(jì)團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)都有一系列影響。盡管牢記技術(shù)限制總是好的，但它們被稱為“用戶故事”，而不是“開發(fā)人員故事”， “設(shè)計(jì)人員故事”。由于我們嘗試使用用戶故事來優(yōu)先考慮用戶的觀點(diǎn)，因此更容易理解當(dāng)前的問題并創(chuàng)建有用的最終產(chǎn)品。

05 下一步

在UI設(shè)計(jì)中嘗試用戶故事時(shí)，需要記住以下幾點(diǎn)：

• 在進(jìn)行任何視覺設(shè)計(jì)之前，請識別出完整的用戶案例。抵制住直接進(jìn)行設(shè)計(jì)的誘惑可能會節(jié)省時(shí)間，避免浪費(fèi)大量精力。
• 對于每一個(gè)用戶故事，看看它是否能別分解為更小，更具體的故事?！癊pics”可以很好地概述所需的功能，但不要太寬泛。盡早深入細(xì)節(jié)，并從一開始就解決可用性問題。
• 切勿把沒有相應(yīng)用戶故事的設(shè)計(jì)元素放置到界面上。記錄每個(gè)元素的內(nèi)容和原因能夠促進(jìn)組織發(fā)展，并使向開發(fā)團(tuán)隊(duì)的交接更加順暢。

1. 敏捷方法論（agile methodologies）（也被稱為輕量級方法論，lightweight methodology），它是一組開發(fā)方法的統(tǒng)稱。隨著技術(shù)的迅速發(fā)展和經(jīng)濟(jì)的全球化，軟件開發(fā)出現(xiàn)了新的特點(diǎn)，即在需求和技術(shù)不斷變化的情況下實(shí)現(xiàn)快節(jié)奏的軟件開發(fā)，這就對生產(chǎn)率提出了很高的要求。
2. 特征蠕動(dòng)(Feature Creep)(有時(shí)候也稱為需求漂移或者是范圍蠕動(dòng))是產(chǎn)品或項(xiàng)目的需要在除了最開始的預(yù)見之外，在開發(fā)過程中產(chǎn)生了新的要求的趨勢，它導(dǎo)致了剛開始沒有計(jì)劃到的特征，對產(chǎn)品的質(zhì)量和計(jì)劃帶來了風(fēng)險(xiǎn)。

原文鏈接：https://www.uxbooth.com/articles/user-stories-a-foundation-for-ui-design/

原作者：Tom Brinton

編譯作者：hubiabia；公眾號：插畫鴨

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

題圖來自Unsplash，基于CC0協(xié)議