交互實戰：雲之家 CRM 1.0 項目總結

文章基於雲之家 CRM設計過程，對其交互設計進行了系列的總結，希望對你有所啟發。

關於雲之家 CRM:

雲之家是金蝶孵化出來的類 Slack 產品。說白了就是一款面向 B 端用戶的 IM 軟體，目前市面上的競品有阿里的釘釘、騰訊的企業微信等。這些面向 B 端用戶的 IM 軟體，與面向 C 端用戶的軟體相比，區別就在於，這類產品會集成各種各樣滿足 B 端需求的「小程序」，比如簽到、工作彙報、公司發文等。（據IDC權威數據顯示，雲之家連續兩年蟬聯國內中大型企業，移動辦公平台領先品牌，知名客戶包括萬科、海爾、樂視、華大基因等，企業用戶280萬家，註冊用戶3000萬人。）

而雲之家 CRM 則是雲之家上的一款面向 B 端用戶的 CRM 「小程序」。（小程序是微信起的名字，但云之家把他們稱作輕應用）主要是幫助企業管理銷售員，協助企業全面提升銷售業績。

雲之家 CRM 自 2015 年底快速發展，從原來的一個模塊，發展到了九大模塊。到 2016 年底，基本上覆蓋了客戶關係管理的全流程。而原來的 CRM 首頁已經無法滿足九個模塊的展示，同時原來的首頁的功能體驗也不夠友好。基於此，產品團隊也開始著手考慮優化首頁的設計。隨著業務越來越複雜，各個子模塊頁面越來越冗餘，所以 1.0 的改版，除了需要重新設計首頁之外，還需要對各子模塊的界面進行優化。

2.1 分析需求

首先在建立設計目標前，需要明確用戶的需求，所以在項目初期，用研幫助團隊找出用戶訴求和產品訴求。同時我也在線上採訪調研了十幾名活躍用戶，根據調研結果我們團隊將首頁的目標人群鎖定為三類人：

• 老闆（頂層）
• 銷售總監（中層）
• 銷售員（基層）

這三類人群對首頁的看法都各有不同，根據我們調研的結果窮舉出了多項需求。

接著我們使用 KANO 模型去分析目標用戶和產品決策的需求。我們將實現難度低用戶滿意度提高不明顯的定義為基本型需求。實現難度較高，但能讓用戶覺得特別有用的定義為興奮型需求。而這兩者並不是我們重點關注的核心問題（因為不是產品的差異點所在），但是在我們設計的過程中，依然投入了資源去實現此類需求，因為用戶最基本的需求還是需要滿足的。經整理我們將窮舉出來的需求歸納到 Kano 模型中：

2.2 找到設計目標

最後，我們根據上圖，將需求進行了進一步的精簡提煉，找到了產品的終極目標：使用大數據服務提升銷售效率從而提高企業收入。產品終極目標的存在就在於防止我們的產品在最終呈現上偏離了既定的方向，但是產品目標歸產品目標，而設計目標則不太一樣。設計的本質還是為我們的用戶提供有效的行為解決方案。所以經過對產品終極目標的分析，以及考慮到 CRM 1.0 首頁的定位，我們進一步提取了 CRM 1.0 首頁改版的設計目標：效率與激活。

3.1 首頁設計

3.1.1 明確元素

明確了設計目標后，我開始著手考慮整個首頁的信息架構。但是在建立信息架構前，首先需要明確所需元素。經過討論我們明確了幾個核心功能：

• 新增功能（提高工作效率）
• 應用快速入口
• 激活員工戰鬥力功能
• 業績看板（舊版功能）

3.1.2 在紙上製作原型

確定元素后，我開始著手製作原型，但是我沒有馬上打開 Sketch 或者 Axure ，而是拿起紙和筆，開始製作紙質原型。經過一些嘗試后，我決定將整個首頁的信息架構設定為：

• 新增模塊
• 應用入口模塊
• 子功能模塊

在這個過程中我設計出了多個方案：

3.1.3 製作原型——專於一次設計但不止於一次設計

最後，我挑選出了比較好的兩個方案，並把他們製作成數字版原型：

從上圖可以看到，兩方案的差異點就在「有無快捷新增操作」上。我在後台查看了個模塊的用戶行為數據，發現其實某些新增功能是非常高頻的，所以我提取了一些高頻的操作，將其放到了首頁那裡。但是這個方案的問題就在於，這種新增功能對於銷售員來說的確很方便，但是對於中層人員以及老闆來說就不是很重要了。

因為一般這類人已經不跟單了。於是我就想「有沒有一個不同角色的用戶都共有的高頻需求呢？」，回過頭來看之前整理的思維導圖、 Kano 模型，以及設計目標。發現 to B 應用跟 to C 應用最大的不同就在於，to B 用戶存在階級。特別是業務比較重的場景中，階級之間存在種種矛盾。很難通過單一的設計去滿足多階級的需求。

