用戶研究如何跟上產品的快速迭代？
現在互聯網產品迭代速度很快，很多是小步快跑，跑錯方向再改，而不是經過比較全面的用戶研究，再去決定迭代的方向。
一個完整的用戶研究確實會花費很長時間，很多時候把等研究結果的時間用來迭代，也早就找到正確的方向了。請問，如何讓用研更好地融入到互聯網產品的快速迭代中？
謝邀。用戶研究與產品迭代之間的關係是用研面臨到的重要問題之一。這其實需要的是建立起來一種機制，是用研能參與到其中的機制，從而避免用研「可有可無」的尷尬局面。從以下方面說，一，用研同學必須有產品意識和產品思維，必須對於產品的迭代周期、產品思路有深刻了解，我覺得大部分產品不願意找用研，是因為覺得「研究」離產品太遠以及時間太長。因此，用研必須保持「時刻準備好」的狀態，在明確調研目的的情況下做一些小而精的調研，縮短調研周期，快速將結果運用到產品中去。二，互聯網產品雖然迭代快速，但並不是每一次的迭代都值得去調研，不要為了跟進而「跟進」。因為研究必然是有成本的，做任何調研都要衡量性價比的問題。據我觀察，小於一個月的迭代，大部分是優化和修復，這種情況是沒有多大調研價值的。而大於一個月，甚至半年的大版本才是調研的重點，這種大的改動往往更能體驗調研的價值。三，需要建立用研與設計、產品甚至是技術之間的長期合作信任關係，要讓他們看到調研是必須的，是有成果的。這樣幾次之後才會建立起長期的合作機會。以前的經驗大致這樣，希望有用。
謝邀。
我覺得頂樓百度的同學說得蠻好的，大部分的觀點類似。研究天生是個消耗品，跟快速迭代是相矛盾的。尤其是希望達到學術標準的用研，要求的時間、成本、方法都很高，跟上產品節奏或者說幫助產品落地無異於天方夜譚。
我們要做的就是小步快跑。用產品經理的思維方式去貫徹用研。做精益用研
另提一句，要做戰略層的用研，僅僅思考用戶層的問題是不夠的，我們需要對商業模式、市場運營都有深入的分析。這樣才能佔據主動
修改一下：關於迭代的說法經驗來源於互聯網行業這裡嘗試從技術的層面對問題進行討論。如何讓用研跟上產品迭代，也許先假設產品迭代是在敏捷開發環境下進行的，我想這會是一個可信度很高的假設，因為快速的迭代很少發生在傳統瀑布模型下。
Desiree Sy 對在敏捷設計中融入可用性測試進行過深入的討論，讓我們以她在Journal of Usability Studies中的文章《Adapting Usability Investigations for Agile User-centered Design》作為討論的切入點。
文章的要義在於：
- Sprint 0： 用戶研究早於其它工作在Sprint 0 開始
- 平行設計：用戶體驗與產品開發擁有各自的Sprint Planning，平行前進
- 設計領先產品開發一個Sprint，而用研領先產品開發兩個Sprint
Desiree Sy提出的設計模型，為我們提供了一種思路。雖然在很大程度上，該模型工作與理想的產品開發環境，尤其它假設產品迭代遵循初步擴展的節奏，而不會發上產品概念上的巨大改變。對很多成熟的產品來說，這樣的假設是毫不過分的，我想如果你的工作是為成熟的產品尋找新的功能，上述的設計模型經過對具體情況的適應，應該會有所功效。當然，之前大家討論的，對用研方法的調整也必不可少。
對於全新的產品，或者突破性的創新，我們則需要有完全不同的思維。在這樣的情況下，用研的挑戰更多是如何推動產品pivot。沒人能知道用戶將來會喜歡什麼，此時將用研的工作重心從feed forward調整為feedback，強調測試的重要性，而不把有限的時間投入在對用戶未來的需求膚淺的研究中。上述的討論無意降低深度用研的重要性，這是用研對產品長期的價值所在。對於突破性的創新，產品周期遠遠小於深度用研所需的時間。所以與其說把用研融入產品迭代，不如說將產品迭代融入到對用戶深入的理解過程中。問題題干本身就有問題了，為什麼用研的定位是跟上產品的節奏，優秀或者說合格的用研應該引領一個產品的走向。
因為自己也是這條道路的實踐者，所以想要多說一點。我不清楚是不是所有人都知道產品每天在做什麼，但不排除產品的隊伍中有一部分人其實只是熟悉PM流程的項目經理，他們在把握用戶需求和產品形態的造詣有時候可能還不如UX體系的人。跟著產品的節奏做用研有兩個坑，1. 這些人本身設計的產品並不靠譜，且不自知；或者他們根本對產品走向沒多大發言權（跟著老大走）2. 產品有「證實」的傾向，沒有上帝視角的大家只能根據自己的經驗去判斷哪個需求是真的，哪些需求是偽的。通過PM的加工用研的結論打折不只一半，也沒什麼意義那麼怎麼不跟著產品節奏作用研又能影響甚至引領產品走向呢？
1. 不需要用研直接小步迭代就能驗證的需求請盡情的去上線驗證，後者確實更有效率
2. 用研要自己做落地的事情，發現問題並且解決問題，自己試著把解決發現問題的原型畫出來。這有兩個好處，一是能明顯提高用研結論落地轉化率；二是在做設計的過程中就會很明確實際設計中需要怎樣的用研數據3. 用研要自上而下影響產品。做了三年用研，第二年開始實踐以上的路徑，到現在個人收穫不負責任的說大於同一起跑線上的其它同僚們。在外界，一旦這種經驗成功過一次兩次，之後根本不會遇到題主提出的如何跟上節奏的問題，剩下的問題只是在眾多產品提出的需求中，你看重哪一個？想深入去實踐哪一個。我不是用研，但是和我們公司的用研同學討論過這個問題，當時他說「這就好比是要質量還是要速度的問題嘛，太難平衡了」。但是後來我們想想那也就是一時的吐槽，其實用研和快速迭代本身是沒有矛盾的，只不過是現在的一些用研方法已經不適合流行的快速迭代環境了，用研思路需要更新！
我們團隊（或者整個獵豹移動）都是以快速迭代聞名的，重要產品幾乎一周一個版本，很多周一發出的迭代計劃，周四之前就要測試好上線，周末之前就要看到反饋並且準備到下周的彙報中。這樣的速度別說是用研了，連設計師作圖都很難跟上。
但是我們發現沒有用研不行，沒有用研就好比我們在做一個低頭不看方向盲頭奔跑的人，沒有用研我們就沒辦法了解除了數據直觀反饋以外的其他改進是否有效果，所以我們經過長期的摸索就學會了把用研「互聯網化」：1，最重要的就是把用研變成一個常態的事情團隊每一個成員都要接觸用戶，經常接觸。泡論壇和QQ群是家常便飯了，每周都要邀請一位用戶做用戶訪談。原本為了某個用研計劃開展的那種集中幾百人的訪談被分到了平時每個人互相幫忙做，至於質量當然無法完全保證，但是一個問題能把握到大概也是可以的。這種氛圍下仍然需要一位懂用研的同學帶領大家，主要目的是協調大家一同參與，作為諮詢者和領導者發起和把控整件事情，而不需要他萬事都親自去辦。因為他的經驗和幫助，我們可以把用研結果保持在可用的層面上，至少主要目標能夠解決，至於那些精細的用研報告或者更詳細的分支問題一般都省去了。另外這樣還能訓練大家的用戶感覺，在一些普遍或者不那麼重要的問題上因為長期的訓練大家都心中都自有譜子，而不是專業的人更專業，不專業的人只能幹等著。2，更前置的開展用研活動
產品的快速迭代其實更多是指加快產品的開發節奏，不要因為走錯路而浪費了耗時最長的開發資源。但是研究的工作一直不會停，而且說實話如果研究能夠提前發現結果也比產品開發出來要划算的多。我們UE團隊有的時候會看到很多很長遠的問題，比如一些用戶痛點在當前並不是最緊急的，但是隨著產品逐漸完善我們一定會遇到的問題，我們就會提前開展用研工作。因為對瀏覽器的經驗，我們會把整個產品的發展當做一顆大樹，在開發搭建主幹的時候我們就已經在探索分支了，等開發分支的時候我們再來探索主幹如何升級，始終保持比產品團隊還要快一個步調。
然後我們還會維護用戶體驗地圖，如果不知道的可以看這個「以乾貨開場，如何有效地做用戶體驗地圖」。就是對產品的某一方面保持長期的觀察和評估，雖然不會做那麼高大上的展示，但是大家心中都會對某個流程的體驗問題是非常有譜的。當這些準備都完成之後，我們就會把重要且有解決方案的問題用快速迭代的方法儘快丟在線上實踐，其他相對重要但是還有疑問的問題就要做用研。
這種情況下用研的方法很多，一種就是和傳統一樣，訪談和問卷照樣做，雖然時間長但是我們一時半會也不會著急開發到這一塊，只要保證合適的時間能夠拿出合適的解決方案就可以了。還有一種就是告訴大家最近要注意這方面的問題，比如收集用戶反饋和與用戶聊得時候多深入挖掘一下。另外我們的用戶反饋在平時就都有收集，所以我們會把以前相關的反饋都拿出來認為分析原文和挖掘場景。
很簡單。如果想把產品快速迭代跟勞，就用行為數據作為效果衡量方法，持續優化單點。這種方法盡量別用在新產品上，不是說做不了，而且影響因素多了後，一方面當前很多行為數據並不幹凈，另一方面多因素必帶來權衡和複雜性，也會拖慢迭代速度。
但我本身就置疑這個問題，在互聯網產品中的確最接地氣的用研服務是圍繞產品迭代做。但對商業而言，並不是唯一價值，也不是最高價值。建議每個用研人多想想，當然，在解決了個人的基礎存在價值後吧。利用現有的研究成果在設計前期就介入多研究競爭對手用研也設計也做一些數據分析，給出結論要直接定性分析最好拿出理論依據多交流
推薦閱讀：
※UI 設計師如何向程序員解釋複雜的交互動畫？
※產品經理和項目經理的衝突，怎麼解決兩個角色的平衡？
※Axure 7.0 部件里的中繼器是幹什麼用的？
※如何最簡單的搭建一個語音交互的原型？
※justinmind為何沒能像axure一樣流行起來？