原文鏈接：User-centered design in the enterprise: A case study of Jive Circle

作者參與設計了自家公司產品Jive Circle后，總結出以用戶為中心的設計步驟，配以實際案例，能讓讀者深刻體會到如何從需求分析開始，快速將一款產品到推向市場。很值得參考和學習。

我們剛發布了Jive Circle，一款全新的企業通訊錄app，自年初開始，我們一直為它奮戰著。對于這款app，我感到非常興奮，因為我們能采用“以用戶為中心”的思路來設計它，從而確保我們開發出既有用又可用的產品。在這篇文章中，我很樂意分享一些我們的設計流程，以及作為一個團隊我們所學到的經驗教訓。

所以，讓我們從每個產品都會經歷的地方開始——用戶需求。

從頭說起：用戶需求

Jive Circle是我們為企業辦公app貢獻的第3款產品。第一個（Jive Daily）和第二個（Jive Chime）在今年早些時候已發布。通過對這些app做的市場調研，調查小組發現了一個亟待解決的新痛點：企業通訊錄。

人們一般會在一天中多次訪問企業通訊錄，而這一過程會帶來很糟糕的體驗。通常人力資源系統或內網系統能滿足需求，但調研顯示，人們很少會用這些系統（原因很多，既可能是因為難用，也可能是因為忘記密碼又懶的找回）。相對的，他們會采用從“Microsoft Outlook”中尋找通訊錄這種體驗極差的方式來滿足需求。

企業通訊錄中，最常用的找人方法有以下幾步：

1、在Outlook中撰寫一封新郵件

2、敲出對方的郵件地址

3、右鍵點擊他們的名字

4、去他們的個人信息頁

5、復制想要的信息

6、關閉未送出的郵件

這完全不是一種理想的方法。于是我們看到了機會，用Jive Circle來解決這個問題。

行勝于言：原型解決方案

最開始，我們就想要一個正確的設計流程。我們團隊內部達成一致，希望在早期就隨時能收到用戶反饋，此外，我們會盡可能快地產出一個可用原型，并從此啟動迭代。

在開始進行任何設計工作前，首先我想要團隊清楚基本的用戶使用流程和信息架構。我們花費了幾個星期梳理正確流程，但在v5.1版本才敲定了最終方案（很抱歉下圖中我模糊了一部分模塊，這些是我們即將推出的新功能，還不能告訴你們哦~）

該版本后，此流程幾乎從未變過。相比那些僅做了視覺稿，然后自求多福的方法，從梳理用戶流程開始，對產品設計而言極其有幫助。在做信息架構時我們遇到了很多問題和爭議，而在這一階段就解決掉它們，比起開始做設計后再解決，要更有效地多。

確定好基本流程，就可以開始進行（原型）設計了。我選擇Proto.io來做初始原型。當然，也有很多其他選擇，但Proto.io是最能滿足我需求的工具（包括提供“長按”手勢操作，這是其他工具那時還沒有的功能）。

現在再回顧那時的原型，我很吃驚地看到從第一版原型到我們第一個的Alpha測試版本的進化。一些元素改變很大，另一些則保持大部分不變。這里有個例子，首版原型Home頁面，和今天Beta版本的頁面對比：

更突出的搜索框，更專業的“team”模塊，以及底部基于卡片化的信息呈現，所以的改變都直接基于可用性測試——但更多的改變是在那之后。

每隔幾天，我都會基于團隊反饋發布一個新版原型，上面列出所有改動點：

就像你在上圖中看到的，此時我們發布了v3.1版本，我們意識到在進行下一步之前，是時候該將它推到用戶面前了。

節省時間和計劃：可用性測試

對這款產品，我們非常有必要做至少2輪可用性測試：一輪針對原型，另一輪針對首個alpha測試版本。所以利用v3.1版本原型，我通過可用性測試更好地了解到人們當時是如何使用他們的企業通訊錄的，以及我們推出的方案做的如何。

像往常一樣，這個做法效果很好，那場早期反饋做出的改變，對軟件的功能和可用性產生了很大影響。如果我們等app推向市場再去發現問題……那時，我們將會付出嚴重代價。

我們從中收獲的2個最大發現：

• 獲取用戶位置、時區和當前狀態十分重要，此外，還需要提供找到該用戶所需的所有聯系方式。所以這些已經成為這款app的核心功能。

• 我們很吃驚地發現人們經常想在組織結構圖中查找用戶——尤其是在大型公司。這意味著我們要把它設計成一個核心模塊，而不只是為通訊錄子菜單提供一張組織結構圖。

利用手上所有的測試結論，我們持續在對原型進行優化，直到v5.1。此時就該開始視覺設計和開發了……

