數據與理論結合,讓交互設計更專業

0 評論 4371 瀏覽 0 收藏 16 分鐘

Part of TaobaoUED 碳酸飲料會講稿 By 用戶體驗分析師:曉荷 |? 交互設計師:老三[2010/7/21]

Pay.taobao.com是淘寶賣家訂購增值服務的平臺,但該平臺的可用性和操作體驗欠佳,導致客服部門收到非常多來自賣家的訂購服務咨詢,壓力很大,需要在系統層面解決此問題。因此發起了訂購流程體驗優化項目,對pay.taobao.com進行前后臺改版。

圖1:優化前的軟件服務訂購頁面

圖2:優化后的軟件訂購中心首頁(原來無首頁)

圖2:優化后的軟件訂購中心首頁(原來無首頁)

圖3:優化后產品列表頁

圖3:優化后產品列表頁

優化之后,客服部門反饋數據顯示,賣家咨詢量由40%下降到7%。為此,與大家分享項目的兩點經驗:

1. 如何利用數據指導交互設計

  • 前期數據采集
  • 上線后數據分析
  • 用戶反饋數據分析

2.良好的團隊協作,提升UED話語權

  • 與非UED同事協作
  • 與UED同事協作

1.如何利用數據指導交互設計

1.1前期數據

知己知彼,百戰不殆。常說為中間用戶設計,只有熟悉數據,了解數據,才知道誰是我們設計的中間用戶。通常,公司內部都會有數據部門,也會有后臺系統。作為交互設計師,你應該有不少于業務線產品經理(PD)的內部權限,這樣才能為設計和決策提供各種數據作為支持。

在制作軟件服務訂購中心時,我采集了以下幾種數據

  • 基礎數據
    包括原軟件服務訂購頁面的PV、UV,訂購的交易轉換率,訂購的成功率、失敗率等數據。
  • 業務數據
    項目在規劃好時,PD會事先知會交互設計師。然后PD會寫PRD(需求文檔),交互設計師在此時應開始準備調取部分相關數據,在本例中,調取數據如圖4所示。此份定量數據非常重要,對于后期用研的介入、設計的參考都起了很大的作用。

圖4 軟件服務訂購用戶數據

圖4 軟件服務訂購用戶數據

服務訂購量的人群分布

服務訂購量的人群分布

不難看出

  • 軟件服務訂購主要由擁有X個(由于保密性,該數據不能透露)服務的會員所購買,核心消費人群為擁有X個服務的會員。
  • 大多數會員擁有的軟件服務數為X。

以上數據為前期設計提供了可靠的依據。訪問量的多少、用戶使用此頁面的目標決定了頁面的最后設計結果,以及設計該頁面時投入的成本。同時,這些數據對于可用性測試的目標用戶篩選,提供了明確的指導。

1.2上線后數據

“任務可被完成? 任務在無外界影響下可以被完成?!?/em>

《交互設計食用指南》使用指南總則? by 青云

要知道我們的用戶任務是否可完成,就得監控關鍵頁面:訂購成功與訂購失敗頁面。軟件服務訂購中心的一個重要指標是充值的成功率和失敗率。

http://pay.taobao.com/account/payError.htm

充值失敗頁面

我們來看一下上線初始的1個多月來,出錯頁面的訪問量:

上線初始出錯頁面訪問量

上線初始出錯頁面訪問量

可以看到,在上線初期,用戶支付的失敗率非常高,我們來分析一下當時的頁面流程。

第一步:輸入金額,彈出浮出層

第一步:輸入金額,彈出浮出層

第二步:點擊去支付寶付款

第二步:點擊去支付寶付款

第三步:彈出支付寶頁面,付款完成后在舊有頁面點擊任意按鈕,判斷支付狀態。

第三步:彈出支付寶頁面,付款完成后在舊有頁面點擊任意按鈕,判斷支付狀態。

看過此流程,大家不難發現,第二步有點多余,為什么不直接進入第三步呢?其實第二步的增加是為了解決支付失敗率高。直覺反應應該是彈出層的問題,經過分析,一些瀏覽器會阻擋非用戶主動激發的彈出頁面,故用戶點擊充值后并未彈出支付寶頁面,用戶就疑惑了,并隨意點擊一個按鈕,從而導致出錯頁面訪問量高。

此處優化以后,錯誤頁面的訪問量有非常明顯的下降。

優化后訪問數據

1.3用戶反饋數據

與用戶對話,了解你的用戶是咋想的,并逐漸的改進產品。與開發、PD、PM共同協商問卷想采集的數據后,再與用研同學合作,他們會整理出合適的題目。特別是一些設計中擔心的小點,如頁面載入速度、CDN速度等、信息架構等。這份在線問卷的入口放置在訂購中心首頁左側。

問卷訪問入口

打開后,是一份半開放、半封閉式的問卷。

問卷詳情

用研同學會將這些數據整理好,并出具報告。內容包括定量與定性統計兩部分。來自用戶的一手反饋能證明團隊的工作,還能為后續優化指明方向。

用研報告

用戶反饋文字很小

用戶反饋文字很小

收到用戶反饋字體很小。查看頁面數據,發現軟件訂購中心的訪問者中,大分辨率的用戶是1024X768用戶的2倍以上!于是他們做了專門的界面優化。

