版權聲明：轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://piglili.blogbus.com/logs/39900064.html

上周參加碳酸分享，趁機對設計師進行了小小的“調研”。當然，8個問題，16個設計師，說“調研”有點只是希望更好地了解一下提出測試需求的設計師們——也就是我們的“客戶”，也為接下來的工作提供指引。

（由于用的是google的表單統計摘要，圖表沒法排序，有點惡）

時間很少，需求很多，設計師都很辛苦哦。

上次用戶測試前看項目的PRD（產品需求文檔），總覺得非常以功能為中心。遂萌生了了解設計師如何看待的想法。結果跟我的感覺差不多。那么，用研組是否合適去承擔，輔助產出用戶使用場景(Scenario)和Persona的工作？

這道題讓設計師勾選TA所使用的工具/手段，并排序。
既然收集案例是絕大部分設計師都做的事情，那一個內部的案例共享庫，會不會有用呢？
有意思的是，有一半以上的人將Persona列為常用輔助手段，且是第三常用的，我就好奇了，這些Persona是以什么形式存在的呢？似乎從沒見哪個項目產出過Persona哦。那是否意味著Persona僅僅存在于設計師腦海？存在于腦海的話，其實是否就已足夠呢？

可用性測試平均排名為首，這是很正常的，因為耗時最短。大家對實地考察的興趣蠻濃厚～～～我也很期待！

哈哈，有趣的結果哦！用戶使用心得日志竟然排在第一了！也許是因為大家感覺這種反饋最真實？
其實，之前已在考慮做這種人種學形式的體驗案例收集，只是困難包括周期長，數據提取、總結較復雜等。當然，人種學式的用戶研究還是很希望有機會做的。

6個人測試為什么就足夠，看來我們還是沒有好好傳達出去。對于定性和定量的區別，實在很tricky，但是想明白了，還是很清晰的。
至于測試任務，我們也很頭痛呢。記得我看過一個設計師說他認為測試的環境太假，用戶在假環境中做著假任務，只會給設計師制造假象。的確，仿真程度往往與測試嚴謹性是互斥的。但可用性測試并不是也不可能發現所有問題，比起AB Test或投放試用版，它能更廉價、更高效地發現可能存在的問題。經驗看來，即使在假環境中做假任務，也能做到這一點。這些問題未必有普遍性（因為樣本小，無法推論），但問題既然發生，那么通過分析原因——包括用戶本身的個體差異，是否違反設計規范、經驗準則等，就能較好地判斷設計是否不妥，或者是否能進一步優化。這也是為什么6個人就足夠的原因之一。用一個簡單的方式理解就是，可用性測試不是要論證問題的普遍性，而是試圖發現可能會被用戶普遍遇到的問題。AB Test確實能從數據上證明版本的優劣，但它并不能告訴你，A為什么比B好，B是否也有比A好的地方。而讓6個用戶試用A和B版本，盡管不能用“5個用戶覺得A比B好”來證明A就是比B好，但至少你更有可能發現A和B各自的優缺點，從而產出一個更完美的C來。

對于報告的撰寫，我們一直在探討，并努力改進。目前結果看來，與我們努力的方向還是一致的，只是仍需努力

記得前周一個培訓上，一位交互設計師提到，希望用研童鞋的報告“把問題寫得嚴重點，但表達得委婉點”。就是說，動之以情曉之以理是吧？要照顧設計師的情緒，又不能不指出問題，的確有點難度可是，我們會迎難而上滴！

每一個項目的測試，對我來說都是向設計師學習的機會。而我們這群從來不設計，卻老去挑人家設計毛病的用戶研究員，的確應該提供更多“服務”（如上面提到的使用情景、Persona等）。只不過由于溝通的缺乏，我們往往被排于設計的主流程之外，只是在最后的時候來插一腳。

最后一道是開放性問題，“想對用研童鞋說的話”。大家的“加油”我們看到了，大家的期望和指教也看到了。讓我感動的是這句話，“我信任你們的團隊”。信任是最大的支持和鼓勵，也是最大的鞭策——因為不可以辜負這種信任哦！
未來的大方向，就看偉大領導輕侯同學的指引了。至于我自己，目前將致力把國際化的研究方法山寨化。