首先，我承認這次標題黨了，其實我要說的是 - 設計
為了證明我不是純粹的標題黨，我先貼上自己翻譯的第一篇文章，來自Uber設計師，講述了一段他與共享單車的故事......
故事開始的地方
2010年，倫敦推出了巴克萊自行車出租的共享方案。這是一篇我積極改變自己生活與這個城市的故事。
為了遵守我的保密協議，我省略了部分機密信息，重新包裝了這些設計過程。故事開始了，他的名字叫 London By Bike。
我的角色
我們的團隊負責的用戶體驗策略和移動端應用的設計部分。我帶領UX團隊交付產品中所有和用戶體驗交互相關的內容，并應用于2011年11月到2012年3月之間的客戶。在此期間，我與一個初級UX架構師一起專注于Android部分的應用程序設計。
我們所面臨的困難，只有兩個月時間
客戶只給了我們兩個月的時間讓我們提高他們的應用程序的功能性和可用性，使其超出其他競爭對手，并促進相關社區的用戶活躍度。
為了配合在東倫敦擴張的方案，我們的隊伍走的很快，頂著巨大的壓力。我們的任務是在2個月內提供iPhone和Android的高保真原型給我們的開發方合作伙伴。一個固定的最后期限，在應用程序商店提交，完成安全測試和可用性測試，這意味著我需要在第一個月就要完成正確用戶體驗信息的采集和分析。
專注于目標，而不是功能
雖然我們的任務是開發出比競爭對手更好的功能，但我們覺得在功能增強上發起一場戰爭并不明智，也無法捕捉到用戶的心。
為了在一個已經非常成熟和競爭激烈的市場中脫穎而出，我們需要為這個應用定義一個理想的角色，以及它如何滿足目標用戶的需求。這是一個讓我們感到無比興奮的機會，因為我們能創造出更加有意義的東西。
精益用戶體驗設計的合作文化
我們選擇了精益設計 的方法，強調快速線框圖設計，原型設計，用戶的反饋和仿真設計。這創造了早期團隊的高度一致性，引發了大量的思考和創造，讓身處不同組織的伙伴們感到了很強的歸屬感。
通過工作的透明性建立信任
通過分享方法和想法，幫助我們從一開始就建立一個良好的伙伴關系。在項目中我們有充足的機會和舒適的環境來分享想法，建立彼此的信任，這是在初期最為寶貴的價值。
隨時隨地做兩次部署
由于項目交付時間緊迫，我們選擇 Appcelerator Titanium Framework來構建應用程序，這個框架支持代碼重用和跨平臺部署。事后看來，這是一個糟糕的選擇，它嚴重 損害 了用戶體驗。
愉快的開始設計吧
與主要利益相關者溝通幫助我們了解他們的業務挑戰。我們一起確定風險和期望，并構建了應用的共同愿景。接下來，我制作了一個經驗戰略來概述我們每個階段設計應用的方法和方向。
發現階段 - 騎行對你意味著什么？
發現階段，過程短、強度高，允許我們定義項目的里程碑，審視現有的工作，調查競品情況，了解我們的客戶的愿景，并開始研究用戶的需求、行為和痛點。同時我們還開始了技術驗證階段，了解可行性和約束。
我們的研究顯示，用戶對參與騎行的計劃和動機不同，存在著不同的需求。
在確定人物角色類型和結合我們的戰略后，優先考慮重點支持我們早期用戶Michael和Nick。后續的計劃中，將支持Natalie, Carla & Alejandro and Chris。
我們使用人物畫像不斷在項目指導我們的設計決策，優先級和重點。
我們的人物角色假設有五個不同的原型，用來方便進行我們的用戶需求討論。通過仔細分析，我們確定了足夠的行為變量，例如：騎行頻率、技能、信心和動機等，來細分我們的受眾用戶。我們與客戶討論這些設定的人物角色，綜合判斷誰才是我們的早期用戶。
騎行者的想法
嚴格的時間意味著我們需要有效地進行用戶研究和收集反饋。幸運的是，該計劃的普及為我們提供了充足的參與者。我們進行了一系列與利益相關者同事和朋友的訪談；通過Twitter觀察人們在說什么；并利用官方報道從倫敦交通局了解用戶的參與動機。這些不同的渠道有助于迅速了解我們的用戶的需求，并幫助我們了解具體的騎行環境和工作流程。
一見到陽光，我就自己出去兜風了。
虛擬化描述端到端的用戶體驗
我們用體驗地圖技術來將用戶體驗變得可視化，它能體現出用戶端到端的，在各接觸點上的經歷。這使我們能夠找準用戶的痛點，看看我們需要在哪投入更多的精力。這里的關鍵是找準用戶的情緒反應，為客戶設計符合他情感狀態的場景，以滿足客戶的預期。
用單車讓倫敦變得更美好
當我們的競爭對手致力于解決客戶痛點時，我們的愿景是讓用戶更加享受生活的樂趣。我希望我們能真的讓倫敦變得更加美好。
需求階段 - 設計是為了用戶的想法、體驗和感受
我們對用戶體驗的綜合研究就像一個透鏡，不僅僅要考慮產品怎么設計，也要考慮用戶怎么去感受它。我們相信這是一個好的產品和一個偉大產品之間的區別。在早期思考用戶的情感設計，有助于讓客戶和我們體會到美感與體驗的重要性。
用故事來處理體驗設計
首先，我們必須清楚我們產品到底是為誰所設計，如何用產品來解決用戶生活和工作中的問題。我們的設計經驗應該用在用戶的思維和行為上，而不是具體接口、技術和業務目標。
用戶場景需要維持在一個高階的層面上去進行描述，這樣能幫助我們更加順暢的和其他人進行溝通并達成理解上的一致。這些故事逐步形成了一個主干，在功能和情感上不斷進行完善，讓所有參與到產品中的人能夠感同身受。
用心智模型來提取需求
通過我們的研究和頭腦風暴的梳理，人們在騎車之前、中、下班之后做的不同的事情都能讓我快速總結出一系列的任務。我按照用戶行為進行歸類整理，并統一到相同的內容和特性下。這給了我一個方法來了解現有的功能和內容什么會是有用的，什么樣的任務需要額外支持，什么樣的任務意味著創新，什么樣的任務需要被丟棄。
隨后，我將所有的想法整理到一個電子表格，并優先考慮它們對人物角色的需求，技術可行性和商業目標的影響。這個體現到了我們的產品策略，產品路線圖和產品備忘錄中。
此外，我們還需要考慮體驗和品牌的需求
了解應用程序使用的上下文幫助我開發一個清晰的視覺主題以匹配用戶對我們產品的預期。為了確定我們應用程序的個性，我和團隊及客戶制定了一套經驗原則，被用來支撐我們設計決策。清晰的核心價值觀和描述應該秉承用戶和品牌的關鍵屬性，該原則被用來推動產品美感，體驗和整體色調等方向的不斷演進。
制定設計的方向
我們使用從頂至下的方法來定義用戶體驗的整體結構，包括草圖和故事看板。我繪制了大量的UI來表述信息架構，功能、數據元素，和互動行為。從此，我們的愿景開始演變成有形的東西：一種高階的設計語言，交互方式和產品結構。
追蹤與同步
一但用戶確認了我們的內容及功能并排入到生產中，我就要開始編制內容的追蹤和同步機制。我使用 Jesse James Garrett's Visual Vocabulary 來描述應用的架構。 在早期使用統一的系統編碼能夠幫助我們更好的與產品其他團隊進行溝通并達成理解上的一致。
用戶體驗的結構化
在確定了主要的場景后，我們將通過應用中不同角色的探索定義出用戶使用產品的幾個主要途徑。我們為每一個人物角色制作幾個關鍵用戶旅程，這是構思和提煉出內容及功能的最佳途徑。我開始考慮特定的使用環境，幫助我們思考如何在界面中如何設計元素的呈現和排布。
我把想法寫到故事看板上，幫助大家設計和溝通更復雜的交互和流程。它節省了我大量的時間來避免繪制一些邊緣化的情況和原型。
設計階段 - 交互框架
因為在Axure的一些局限性，我決定使用蘋果的Keynote來傳達應用程序的交互和場景轉換。因為其主題提供了所有iOS原生的過渡效果，是一個非常理想的工具。
不幸的是，大部分的交互設計工作并沒真正的被應用到程序中，因為大多數人認為它只是一種美化而被排上較低的優先級。雖然我設計了必要的交互想幫助用戶在場景跳轉時保持導航的上下文，提高用戶感知性，但這些設計只是在可用性測試時重新排布了優先級。想要在第1階段就發布這些已經有點太晚了。
使用Axure RP設計手機原型
Axure是進行原型設計最好的選擇。因為時間緊迫我們選擇開發一個高保真原型，這樣做既有優點又有缺點。
優點是：原型是一個強大的工具，體現了我們的設計過程的透明性，加強了我們與客戶的互動，獲得及時的反饋，并得到客戶和開發伙伴的早期認可。
缺點是：原型是我們交付合作伙伴的最終成果。這意味著任何設計的修改都需要在原型本身中反映出來。幸運的是，Axure可以創建可重復使用的頁面組件。當我們迭代可視化設計時，我可以復用它們，讓設計的變化反映在原型的每個實例中。事后看來，我們應該找到一種更好的方式來傳遞修改，讓原型真的成為原型。
讓重要的事情做起來更迅速
在設計主屏幕時，要讓用戶能夠快速訪問應用程序的主要功能。圖標大小的設計使點擊更容易，圖標順序基于功能的到達率和布局進行設計，并為信息選擇提供不同的展現方式，同時還要考慮必要的擴展性。
讓學習成本最小化
因為用戶的使用場景都發生在運動中，因此可以依靠他們使用谷歌地圖的經驗，并結合現有iOS設計約定來幫助他們學會使用我們的產品。
測試階段 - 這是一個好的設計還是一個垃圾？
我們的應用程序利用情感設計的原則，激發用戶去兜風。針對那些安全性上的擔憂，以及我們目標用戶natalie對新自行車的擔憂，我們會在網頁上放上吸引用戶去騎車兜風的圖片。這樣做是因為我們希望放大積極的方面，并幫助用戶專注于美好的回憶，而不是擔憂。另外，我們會創造一種安全感，讓用戶知道他們在騎行時是安全的。
設計時要體現出自信
界面設計力求自信。它不包含一些不必要的元素。我們選擇了清晰，可讀性更高的字體，選擇具有高對比度的、增加戶外易讀性的色彩。整體設計簡潔，干凈，大間距。我們所有的設計決策，都散發著強烈的設計自信心。
讓用戶參與到測試中
我們與我們的可用性測試合作伙伴Spotless Interactive進行緊密的合作和互動，幫助我們確定任務，建立目標和評估應用程序。
為了確保測試是真實的，我們選擇使用一個真正的應用程環境。然而，這個過程也揭示了應用程序的不穩定性。在各種錯誤和程序崩潰過程中，我們能夠找到布局、搜索以及各種交互設計可能存在的問題。
如何理解自行車和存車處
反饋問題中有一個提到了頂欄中的自行車、存車處與地圖之間的視圖是斷開的。對此，我們當初的理由是：使用標準的iOS標簽欄風格并不能傳達給用戶足夠的認知性、可見性和信息的連接圖，從而使用了頂部分欄的方案。這種分欄控制的平臺模式，更加容易找到想要的信息也更加清晰。
搜索的修復
我們通過觀察用戶的搜索，發現了一個嚴重的問題，于是我們重新制定了剩下任務的優先級來解決這個問題。用戶搜索目的地時，使用地址、郵政編碼、區域、地鐵站和地標時有很大的差別。我們使用的API沒有返回任何有意義的結果，這意味著用戶不能完成他們的搜索。于是我們改變了我們的API，還添加了更多個性化的搜索索引比如：最近和最喜歡的。
同時我們還發現，用戶無法確認他們的搜索是否成功。在服務繁忙時，無法在地圖上看到搜索的結果。這是因為標準地圖行為默認為完全縮小。為了幫助用戶，我們實現了一個隱含的功能，可以設置縮放水平來顯示地圖至少3個結果，并提供足夠的背景空間方便用戶了解結果位置和附近的其他的車輛。
心得 - 我們該如何看待設計？
我不是一個布道者，也不是一個專業的翻譯者，不是為了宣揚敏捷設計方法；也不是為了鼓吹國外工程師如何牛逼；也不是為了教大家如何去做用戶體驗......
通過這篇文章，我們可以清晰的看到作者的設計愿景、原則、思路和實操手法，讓我們能夠感同身受并且還有可能學到一些好用的方法。這個過程本身，就是設計的意義！
設計，是即使站在不同的角度，也能講好你的故事，讓目標受益、讓同伴理解、讓自己進步！
