原文鏈接：Enterprise UX Case Study: Improving Usability Under Tight Deadlines by Jerry Cao Jerry Cao
原文作者：Jerry Cao
基于云的一款項目管理系統(tǒng)，Liquidplanner需要去幫助用戶更快地創(chuàng)建dashboard。
在原先的過程當中，需要去創(chuàng)建dashboard，還有其他所有的小部件，全部都是從頭開始。為了讓dashboard能夠被更多的用戶使用，并提高它們的生命周期，產(chǎn)品團隊著手去創(chuàng)建一個新的dashboard模板功能。
團隊的目標是創(chuàng)建“一鍵解決方案”，用戶可以創(chuàng)建一個有用的dashboard而無需任何配置。
在四個月的時間里，LiquidPlanner塑造了一個新的dashboard模板功能，這讓用戶印象深刻，并且有很高的使用率和很好的商業(yè)效益。
接下來，你會看到他們是如何做到的。
設置情景
在進入實際的過程之前，我們需要先確立用戶人群和項目目標。
1、主要用戶
LiquidPlanner有三個主要的用戶的人群：
產(chǎn)品經(jīng)理－這些人是產(chǎn)品的重度用戶，他們幾乎黏在LiquidPlanner上。這些決策者確保團隊使用產(chǎn)品來跟進時間，合作，使用功能來幫助他們做的更好。
職能經(jīng)理－像是以下其他的決策者，如UX經(jīng)理，或其他主導團隊的人，確保自己對產(chǎn)品負責。
前線貢獻者－大多數(shù)使用產(chǎn)品的人。這些在前線使用產(chǎn)品的人，可能并不是他們選擇了LiquidPlanner，但是他們每天都因為項目使用它。
2、產(chǎn)品目標
下面這些定量和定性的目標會確定dashboard模板功能的成功：
在30天內(nèi)開放增加dashboard的使用率，使用Heap去跟蹤應用內(nèi)事件，他們發(fā)現(xiàn)在整個項目中，創(chuàng)建dashboard有許多的磕磕碰碰。
Grant立即獲得了項目的關鍵信息，它不僅與質量有關，而且與速度有關。LiquidPlanner需要去簡化訪問數(shù)據(jù)的流程。
在三個月的時間內(nèi)完成這個項目，從2016年的1月開始，預期4月初上線，留給了團隊一個緊張的時間來給出正確的解決方案。
階段一：發(fā)現(xiàn)&概念
（2016年一月上旬）
在實際執(zhí)行之前，我們團隊進行了頭腦風暴和草圖會話。項目經(jīng)理，UX經(jīng)理，和UX設計師Edward Nguyen也都出席了。
檢查Heap的應用內(nèi)模式，團隊將最常見的dashboard進行了分類：
項目Dashboards
團隊Dashboards
文件Dashboards
他們在白板上概述了自己的想法。這里主要涉及到用戶流程圖，畫出屏幕上的體驗。從用戶流形成的基礎上，最終演變成dashboard的完美解決方案。
第二階段：創(chuàng)建和測試低保證流程
（2016年一月上旬）
在緊跟白板會話之后，Edward使用AI繪制了低保證版本的白板草圖，這些低保證的流程，在用戶進行高保真原型和測試之前，成為了關鍵的中間階段的內(nèi)部測試。
首先，早期的反饋收集，Edward展示了低保真用戶流程給5～10個產(chǎn)品團隊以外的同事，他管理這些單獨測試，解釋相應的問題，收集反饋，并用來指導dashboard的迭代設計過程。
這次非正式的測試也給了他一個機會來回答一些個人關系的問題。最終測試證明是成功的，沒有負面反饋就是一個好的反饋。
階段三：高保真原型
（2016年一月中旬－二月）
建立一個中保真的用戶流程和內(nèi)部反饋，團隊準備創(chuàng)建第一個版本的功能設計。
1.創(chuàng)建
線框圖和中保真的用戶流程展示了產(chǎn)品可能是如何工作的，那么一個原型將是展示產(chǎn)品是如何工作的。
因為創(chuàng)建一個原型的目標是測試你的設計決策，第一步就是在可用性測試計劃列出所需要的見解。文檔優(yōu)先測試最重要的目標用戶的操作：
驗證用戶是否知道如何創(chuàng)建一個新的dashboard。
驗證三個默認的測試模版是否有用（項目，文件，團隊）
驗證創(chuàng)建儀表盤的功能是否能在項目中被發(fā)現(xiàn)。
確認默認的組件在dashboard中是有用的。
可用性測試計劃還包括部分如測試腳本以及撰寫用戶任務（即：你能為項目A創(chuàng)建一個模板dashboard嗎？）
在這個階段，團隊做了一些數(shù)據(jù)挖掘庫存和統(tǒng)計模板部件。這讓第一個原型更接近最終產(chǎn)品。
新的設計需要足夠直觀，讓面對的用戶沒有困惑，愛德華選擇了一個笨拙的左側標簽格式，來與團隊最初畫的多步驟過程做比較。最后他意識到他的選擇比團隊的更加易于實現(xiàn)，并且用戶也能受益。
設計師不需要去創(chuàng)建有趣的圖標，開發(fā)人員不需要構建一個多步驟向導，用戶可以通過更少的步驟選擇他們的dashboard。
Edward解釋道，設計師不需要知道如何寫代碼，但是他們應該了解設計會涉及的技術。
2.可用性測試和迭代
團隊進行遠程會議，通過Join.me有14人參與了測試。
Edward主持了測試環(huán)節(jié)，另外一個團隊成員觀察并做著筆記。他們測試了兩個主要場景：創(chuàng)建dashboard，在現(xiàn)有的項目中發(fā)現(xiàn)dashboard。
測試結果是快速的迭代到了下一個版本，然后進行同樣的測試和結果反饋，直到團隊想出了一個被證明是理想的設計。
“用戶甚至誤以為我的高保真原型就是真實的產(chǎn)品，告訴我感謝我們的開發(fā)團隊。”Edward說。
可用性測試解釋了設計是一項系統(tǒng)性的工作：
用戶發(fā)現(xiàn)從標簽布局創(chuàng)建dashboard模板，更易于使用和理解。
用戶提及了默認的測試模板是有用的，并且符合他們的要求。
雖然大多數(shù)用戶發(fā)現(xiàn)默認的小組件有用，但是有一部分用戶說他們會按個人喜好選擇小部件。例如，一部分用戶沒有找到“剩余工作”的linechart部件。另外一部份人則表示自己完全沒有自制模板的能力。
用戶一旦創(chuàng)建了dashboard，體驗就會變得稍微困難了一些。
Edward花費了相當多的精力和時間去與項目經(jīng)理討論映射模式來增進理解。異常的評論適用于一些可操作的反饋。
為了讓新建dashboard更容易被發(fā)現(xiàn)，Edward決定增加負空間，在“視圖項目Dashboard”下標簽出詳細的視圖。
進一步的改進，例如保存部件編輯的功能，在后來被用在測試，因為它們不屬于MVP的范圍內(nèi)。
階段四：研發(fā)并且上線
（2016年二月－四月）
在敏捷開發(fā)之后，研發(fā)沖刺緊跟著設計沖刺。
盡管Edward的團隊仍在測試原型，研發(fā)人員已經(jīng)構建了驗證迭代。“協(xié)作高保真原型和測試的見解給我們的研發(fā)人員足夠的信息，在代碼中實現(xiàn)我們的設計決策。”Edward說。
團隊中的有效溝通提高了每日站會的效率，Edward會公布任何新的研發(fā)人員對可用性測試的見解。
因為新功能測試效果很好，LiquidPlanner發(fā)布了新的dashboard模板功能，而沒有發(fā)布beta測試。盡管團隊可以測試大量的性能，他們?nèi)孕枰尮δ茏叱龇块T，因為現(xiàn)在的dashboard很不一樣。
感謝高效的高保真原型和無間的合作，團隊在2016年的四月九日推送了新的功能，在計劃的時間范圍之內(nèi)，最終的結果是：
已經(jīng)有超過17000的dashboard在LiquidPlanner中被創(chuàng)建，其中1700（10%）是在發(fā)布后的兩周內(nèi)創(chuàng)建的。
模板功能被75%的新dashboard使用了。
絕大多數(shù)的大型企業(yè)客戶已經(jīng)在使用并享受這個新的功能，因為它可以推動他們大型，復雜的項目。
“我要被這個數(shù)字給吹走了。”Edward說，“很高興我的工作能夠受到用戶的歡迎。”
其它
基于LiquidPlanner的成功，我們可以將這些知識應用到我們的產(chǎn)品設計過程中去：
不要過于雄心勃勃地重新設計項目。新的設計需要對老用戶足夠的尊重，保持一致性，并同時還要能夠吸引新用戶。為了實現(xiàn)這一微妙的平衡，請保持一切盡可能的簡單。
為了效率，當然可以直接從草圖到用戶流程再到高保真原型，只要你能夠讓測試跟上腳步。因為現(xiàn)有的視覺設計標準已經(jīng)驗證，所以高保真原型的風險較低。
壓縮時間，確保設計人員能夠領先研發(fā)人員一個sprint。
像Edward那種拯救“小部件編輯”的功能，不要害怕在上線之后測試過程中發(fā)現(xiàn)了新的想法。
與詳細的高保真原型密切合作，研發(fā)人員可以實現(xiàn)代碼的轉化，并且會較容易的理解。
