## 產品設計體會(三七)——可用性測試
可用性測試也是用戶研究/需求采集的一個常用方法,從理念上講就是:讓產品的最終使用者盡可能多的參與到產品設計各個環節中去,深入一點就很2.0了——“用戶創造內容”(這也不是什么新概念,傳統行業的宜家IKEA好像早在50年前就有所行動,讓用戶參與到產品的設計),把用戶參與擴展開,還可以包括前期調研、demo評審等等。
?
可用性測試的效果往往無法量化,所以經常因為項目時間過緊被略過,好不容易前段時間這次有了一些空閑,正好系統的部分模塊是給阿里內部人員使用的,所以就很低成本的執行了一次可用性測試。最最輕量級的,表現為:一個人,半個小時,在我的座位上,結果提出了15個左右的問題,效率很高。
?
講幾點要注意的地方。
?
可用性測試開始之前,要邀請用戶來做tester,不要給tester看到“可用性測試”的術語,而是說“來試用一下我們的新產品,提點意見”,一定不要讓用戶誤以為是我們拿著新產品測試他,而是我們和他一起測試新產品。告知大概持續的時間,給一點產品的背景知識,測試內容是做哪些事情完成哪些任務,讓tester心中有數。
?
做測試的過程中千萬不要引導,而只是觀察和記錄,用戶行為和預想的不一樣的時候,提問,進行不下去的時候,給與提示。記住一切的錯都是產品和我們的錯,用戶絕對沒有錯。如果真覺得用戶錯了,那也是你找錯人了,不是這個人錯了,:)
?
結束之后,如有可能應該送個小禮品,但這次內部的就免了呵呵。盡快的總結,發給tester,一方面讓tester感到他起到了作用,另一方面也是表示感謝,建立長期和諧的“用戶參與產品設計”的氛圍。最重要的,這分總結要用于指導產品改進,這才是可用性測試的根本目的。
?
有興趣的繼續去搜搜:《進行可用性測試的8個指南》、譯言的《了解可用性測試》。
- 前言
- (一)——變態吧,開始帖周報了
- (二)——數據分析
- (三)——性價比:做不做?
- (四)——需求管理
- (五)——有關流程
- (六)——再談流程
- (七)——需求探針
- (八)——產品與項目
- (九)——關于學習
- (十)——團隊合作
- (十一)——市場掃描
- (十二)——少而精
- (十三)——再說需求分析
- (十四)——做過的幾個項目
- (十五)——PM、PD、UE與UI
- (十六)——Feature List
- (十七)——PD的幾種文檔
- (十八)——概念設計
- (十九)——UPA年會的流水賬
- (二十)——有關改版
- (二二)——封閉開發
- (二三)——用戶研究
- (二五)——當交互設計遇到敏捷開發
- (二六)——PD就是出來賣的
- (二七)——大產品設計
- (二八)——細節之文案
- (二九)——產品設計的五個層次
- (三十)——“體會”導讀的思維導圖
- (三二)——零散的體會
- (三三)——用戶大會
- (三四)——土老板破冰必殺技
- (三五)——QA與測試
- (三六)——再理解“敏捷”
- (三七)——可用性測試
- (三八)——項目外包!=開發外包
- (三九)——CSDN專訪精編版
- (四十)——銷售渠道
- (四一)——用戶創意無限
- (四二)——又是零散體會
- (四三)——說說評審會
- (四四)——項目外包不適合“敏捷”?
- (四五)——外行眼中的技術分工
- (四六)——UML學習摘錄(上)
- (四七)——UML學習摘錄(下)
- (四八)——資源戰爭與BRD
- (四九)——產品市場化
- (五十)——終點:Matrix
- (五一)——敏捷的估計與規劃
- (五二)——MS Office使用心得
- (五三)——產品文檔與規范
- (五四)——PD招聘廣告詞
- (五五)——項目Kick Off
- (五六)——《需求工程》培訓記錄
- (五八)——《項目化管理》培訓記錄