起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識UI設計中，用戶故事起到什么樣的作用？
用戶故事是特定于敏捷方法的，當應用到UI設計過程時，它們為設計的后續階段提供了一個重要的基礎。一個精簡版的用戶故事幾乎不需要花費時間來實現，但是卻可以讓項目保持在正軌上。
設計團隊坐下來為新客戶的應用程序共享第一輪模型，當團隊成員展示他們的想法時，很明顯每個人對于這個應用是什么以及它應該如何運行都有不同的想法。
會議很快就變成了關于誰而不是什么是正確的討論，每個人都在為自己的設計辯護，沒有人在為用戶辯護。聽起來是不是很熟悉?像這樣的時刻，我們需要實現用戶故事。
今天，許多UI/UX專業人員發現自己在敏捷世界中工作，敏捷開發（和設計）過程進展迅速，因此，我們需要能夠實現快速、高效協作的工具。這聽起來像是矛盾修飾法，但是有一些工具可以幫助我們一起工作，而不需要在時間表上增加天數。
用戶故事是特定于敏捷方法的，當應用到UI設計過程時，它們為設計的后續階段提供了一個重要的基礎。一個精簡版的用戶故事幾乎不需要花費時間來實現，但是卻可以讓項目保持在正軌上。
在移動應用開發公司CitrusBits，我們的UI設計團隊在我們的過程中實現了用戶故事，我們發現它完成了三件主要的事情：
- 用戶故事使產品以用戶為中心。
- 用戶故事促進團隊成員之間的合作。
- 用戶故事有助于防止特性漸變和設計死胡同。
什么是用戶故事？
用戶故事的核心是描述用戶希望通過使用軟件產品完成的事情，它們最初是敏捷和Scrum開發策略的一部分，但對于設計師來說，它們主要是提醒用戶目標，以及組織和優先考慮每個屏幕設計的方式。
一個用戶故事是一個非常短的故事——實際上只有一句話。這里有一個模板：
“作為一個用戶，我想……【基本用戶目標】?！?/p>
因為這些故事是如此的簡短和具體，所以需要很多故事來涵蓋所有可能的用例。事實上，我們試著把每個故事都記錄下來，看看它能被分解到什么程度。
保持用戶專注
作為一名設計師，我在與項目涉眾的第一次會議上就開始構思布局和配色方案。當我傾聽他們的目標，了解他們的最終用戶時，我可以想象這個應用會是什么樣子。但是，重要的是不要把購物車放在馬的前面——當我們首先識別用戶故事時，我們讓它們來決定設計，而不是反過來。
在對一個應用程序的所有用戶故事進行頭腦風暴之后，我們把它放在一個協作的谷歌電子表格中，在那里客戶可以添加他們感覺缺失的任何故事。一旦客戶和團隊都覺得我們已經覆蓋了所有的基礎，我們就給每個故事分配一個數字。這些數字在項目的后面特別有用，當我們使用它們作為簡潔的標簽來識別包含哪些故事的線框圖時。
這個列表不僅僅是提醒我們功能，它使我們在整個過程中與用戶保持聯系。每個用戶故事都是專門為滿足我們的最終用戶而設計的，確保我們能夠滿足他們的需求。在一個涉及約會應用的項目中，這一點變得尤為明顯。
當我創建線框為“用戶配置文件”頁面，我起初認為這是適當的添加一個用戶“保存”功能通過添加一個按鈕,將標志著他們的應用。然而，一眼“用戶配置文件”部分用戶故事讓我想起了一個細節——“作為用戶我想最喜歡的另一個用戶?！?/strong>
從“保存”到“收藏”的改變是一個很小但很有價值的決定，因為“保存”用戶是冷漠的，沒有人情味的，而“收藏”與用戶的約會心態是一致的。設計師們傾向于落入技術手段的陷阱，尤其是在花了數小時研究功能之后，用戶故事提醒我們要專注于用戶體驗，從而賦予應用自身的特性。
促進合作
UI設計通常有多個涉眾關注結果，這個團隊可以包括客戶、設計師、程序員和許多其他職位，這取決于組織的規模。
在很多方面，這和在賽艇隊里是相似的情況。為了贏得一場比賽，每個隊員必須以同樣的速度和方向，在unisin一起劃船。這并不意味著每個人對每件事都有相同的看法——它只是意味著每個人都專注于同一個目標，知道如何融入團隊。
雖然我們在CitrusBits的過程遠非完美，但我們發現：用戶故事可以讓所有人一起劃船，能夠將決策與用戶故事結合在一起，使應用程序的目標清晰而明確。這降低了團隊合作的障礙，因為我們已經用簡短、具體的短語確定了我們的集體目標。
用戶故事也使位于不同位置的團隊更容易協作，當我們為一個位于舊金山的客戶開發一個小測試應用程序時，我們的灣區團隊偶爾會與客戶會面，討論應用程序的需求。
然后，我們洛杉磯的團隊將在創建線框圖，并根據需要進行更改時引用用戶故事。如果不是這個過程，這個項目要花很長時間才能完成，并且需要很長時間的解釋，才能在幾分鐘內，完成大量的小用戶故事。
防止特性蠕變和設計死角
“特性漸變”是UI設計中經常出現的術語，它指的是希望不斷增加功能并擴展項目范圍的趨勢，無論是硬件還是軟件。
當然，隨著項目的進展，我們愿意改變需求。然而，這些天我們拒絕添加太多的文本框，沒有一個用戶故事來解釋為什么這個文本框很重要。在看到以前的項目失控、注意力不集中、無法完成最初的目標之后，我們決定采取強硬的態度。
在不久前的一個實例中，我們的客戶機忽略了用戶故事。我們正在為一家處理機密資產的公司開發一個應用程序，他們想要一個管理員工之間通信的應用程序。
溝通的主要方式（我們都同意）是公司內部的聊天平臺，使用短信和圖片，我們在用戶故事中記錄下來。后來，客戶要求添加視頻、語音消息和位置共享。為了做到“靈活”，我們嘗試在新的通信中實現，擴展了范圍并延遲了計劃，在所有這些努力之后，我們最終意識到添加對最終用戶沒有好處。
雖然這些功能都很不錯，但最初的原則是創建一個應用程序，將通信簡化到最低限度，以促進團隊建設和合作，而不會變成一個內部的Facebook。我們把它們轉回到用戶故事中，提醒他們這款應用最初的意圖。
最終，我們阻止了這個特性的蔓延，回到了正軌。實驗可以產生一些奇妙的結果，但如果產品不滿足基本需求，獨創性就毫無意義。
我們從錯誤中吸取了教訓，在開發B2B公司的銷售應用Quicksilver時，我們嚴格遵守用戶描述。結果，最終的產品與我們最初的設計保持了驚人的一致，主要是因為我們已經完成了構建一組全面的用戶故事的前期工作。
在此基礎上構建，節省了以后的工作，并使我們的工作保持有序和以用戶為中心。雖然項目的每個迭代都帶來了額外的用戶和客戶的反饋，但是這個概念的核心仍然很強大。
每個用戶故事對設計團隊和開發團隊都有一組含義，雖然保持技術上的限制總是好的，但這些都被稱為“用戶故事”，而不是“開發者故事”，甚至“設計師故事”。
“由于我們試圖用用戶故事優先考慮用戶的觀點，因此更容易理解手邊的問題，并創建一個有用的最終產品?！?/p>
下一個步驟
在UI設計中嘗試用戶故事時，需要記住以下幾點：
- 在進行任何視覺設計之前，先確定一個完整的用戶故事集。抵制直接進入設計的誘惑，可以節省時間、減少頭痛和大量浪費的精力。
- 對于每個用戶故事，看看它是否可以分解成更小、更具體的故事?！笆吩姟睂τ谛枰奶匦缘母呒壐攀鍪呛芎玫?，但是不要太寬泛。深入細節，并在一開始就解決可用性問題。
- 不要在沒有相應用戶故事的界面中，放置設計元素。記錄每個元素的內容和原因可以促進組織，并使開發團隊的交接更加順利。
原文作者：Tom Brinton
原文鏈接：http://www.uxbooth.com/articles/user-stories-a-foundation-for-ui-design/
本文由 @ANG 翻譯發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
作為一個XXX（角色），我想要…（什么功能），以便…（目的）