MVP Testing 驗證了我的思考。製作好了低保真原型后，我拿著這兩個版本去到我們公司的銷售員、銷售總監那裡做了個簡單的 MVP Testing。大家對快捷新增操作的意見的確是很不一樣。銷售員的確認為這樣可以更方便地開展工作，但是也有一部分人覺得不實用，原因就是沒有提供 TA 想要的快捷操作入口。（因為銷售員的工作也是存在分工的，有些銷售員可能就關注線索的挖掘，比如地推人員。對於這類用戶他們的高頻操作就應該為「新增線索」。同時，銷售模式的不同，也會導致高頻操作的不同，如果企業的產品是以投標的形式售賣的話，這種項目型銷售則是以「商機跟進」為主。）而銷售總監則認為快捷入口比較雞肋。

所以基於此，我想到了三種解決方案：

• 按角色推送不同的內容
• 其實不一定要有統一的快捷入口模塊
• 提供自定義快捷入口功能

大家可以看到，其實我是取消了整個快捷入口模塊，原因就是它不靈活，而且通用性並不強，如果需要提高其通用性的話，還要為它提供自定義功能。用戶需要為此，去學習如何設置，同時其它模塊也有設置功能，過多的設置只會讓用戶覺得軟體過分地複雜。同時增加了自定義功能，會延長整個開發周期，就當時的情況來看，留給我們開發的時間並不多。（我認為在平衡設計方案的時候，還需要考慮實現的問題。如果開發周期很長，但是對體驗的邊際提升並不是很大的話，我寧願採取開發資源較少的設計。因為互聯網產品的精髓就是「迭代」，設計也是可以「迭代」的）

明確了整體設計方案后，我開始設計各個子模塊的卡片。在設計的過程中，還考慮了交互框架的搭建，確保產品的可拓展性，降低開發成本，提高輸出效率。所以我製作了統一的卡片交互框架：

根據這個框架我們設計了多個卡片模塊，涉及：

• 激活員工的銷售龍虎榜
• 管理人員期望的數據看板、目標完成度圖表
• 提高用戶效率的快捷操作卡片
• 甚至還有運營活動所需要的廣告卡片

3.2 子模塊重新設計

除了完成首頁的設計以外，還重新設計了原來的各個子模塊界面。原因就是需要將首頁的卡片元素融入各個子模塊中。所以我重新設計了各個子模塊：

依據此框架，我完成了其他模塊的交互設計：

最終，感謝視覺設計師們的付出，將低保真設計方案完善成高保真原型。

總結整個設計過程，其實大家不難看出，我的整個設計流程幾乎按照 Lean UX Cycle 的方式進行：

從需求分析到設計，再到完成設計原型展開原型級的檢驗。檢驗過後，繼續思考並且調整設計，接著再進行檢驗。可能每一個新設計只是在舊設計的基礎上進行了一點點的改進，但不積跬步無以至千里，微小的提升積累得多了，量變形成質變，產品就會慢慢變得越來越好。

不過，回過頭來看這個項目，我認為還有一些不足的地方：

前期設立設計目標的時候，缺少可量化的指標性目標。比如降低用戶投訴率、提高用戶滿意度等。

因為迭代時間短，沒有建立設計目標考核機制。缺少可檢驗量化指標，導致很多檢驗都要靠採訪的形式進行。所以未來可以在應用內增加用戶評分功能，或者凈推薦值調查。

所以總結下來，做好體驗設計，我覺得重要的是做好以下幾點：

• 迭代：好設計是反覆迭代出來的，要多嘗試多檢驗。
• 目標：儘早明確設計目標。而且目標不是拍腦袋空想出來了，而是明確了「為什麼」后推理出來的。
• 量化：要建立可量化的檢驗機制。可能從這個機制那獲取的數據不一定精準，但是數據積累到一定的 量級后，也能反映出很多問題。

雲之家 CRM 1.0 發版后，得到了許多用戶的好評，但這不只是一個人的力量，而是一個團隊的力量，感謝每一位參與的同學。回過頭來看當年，團隊所有人為著 1.0 發版而加班，也是很快樂的~ 大家朝著同一個目標前進，為用戶堅持不懈地打磨優化產品。

作者：王梓銘，雲之家用戶體驗部交互設計師。前產品汪， 還能偷偷擼幾行代碼。時常做夢,想改變世界。懷揣著這個夢想，跌跌撞撞嘗試了各種各樣的東西。錄過視頻，開過 Podcast，玩過博客。 最後發現，其實改變世界並不難。從小事做起，幫助能幫助的人，改變能改變的人就已經足夠了。

本文來源於人人都是產品經理合作媒體@金蝶雲之家體驗中心（微信ID：UXD-Cloudhub），作者@王梓銘

題圖來自PEXELS，基於CC0協議