天天看點

論使用者體驗測試:牛逼的功能千篇一律,好的使用者體驗萬裡挑一

此文已由作者吳豔秋授權網易雲社群釋出。

歡迎通路網易雲社群,了解更多網易技術産品營運經驗。

一、什麼是使用者體驗

使用者體驗,英文叫做user experience。一個較常見的定義是“指使用者通路一個網站或者使用一個産品時的全部體驗。他們的印象和感覺,是否成功,是否享受,是否還想再來使用。他們能夠忍受的問題,疑惑和BUG的程度。”

而在我看來,使用者體驗就是一種使用者在使用産品時所建立起來的心理感受。心理感受是純主觀性的,也就帶有一定的不确定因素,不過,在界定使用者基本确定的情況下,其使用者體驗的共性是能夠通過良好的設計來實作的。 如今軟體行業發展甚為迅速,各種軟體産品更是形形色色,使用者成了強勢的群體,他們不再滿足于使用的軟體能實作其需要的功能,更追求一種使用過程中的良好的心理感受,用一種形象的說法就是使用者是用他的腳來為軟體投票的,非常簡單的道理,你的産品不好,你的使用者就會抛棄你的産品,走掉了。總結一點還是那句話:牛逼的功能千篇一律, 好的使用者體驗萬裡挑一。

二、什麼是使用者體驗測試

使用者體驗測試顧名思義就是測試人員在将産品傳遞客戶之前處于使用者角度進行的一系列體驗使用,如:界面是否友好(吸引使用者眼球,給其眼前一亮驚為天人的體驗,用了還想再用)、操作是否流暢、功能是否達到使用者使用要求等。從測試人員于使用者角度進行體驗使用,最終目的就是驗證我們的産品是否符合使用者習慣。

使用者體驗測試已作為各個企業所關注的流程,不過對于國内部分公司對測試生命周期的濫用和不完善了解導緻整個測試過程都還在不斷的改善、發展的路程,此時“使用者體驗測試”也随之顯得更為不受重視。衆所周知,測試過程會花費部分成本,比如産品的需求變更,開發的bug修複,使用者體驗測試也不例外(使用者體驗環境從時間耗時和資源上都能展現)。考慮實際收益,使用者體驗測試的設計需要慎之又慎,他需要對測試的目的、介入時間、測試的周期、場景、人員的選型都要做出深入的分析和界定。

目前我們選擇進行使用者體驗測試的一個非常重要目的是為了判定我們的産品是否能讓使用者快速的接受和使用,或更直接的說法是驗證我們的産品是否會不符合使用者的習慣,甚至讓使用者對産品産生抗拒。顯然針對這一目的進行的使用者體驗測試介入時間一定要盡可能的早,試想如果在系統快要釋出前才進行該項測試,非常可能因為在使用者體驗測試時發現頁面結構不合使用者操作習慣,或有些功能對于使用者而言需要強化,或操作步驟過繁,在不推遲釋出時間的情況下,此時對代碼進行修改和優化,誰都知道這樣的行為無疑是危險的。是以,較為合理的做法是當頁面的demo定稿時我們就需進行使用者體驗測試,不過由于此時的測試是靜态的,是以還不足以確定使用者實際的操作感受,我們還需要在系統送出功能測試後,當功能測試人員驗證主流程已能正常流轉,使用者體驗測試就能再次介入進來,此時的使用者體驗測試不必像功能測試那樣關注細節的實作,更重要的是收集使用者的操作習慣和使用感受。假使我們不必說明使用方法使用者就能流暢的進行操作并且在操作過程中不會對操作習慣進行過多的抱怨,那麼我們能認為系統的互動、設計是合理的,反之,我們就需要考慮作出相應的修改和調整。

三、使用者體驗的本質及執行個體

使用者體驗的核心和本質:滿足使用者需求,超出使用者期望。

有人将使用者體驗與軟體的運作效率混為一談,認為使用者體驗就指響應時間、可靠性、穩定性這三方面。其實這隻是使用者體驗的一部分。我認為使用者體驗度可用幾個簡單的詞來概括:

論使用者體驗測試:牛逼的功能千篇一律,好的使用者體驗萬裡挑一
我們需要記住一點:我們要做的是去适應使用者,而不是改變使用者。
論使用者體驗測試:牛逼的功能千篇一律,好的使用者體驗萬裡挑一

四、bug和使用者體驗差的差別

現在産品的通病就是隻求“孩子”産品四肢健全,不在乎它們是否長相平庸難以相處,隻要邏輯沒有漏洞,功能上沒有bug,産品即可釋出上線。這個觀點我不敢苟同,在不花費較少的實作成本的情況下,我們應該抱着高要求去對待産品的功能測試及使用者體驗測試。讓使用者鄙夷的使用者體驗和有線上bug一樣讓都是唾棄。IT從業人員認為,使用者體驗差不屬于bug,它屬于優化任務,優化任務廣義上都是使用者所發現提出的軟體可改進的細節、或與需求文檔存在差異。本質上使用者體驗差和缺陷等級較低的bug沒有什麼差別。

