[[130480]]

一支設計團隊坐下來討論為一家新客戶所設計的應用的第一輪模型情況。隨著團隊成員不斷提出想法，我們發現大家對于這個應用是什么？其功能應該是什么樣有著截然不同的看法。后來，會議迅速變成了“誰對誰錯”而不是“什么對什么錯”的爭論。大家紛紛為自己的設計辯護，但沒有一個人站在用戶角度說話。聽著耳熟嗎？正是在這種時刻，我們迫切需要描繪用戶故事。

今時今日，很多UI/UX專業人士都開始意識到自己工作的環境進入了Agile狀態。Agile開發（和設計）流程需要快速推進，相應地，我們也需要能夠實現快速、高效協作的工具。這個聽起來像是個矛盾，但實際上確實有很多工具能夠幫助我們在不增加項目時間的情況下有效合作。用戶故事就是針對“Agile法”的工具，在運用到UI設計流程時，其能夠為后續的設計階段提供堅定的基石。簡約版的用戶故事操作起來幾乎不用時間，但卻能對保證項目按軌道運行帶來奇跡般的效果。

我們的UI設計團隊會在流程中運用用戶故事，而在運用過程中我們發現，用戶故事幫我們做到了三件事。

1. 用戶故事可以讓產品以用戶為核心。

2. 用戶故事可以促進團隊成員之間的合作。

3. 用戶故事可以防止出現功能蔓延以及設計死胡同。

什么是用戶故事？

從根本上說，用戶故事的用途是描述用戶通過使用軟件產品想要實現的任務。用戶故事起源于Agile和Scrum開發策略，但是對于設計師來說，用戶故事主要用來提醒用戶目標以及對各個界面設計進行整理和排序。

一個用戶故事就是簡單的一句話。可以用這句作為模板：“作為用戶我需要（基本用戶目標）”。因為故事都很簡短而且有針對性，所以需要多個不同的故事來覆蓋所有可能的用戶案例。事實上，我們會想辦法把每個故事進行細化。

舉個例子，一個用戶故事剛開始時是：

“作為用戶我需要創建一個新帳戶。”

但是新建帳戶的過程中又涉及到哪些步驟呢？用戶需要提供用戶名、密碼以及其他相關信息。其中每個操作都需要有相對應的用戶故事，故事越具體，到后期對設計師和開發來說就會越方便。那么，“創建新帳戶”就可以進一步細化為：

“作為用戶我需要輸入一個新用戶名。”

“作為用戶我需要輸入密碼。”

“作為用戶我需要再次輸入密碼進行確認。”

“作為用戶我需要提交信息，創建帳戶。”

這樣繼續下去，最后就會得到一大長串用戶故事，其中大部分都需要加入到最終產品內。

我們最近為Quiksilver服裝設計了一款iPad應用，可以讓銷售其貨物的店鋪跟蹤當前存活狀態，以便輕松下單訂新貨。就是這么一款看似非常簡單明了的應用，我們想出了266個用戶故事（剛開始時）。你們都沒想到細節能夠細到這種程度吧！

以用戶為中心

作為設計師，我在第一次和項目相關人員開會的時候就會開始考慮布局和配色方案。在聽他們說目標以及了解終端用戶情況的同時，我就能想象出這款應用應該是什么樣的。但關鍵在于不能本末倒置——我們要先確定用戶故事，讓用戶故事道出設計，而不能倒過來搞。

在對應用的所有用戶故事做完腦暴之后，我們會把故事放到Google的合作電子表格上，以便客戶在想到有其他用戶故事時隨時添加。在客戶和團隊感覺已經窮盡所有內容之后，我們會給每個故事一個編號。這些編號到項目后期會派上大用場，我們會用編號作為一個簡明的標簽來表示哪些故事需要在哪個時間段處理。

這個表格的功能不僅是提醒我們應用的功能，還能讓我們在整個流程中與用戶緊密相聯。每個用戶故事都是針對于我們終端用戶的，以便保證始終照顧到他們的需求。這一點在一個有關約會應用的項目中表現的尤其明顯。

關于這個應用，我在給“用戶資料”頁面做線框圖的時候，最開始以為需要添加一個“保存用戶”功能按鈕。但是，我不經意瞟了一眼“用戶資料”部分，突然想起來用戶故事中的一個細節：“作為用戶我需要收藏其他用戶。”