訪問者顯示器分辨率分布圖

2.良好的團隊協作,提升UED話語權

2.1從非UED的角度去分析問題(與非UED同事協作)

記得一位朋友講過,要是兩情侶吵架,鬧得不可開交那種。你重復她的話,她來重復你的話,兩人會覺得很搞笑,自然矛盾也就和解了。

生活如是,工作上也如是。運營、PD、前端、測試、開發要求的東西,你換位思考一下,也自然理解為什么了,也不會去瞎鬧騰了。如果你沒有這些職位的經驗,多和PD、運營交流,類似行業的變身還是很容易。

掌握與PD\PM\開發測試人員溝通的語言

為了與PD、PM、開發、架構師更好地溝通需求,筆者在完成交互設計任務之外,還專門去了解了后臺復雜的計費模型、產品定義模型,這樣才能更好地了解什么功能能做到,什么功能不能做到,時,其他項目組成員才不會認為你是一個啥都不知道、只會空談體驗的。

這些底層知識,在原型設計時發揮了相當大的作用。

例如,通過了解預付費模型、后付費模型。在設計計費詳單、續費詳單時會更加清晰,能更清楚的向用戶展現整個收費過程。

站在架構師的角度討論體驗

舊版的訂購列表頁面將所有服務羅列出來,操作中的訂購按鈕無論訂購與否、一直有效。用戶點擊訂購按鈕后,根據用戶權限判斷進入訂購頁面或者錯誤頁面。用戶可能多次點擊均返回錯誤頁面,體驗十分糟糕。

舊版訂購體驗

為了減少用戶的不必要操作,在新版的訂購中心,用戶在瀏覽增值產品列表頁時,訂購與否的邏輯判斷移動到該頁面(進入產品詳情頁前),如果你沒有購買權限,會在最開始就提示不能購買原因。同時,根據是否可續費顯示續費按鈕狀態;根據是否可升級顯示升級狀態,并提示用戶原因。

新版訂購列表操作欄

正是這樣,提高了訂購流程了滿意度。減少訂購中的咨詢而增加了訂購前的咨詢。但頁面需要根據每個用戶的訂購情況來分析應該顯示的效果,架構師提出頁面展現性能的擔憂。該擔憂是必要的。與前端交流后提出以下方案,并結合線上數據做分析:

方案1:頁面通過后臺計算好之后再返回。前端工程師無需任何工作,缺點是用戶看到的頁面時間會增加。列表頁面是否針對每個用戶做出獨立計算,將其所有的服務狀態讀取出來。我們可以參考之前采集的頁面PV數據得到以下分析:

請求量:?,000,000*1*40 = ?,000,000;不考慮網速的情況下,頁面響應相比另一種方案增加200+ms。另外根據頁面PV、UV數據,服務器完全可承受該壓力。

方案2:頁面渲染與服務訂購狀態異步渲染。即用戶會首先看到整體界面,個性化軟件服務狀態在1S以內會根據用戶具體情況調整。異步獲取數據在淘寶的商品詳情頁面有使用,適用于頁面量大,用戶逐步接受數據頁面。缺點是前端工程師需要增加額外工作。再者,如根據是否綁定手機來判斷是否開放短信訂購入口這些情況,計費系統本身無法判斷,需要調取外部接口,開發成本異常高。故決定只枚舉計費系統情況,覆蓋了80%以上的權限情況。

綜合考慮前端、開發成本,由當前頁面PV等情況,最終選擇了方案1。通過后續用戶反饋入口收集到的數據:只有少量用戶反饋訪問速度慢。這次改進是有效的。

與運營合作

設計界面時,就想到營銷手段。做產品列表頁面時,想想運營的同事如何在這個列表上完成他們的營銷目標?其實很簡單,是大家也都能想到的,在超市里面看到特別需要促銷的商品會貼上折扣的信息,于是利用UED的技能,為運營提供一些促銷技巧。這不是特牛的事,但表達了UED的態度。大家合作也就非常愉快!

促銷圖標

促銷圖標線上效果

2.2與UED同事協作

作為一個平臺,當其他服務接入時,我們通常希望其他交互設計師、視覺設計師能做出符合要求的圖標。當該產品轉交到其他人手里時,讓他們理解你的思想,就CODING時候的注釋一樣,寫在里面。方便他人,尊重他人,是為了自己得到尊重。因此,在我的原型里,除了頁面,還加入了大量的注釋。

AXURE目錄樹

文案說明,統一平臺的介紹語言。

文案說明,統一平臺的介紹語言。

圖標接入說明,為接入其他軟件服務時視覺統一做準備。

圖標接入說明,為接入其他軟件服務時視覺統一做準備。

模塊規范,前端有了這個,思考全局組件時更輕松。

模塊規范,前端有了這個,思考全局組件時更輕松。

3.總結……

通過前期數據采集、上線后數據分析、用戶反饋數據分析等方法指導交互設計,在與UED、非UED同事的良好的團隊協作,最終提升了UED話語權。讓交互設計師走向專業、品質、協同!

來源:http://ued.taobao.com/blog/2010/07/26/data-for-interaction-design/

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!