實現它：從原型到視覺設計和開發

早在開發進行前，我們就做了一些我認為很重要的事情。我們打算采用“垂直”而非“水平”的方式開發第一版app。解釋下，“水平”方式指你在第一版app中就加上所有功能，然后再改進它們。這樣做的問題在于你會開發出一堆半成品功能，如果你在發布日期前用完了時間，你就完蛋了。

如果你采用“垂直”方式開發，就要挑出最優先想要的功能，從頭到尾完成它，并確保功能運行完好。第一版可能只有少量功能，但這些功能都是精心打造的，因此你會收獲一款有用的app。然后你就可以在后續版本中添加更多功能，這有時被稱為產品開發的蛋糕理論。對于我們，這意味著專注于某個全團隊認可的，非常具體的功能集：

這個時候，我們的視覺設計師開始為Alpha版本設計主視覺稿和動畫，而開發團隊開始搭建后臺。我們采用高度協作的方式進行開發。那個時候真是種挑戰，因為開發團隊在特拉維夫，而產品和設計團隊都在美國西海岸。但得益于我們的內部協作軟件、大量的視頻通話，以及幾個星期的面對面交流，我們做到了。

那個時候團隊發布了Alpha版本，我們都非常興奮。Alpha版本也是一款讓人吃驚的產品，我們迫不及待地想將它交到用戶手上。所以我們進入了下一階段……

拋光鉆石的粗糙：更多的可用性測試

我們對Alpha版本做了2件事：

• 發布了內部Alpha版本，并交給自家公司的一組用戶使用，以便于他們能嘗試打破它，幫助我們修正錯誤。

• 做了另一輪可用性測試，如果有必要，還會進行一些最后的流程修正（當然，我們確實有必要）

此外，我們也開始把app做的更好玩——那些額外的標題動畫和交互會讓app顯得更特別。我們的視覺設計師和開發工程師出色地實現了動畫的細節部分。下面就是app中我最喜歡的動畫效果：

長按頭像：

組織結構圖動畫：

這些動畫效果很精妙，并不會喧賓奪主，但真的能讓app變得更有個性。

發布上線：知道什么時候你該行動了

我們可能會一直持續下去，但市場不等人，所以是時候準備面對發布上線日了。

時間用盡時，我們只完成了所有功能的一半。如果采用“水平”方式，現在就是個杯具。但因為我們會在進行下一步前完成每個功能點，那種情況就不是什么問題。這就是我們采用“垂直”方式進行開發后的回報。我們只需把那些未完成的功能從初始發布版本中去掉，而在接下來幾個月的更新版本中再加上就好了。

所以現在我們就等著8月31號——我們官方的發布日期！今天提交了app store，所以接下來會跟進上線進展。總的來說這是我經歷過的最喜歡的項目。團隊很靠譜，過程很高效，我已經迫不及待地把它拿出來，并開始添加更多有用的功能。

最重要的是，我很興奮我們能夠在設計過程中進行原型設計，可用性測試和快速迭代。它幫助我們專注于以用戶為中心，我相信這節省了我們幾個月的開發時間。

經驗總結

從項目中我總結了幾條很重要的經驗。

• 異地團隊（合作）很難。我們都知道這一點，但有時我們會低估它的難度。我只發現了2條能夠方便遠程團隊合作的經驗：（1）強化溝通（2）盡可能坐到一起。

• 原型真的是最好用的方法。我并不是說線框圖已死——實際上，我想說的恰恰相反。但如果時間和預算允許，一個可交互原型對團隊溝通和用戶反饋而言是不二之選。

• 企業軟件能以現代化方法設計和開發。整個團隊都采用用戶為中心的設計流程，而這么做讓一切都變得不一樣了。不要認為因為你在一家大公司工作，就必須一直用BDUF（Big Design Up Front，設計先行的軟件開發流程）、緩慢的、瀑布流的方式工作。

由于所有的功能都和設計相關，這款app還差的很遠。但我對我們的流程有充足自信，對這一流程的效果也很有自信。我知道當收到用戶反饋后，我們會持續改進，因為從最開始這就成為了項目的基石。那么，對產品設計師而言，還能要求更多什么呢？

譯后感想

自上一篇譯文以來，時隔已久，皆因空閑時間有限，無暇顧及其他。但此篇文章結構清晰、行文流暢，所述內容對移動產品設計開發團隊參考意義很大，特花費4個多小時，撰寫3000多字完成此文，尤其希望小而美的團隊試下文章提到的敏捷流程，應該能對產品開發迭代有很大幫助。感謝閱讀~致禮！

本文轉載自