從畢業實習算起，從事可用性方面的工作到現在已經5年了。在此記錄筆者的一些所見所想，和大家討論分享一下。
用戶研究在“以用戶為中心”的界面設計方法中是很基礎，也很關鍵的一個環節。但在實踐中，筆者經常聽到的抱怨是“用戶研究投入多，耗時長，還沒用”。出現這種聲音的原因肯定是多方面的，在此筆者想從以下四個方面探討。
從業人員素質低？
有人說，目前可用性從業人員素質低，所以他們做的研究不夠有水準，影響了行業外對本行業的看法。這個提法筆者認同，但暫時不作討論。目前有不少從業人員的調查報告可讀，對從業人員的學歷背景等有較詳細的描述。舉個最簡單的例子， 2009年，公司高層領導發出的郵件中曾寫到“所有的設計師都要寫一些HTML，CSS，甚至PHP。” 西安交通大學李樂山教授也曾經說過，做人機界面設計要會寫代碼。而筆者自己就只會最簡單的HTML，這個基本要求達不到。
用戶研究的商業價值不易估量？
還有人說，用戶調查的商業價值不易估量，因此用研的價值不容易體現出來。對此筆者不同意。不做用戶調查，商業價值會更高嗎？這是走歷史回頭路。過去計算機硬件和軟件發展的50多年，就是在不斷汲取歷史教訓中走到今天這一步。一些問題被解決後，人們往往感覺不到有什麼進步——就像大家已經習慣了使用鼠標，感受不到和只使用鍵盤相比，人機交互方式發生了多大改變——如果某一個步驟讓用戶多花1分鐘，每天幾千萬人使用這個軟件，要浪費多少時間？使用互聯網產品，要浪費多少帶寬，浪費多少服務器資源？返回50年就明白是怎麼一回事了。歡迎大家來談論這個問題。其次，難以估量其創造價值的思想和方法並非只有用戶調查，比如，還有企業文化，品牌建設。我們很難精確估算出企業文化能為企業創造多少價值。就算在市場研究領域，以品牌價值評估為例，就有不少模型，並且還在不斷發展模型，但這“難以估計價值”的品牌建設也仍然不斷在建立項目，且不斷被實際應用。
敏捷開發對用研帶來影響
第三個問題，是軟件開發領域，筆者認為“敏捷開發”理念的提出和採用給用戶研究實踐帶來了一些影響。
圖1：敏捷開發（來源：http://wiki.mbalib.com/wiki/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91 ）
08年夏，西安交通大學李樂山教授給騰訊設計師培訓的時候說：“我們前頭搞用戶調查，是為了建用戶模型，用戶模型建出來目的是幫助撰寫設計指南供軟件開發人員參考。從事的軟件開發的很多人員他是不了解用戶的，但是他要根據你寫的設計指南，將所有的用戶需求都涵蓋在內。你如果漏了一條，他就可能漏了一個結構，一個功能。這個樣子到最後，軟件整個都失效了，沒有用了。”
這種情況很容易發生在採用“瀑布式”開發流程的軟件開發項目。從設計到製定產品特性，到開發，到測試，環環相扣，一步不慎，滿盤皆輸。 2001年， “敏捷開發”的概念被提出來。目前在騰訊，越來越多的產品開發開始採用“迭代式”開發流程。據了解，其他互聯網公司也在採用。這種“迭代式”開發的主要做法是：整個產品開發的過程是一系列不斷的迭代過程；固定發佈時間，發布速度快，有些互聯網產品每半月發出一個版本，每次提供一些新產品特性；灰度放量，小部分用戶先試用，然後蒐集這部分用戶反饋意見，快速修改版本，然後再大規模發布產品。
這種“敏捷開發”對用戶調查和設計帶來的主要影響是：產品發布速度快了，但調查從立項開始，執行分析，都需要花費大量時間，經常趕不上版本發布的節奏；通過灰度放量，可以通過用戶的實際使用產品後的反饋了解用戶情況，而不用依賴於前期大量分析工作預測用戶使用新特性的情況；架構靈活，修改代碼的成本低，允許開發出錯，不依賴前期調查結果做指南。
從本質上來講，“敏捷開發”和用戶調查並不對立。在中國大力推行敏捷開發流程的諮詢公司ThoughtWorks寫到： “敏捷思想核心是人的交流。需求問題實際上是個交流問題。商務分析師要和客戶交流搞清楚客戶到底需要什麼，到底為什麼需要這些東西？商業價值是商務分析師關注的最終目標，有了目標指向就可以不迷失方向。和客戶進行交流的最終目就是挖掘出客戶商業目標。可能大家會經常有這樣經驗——客戶說我要這個功能，我想要如何如何樣，這時候要特別注意他說這些東西可能並不是真正需求，商務分析師需要詳細問客戶為什麼，挖掘出他真正目標。”典型敏捷過程模型中的一種叫極限編程（Extreme Programming），是通過故事卡（Story Card）來管理需求。這種故事卡幾乎可以說是情景分析，任務分析的另外一種表現。 “敏捷開發”並不是不再關注用戶，而是從不斷從試錯中獲得用戶反饋，從而改進產品，其實是“以用戶為中心”的另一種表現。
圖2：故事卡(來源：http://www.scissor.com/resources/teamroom/ )
由此看來，“敏捷開發”本身對於程序員來說是“以人為本”的，因為它允許程序員犯錯，強調開發者之間的溝通交流，甚至鼓勵程序員與用戶交流，希望把機械的編程變成愉快的活動。
所以界面設計師對“敏捷開發”的態度不應該是抵觸的，應該尋找解決方案。這個問題筆者所在團隊正在嘗試通過工具和流程來解決——
我們通過工具來縮短調查時間。用戶訪談中，邀請用戶、做記錄和寫分析報告是很花時間的。對此，筆者團隊正在建立自願接受訪問的用戶數據庫，未來有需要時從中隨時抽取用戶；在調研過程中邀請項目組成員包括開發、設計師、產品經理一同來訪問和觀察用戶，第一時間分享有用資料，減少文檔寫作，只寫必要文檔。問卷調查中，製作問題是很花時間的，公司內部專門開發了問卷製作和投放系統，從製作到投向用戶最快幾個小時內就能完成（不包括設計問卷）。數據分析階段，使用SPSS分析時，將常用分析代碼整理出來，下次統計分析可以繼續使用，減少分析時間。通過使用工具，縮短調查本身的執行時間。最近團隊中一個調查員接到需求，調查盲人對產品的意見，從接到需求到找盲人到訪問到出報告，用了一周，其間還同時在進行其他項目，完成這個訪談項目只用了3個工作日。
我們通過流程來解決長時間調查與敏捷流程的矛盾：一次用戶調查的結果可以寫成許多“故事卡”，每次開發，只開發其中一部分“故事卡”，通過幾次迭代開發週期，才完成一次調查的“故事卡”的開發，這個期間，可以繼續進行新的用戶調查。
此外，最終還是需要對用戶使用所產生的後台數據進行分析，這仍然可以是負責設計調查的調查人進行的工作。
好“借鑒”，輕調研
第四個問題，比較本質，是由於國內企業喜歡“模仿”，或者說“借鑒”。
“借鑒”問題，會對用戶調查造成很大影響。有些團隊不願意投入在調查和設計上，產品的需求說明書和設計指南按照別人的成型產品照著寫就行了。想做調查的團隊，有了創新，設計出產品，也有很大風險被其他團隊“借鑒”去形成自己的產品。 （中國的專利現狀對界面設計沒有實質性保護，具體表現在：首先人機界面在中國往往只能申請外觀專利，是靜態界面，並不真正適合保護人機界面設計；其次外觀專利較難獲批，因此有時申請的是技術專利，其他團體換一種技術方案實現就不會侵犯專利；再次即使侵犯專利，打官司要拖2~3年，維權困難。）
“借鑒”的往往是其他文化背景下，如國外成功運營的產品。然而文化、國情、所處階段不同，直接“借鑒”也未必能成功，即使在騰訊，也有這樣的案例。產品成功，更需要做目標用戶的調查和分析。
“借鑒”絕對不是真正的捷徑，並非必定能獲得商業成功。
因此關於第四個問題，首先“借鑒”仍然存在的現在，還是離不開用戶調查，要對不同文化、國情、階段做出分析判斷，才能幫助產品獲得成功；其次“借鑒”並不是捷徑，絕不會是長期存在的。當“借鑒”不能成為可靠方法，那麼必定還是會回到從調查分析開始進行創新的路上來。
最後額外說一個問題。設計師與產品經理的關係一直是互聯網行業裡討論比較多的。筆者的看法是，做人機界面設計，其實和產品經理的工作有重疊，所以學習人機界面設計之後兩個職位都可以去應聘。已經在設計崗位上，也沒有問題，不妨把自己看成特殊技能的產品經理。界面設計師剛剛到崗，經常和產品經理髮生矛盾，認為對立的原因是自己是從用戶角度出發，產品經理不是。其實很可能是產品經理了解的信息更多，考慮的東西更多。要讓界面設計師站在產品經理的角度想問題，初入職的設計師又往往認為從用戶角度考慮就是自己的全部職責，堅持從一個角度看，缺乏大局觀。不妨在一開始的時候就把自己看成具有特殊技能的產品經理，這個矛盾就好解決了。
(本文出自Tencent CDC Blog，轉載時請註明出處)
特別注意：本站所有轉載文章言論不代表本站觀點，本站所提供的攝影照片，插畫，設計作品，如需使用，請與原作者聯繫，文章轉自alibuybuy