把“保存”一詞改成“收藏”這個決定雖小但很關鍵，因為“保存”用戶聽起來冷冰冰的，而“收藏”則契合了用戶有關約會的心態。設計師容易陷入到技術的陷阱中，特別是在對功能投入了大量時間之后。而用戶故事可以提醒我們時刻以用戶體驗為核心，因為用戶體驗是最終決定應用性格的東西。

促進合作

UI設計通常涉及到的人不止一個。其中還可能包括客戶、設計師、程序員以及一大堆的其他職位工作人員，具體要取決于公司的規模大小。從很多方面說，這就類似于一隊人劃船。要贏得比賽，團隊的每個成員都要以相同的速度朝著相同的方向一齊劃槳。這并不是說所有人的意見都要始終統一，而是說所有人都要有統一的目標并且清楚自己在團隊中的角色。

雖然我們在CitrusBits所采用的流程遠算不上完美，但是我們卻發現用戶故事能夠保證船上的人勁都往一處使。以用戶故事為基準做出決策讓我們得以明確定義出應用的目標。這樣一來就大大降低了團隊合作時的障礙，因為我們用簡短、有針對性的詞句明確定義出了共同的目標。

另外，用戶故事還能讓身處不同地理位置的團隊更加輕松的合作。我們在為一家舊金山客戶開發一款問答類應用時，我們在海灣地區的團隊會時不常的和客戶碰面討論應用要求。他們寫出了用戶故事（但并沒有在項目期間進行其他修改）然后放到了Google Drive。而我們身處洛杉磯的團隊則可以在畫線框圖的同時隨時參考用戶故事，并進行必要的改動。要不是有了這個步驟，這個項目所花費的時間會長的很多，而且還會需要通過大量漫長的解釋工作來解決這些簡短用戶故事幾分鐘就能解決的問題。

防止出現功能蔓延以及設計死胡同

“功能蔓延”是一個UI設計中常見的詞。它是指相關人員會不自覺地不斷增加新功能，擴展項目范圍，這既包括硬件也包括軟件方面。

這幅漫畫完美地詮釋了功能蔓延。

當然，在項目進展期間我們是不反對更改要求的。但是，除非有明確的用戶故事告訴我們原因，我們會拒絕哪怕添加一個簡單的文本框。我們之所以在這方面這么強硬，是因為之前看到過有的項目超出控制、丟掉中心最后無法實現最初設定的目標。

舉個例子，不久之前，我們有個客戶忽略了用戶故事這回事。當時我們正在給一家處理保密資產的公司搭建應用，客戶想要做一款能夠管理員工之間通訊的應用。主要的通訊手段是一個使用文字信息和圖片的公司內部對話平臺（這一點我們都認可了），這個我們記錄到了用戶故事里。后來，客戶又要求增加視頻、語音信息和位置分享。為了保持我們“靈活”的形象，我們想辦法把這些內容加入了新的通訊系統，也因此擴大了項目范圍，推遲了時限，在做完了全部工作之后我們卻發現添加的內容其實對終端用戶沒用。

盡管新增的功能也很屌，但我們最開始的初衷是做一款盡量簡化通訊的應用以便促進團隊建設和協作，不讓他變成一個公司內部的Facebook。于是，我們又回到了用戶故事并重新提醒了客戶做應用的初衷，最后成功組織了功能蔓延，回到了正軌。多方面的實驗盡管能帶來很多很棒的成果，但是如果產品無法滿足根本要求，再精巧也沒意義。

通過這次教訓，我們在開發Quicksilver這個針對B2B公司的銷售類應用時嚴格遵照用戶故事開展流程。最后，最終產品一絲不茍地遵守了最初設計，這主要歸功于我們在前期積累了一套全面的用戶故事。以用戶故事為基石為后期節省了大量工作，同時也讓我們的工作更加有序、更加以用戶為中心。盡管產品的每次迭代都帶來了更多的用戶和客戶反饋，但產品理念的核心一直屹立不倒。

產品從最初設計到最終成品變化非常小。

每個用戶故事對于設計團隊和開發團隊來說都有自己的一套意義。時刻思考技術限制雖然說是好的，但是畢竟我們說的是“用戶故事”，不是“開發的故事”也不是“設計師的故事”。正因為我們通過用戶故事對用戶的觀點進行了排序整理，我們才能更輕松地了解所面臨的問題進而創造出一款真正有用的最終產品。