舉一個例子:APP登入頁面文案為“登陸”,那麼問題來了,這個問題屬于優化任務還是bug。實際上中國語言博大精深,其實用“登陸”是可行的,但是目前的大資料分析結果得出,産品文案均是登入,我們應該服從于大衆。從使用者的角度去考慮,他們可能在人海茫茫的網際網路産品中一眼就記住你,原因不是你的産品功能是如何的牛逼,而是他們認為網頁存在錯别字的産品不多了,而我們的産品做到了。在開發和QA的日常工作中也經常出現,二者為是bug還是優化争的你死我活。在開發的眼裡隻要功能可用就沒毛病,QA從測試的角度會考慮過多細節。bug和使用者體驗差導緻的優化任務其實是沒有本質的差別,因為他們都能給使用者的體驗帶來不快。這些問題最終都是殊途同歸。使用者體驗差等于對待缺陷等級較低的bug,這是毋庸置疑的,衡量的标準其實取決于使用者,他們的主觀意識認定是bug那麼就是bug,這就是萬能定理:使用者就是上帝。

五、作為測試工程師如何提高自己的使用者體驗測試經驗?

1、體驗更多的産品,網站或者APP。不隻是國内的産品,國外的産品也要多體驗,從産品的設計和功能的布局上為什麼别人要這麼做?多思考總結。

2、使用者回報。多看使用者多我們産品的體驗回報、建議等,多去AppStore及其他安卓市場看産品的評論,從評論中也能get到一些關鍵資訊。

資料統計。資料統計從幾個方面去看:

3、比如使用百度統計分析APP安裝情況,活躍情況,都使用了哪些手機型号,手機型号的使用排名,對測試工程師來說,可以在節約成本的情況下購買使用者分布多的機型。另外,通過百度統計測試人員可以再重點關注下crash情況,把crash日志抓取下來找研發一起分析。提高APP的穩定性,進而提高使用者體驗。

b、百度統計跟蹤頁面的通路,按鈕的點選情況,進而分析資料,優化頁面。

c、通過強大的資料中心部門,進行資料的挖掘和分析,做出更多優化。

六、體驗過最坑的使用者體驗是怎樣的?

1.超長的頁面下載下傳時間

加載速度超過30秒已上

基本上使用者已經把你甩到千裡之外

2.無限制的使用flash及圖檔

無限制的使用flash及圖檔.會造成頁面檔案超大,占用浏覽者的cpu資源

并且不利于頁面更新及搜尋引擎對網站的抓取

3.網站頁面過長

過長的網站很容易引起浏覽者的視覺疲勞

網頁和身材一樣,都有自己的黃金比例

4.不友好的導航.

不友好的導航是最影響使用者操作的, 不能讓用記很友善的找到自己想到的内容

使用者來到一個頁面不知如何傳回上一頁,不知道目前頁面是在哪個欄目下的

這樣的網站很可能使用者也會和揮手和你說再見

5.過期的資訊

很久不更新的資訊,很容易讓浏覽者感到反感,

而且在心中也會對你這個網站的品牌形象大打折扣.

執行個體:19樓租房

過期的租房資訊簡直是使用者的苦海

6.死連結或連結錯誤

最基本的錯誤,但是好些還有這樣的錯誤

包括移動、新浪這種使用者量很高的平台

7.頁面安全性

很多頁面會把使用者資訊暴露在頁面上,一覽無餘

使用者安全資訊岌岌可危

執行個體:阿裡巴巴的杭州智慧住房租賃平台

暴露個人資訊,導緻我的電話被中介打爆了,我很想拔刀攻擊敵方的産品

8.惡意插件,惡意彈出視窗

惡意彈出視窗及品牌的公告簡直是謀殺使用者

執行個體:百度帖吧

經常性跳出一些不可描述的視窗

9.頁面中不要過多的用新視窗

過多的彈出新視窗,會大量占用計算機的資源

影響浏覽者的浏覽速度,使用者的cpu和處理岌岌可危

10.鍊連沒有标準的表現形式

網站要有統一标準的連結表現形式,并且要和沒有連結的文字有差別.

要讓浏覽者很友善的認出哪些是

圖檔加的連接配接要在圖檔下标出”點選圖檔見大圖”,圖檔一定要加”alt”屬性.

”更多”要用中文寫最好不要”more”或者标點符号代替.

11.過多的運用新技術

所謂新技術,就是隻有少數人掌握的技術

雖然有可能他的視覺效果很好,功能很強大,但過多的運用新技術,就意味着你準備抛棄99%的使用者,最後玩砸了

12.過複雜的分類

不要說什麼用收藏夾.你以為會有超過一半的人會用收藏夾嗎?

在一個過分複雜的分類中撈不到使用者想要的資料是悲慘的

執行個體:哔哩哔哩

想找點資源按分類查,分類太多太雜,居然找不到,謀殺了一個年輕人熱愛學習的心

13.關于複雜的驗證碼

驗證碼從設計之初,是為了解決區分使用者是人類還是計算機的難題

對于圖檔中被扭曲過污染過的文字計算機無法辨識

而人類隻需要稍微思考下就可以識别出來,但是現在是連人類努力思考也未必能識别出來(比如請你正确的區分出下列那些是狒狒那些是猩猩)

執行個體:12306購票平台-圖檔驗證碼

12306是很值得被吐槽的,讓歸心似箭的使用者迷失在打碼般模糊的圖檔驗證碼的海洋裡,預防不了黃牛,卻成功的攔截了使用者

拓展:主流驗證碼大緻分為以下幾種

  • 文字型
  • 拼圖型
  • 12306型
  • 閱讀了解型
  • 智商題型

網易雲免費體驗館,0成本體驗20+款雲産品! 

更多網易技術、産品、營運經驗分享請點選。

相關文章:

【推薦】 爬蟲開發python工具包介紹 (2)

【推薦】 Question | 網站被黑客掃描撞庫該怎麼應對防範?

【推薦】 TiDB和MongoDB分片叢集架構比較

繼續閱讀