【譯點料】使用者故事：UI設計的基石

前言：嗨，小夥伴兒們，這裡是願得同理心場景不分離的「互動坊」。在需求分析階段，互動設計師是作為產品經理的補充，一方面瞭解需求，一方面幫助產品更好的細化和完善使用者需求，其工作的重點還是在需求分析之後的部分。所謂高階互動設計師等於半個產品經理，就是這個道理。

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

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

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

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

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

3.使用者故事可以防止出現功能蔓延以及設計死衚衕。

什麼是使用者故事？

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

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

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

“作為使用者我需要建立一個新帳戶。”

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

“作為使用者我需要輸入一個新使用者名稱。”

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

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

“作為使用者我需要提交資訊，建立帳戶。”

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

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

以使用者為中心

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

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

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

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

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

促進合作

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

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

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

防止出現功能蔓延以及設計死衚衕

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

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

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

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

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

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

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

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

後續

下面是幾條大家做UI設計時思考使用者故事的提示：

在開始視覺設計之前確定出完整的一套使用者故事。抑制住自己直接跳入設計的衝動可以節省時間，避免不必要的頭痛和無用功。

對於每個使用者故事，看看是否能繼續細化成更具體的故事。長篇大論適合於從巨集觀角度概括所需功能，但是細枝末節的地方也不能忽略。在早期深入細節，從一開始就解決實用性問題。

不要把設計元素放到沒有對應使用者故事的介面上。對每個元素的內容和產生原因進行記錄可以讓條理更清晰，在向開發團隊移交時會更加順利。

來源：網秦UEC