大部分互聯網公司會在開發或更新產品的投入上花費鉅資，但是效果往往不如他們當初所預期的那樣美好，事實上產品資料可能會非常糟糕。而絕大多數這樣讓人沮喪的例子都至少可以得出一個共同點，那就是:這些產品的團隊沒有在產品設計階段獲取足夠多的用戶回饋。
如果你覺得在產品設計階段把使用者相關的調研牽扯進來是一件非常耗時而且耗費財力的事，那麼你需要好好的重新思考一下這個問題，因為如果在這個階段不開展使用者研究，未來所需要花費的成本將會高得多。在國外有專門的用戶研究機構曾經做過一項研究，結果表明在設計階段解決一個問題所需要花費的成本僅僅是開發反覆運算產品過程中解決同樣問題的十分之一;而如果這個產品已經在上線推廣階段，那所耗費的成本將是你無法想像的，它能夠達到在設計階段解決該問題所消耗成本的至少100倍，而且這還僅僅是財務上的成本。加上所有的人力、時間的消耗，這個數值將繼續成倍的放大，而最終的結局將足以讓你後悔自己當初沒有做用戶調研的決定。
何時來做?
傾聽用戶這件事，你永遠不用擔心是否時間過早。
現在有很多種方法在產品設計階段中從使用者那裡獲取回饋和深度需求：
在產品設計還沒有成型的時候把早期的低保真設計圖畫在紙上拿給用戶看，獲取他們對於設計圖的回饋資訊。
邀請使用者來使用公司現有的產品，仔細觀察他們使用過程中的行為動作以及他們對產品的印象，最終發現用戶使用的痛點。
你也可以邀請用戶來使用主要競品，仔細觀察他們的使用過程，在這個過程中你會很明顯的發現哪些功能是用戶認為有用的，哪些是沒用的;哪些交互設計吸引用戶，而哪些則會讓用戶迷茫。
如果需要重新設計一個功能，如理財app中的註冊或綁定信用卡的功能，和你的使用者一起去驗證新的流程，確保他們輕易能夠理解新步驟中的每一步而不至於產生迷茫的情緒。
和誰來做?
很多時候，我們的調研不需要太多的使用者就足以發現很多很深刻的問題。
作為研究人員，你不需要把產品的設計理念展示給很多用戶，因為眾口難調的困擾將會讓你找不出一個科學而合理的結論，而事實上在設計的前期階段從少數用戶那裡獲得的回饋遠比在開發甚至更新產品階段詢問很多用戶來的有價值。一個6-8人的小規模用戶調研所產出的結論就足以支撐一次產品前期階段的使用者研究。
理想狀態下，最好是能夠與產品的目標使用者進行一次測試，特別是比如你的團隊正在醞釀設計一款針對特定人群的產品，如理財，購物app等。但是如果你的產品適合於普通的大眾使用者來使用，那就可以放心大膽的把你想要調研的設計和想法展現給你遇到的任何一個人，甚至是你辦公樓裡的保安，前臺，鄰居或室友，收穫同樣會出乎你的意料。
在哪裡做?
做快速的使用者調研，其實不需要一個正式的實驗室。
如果你在產品開發或反覆運算週期的後期針對這個產品進行一個全面的可用性測試，使用實驗室以及裡面的設施來開展測試可以幫助調研人員更嚴謹和全面的跟蹤用戶的反應;但是在設計階段獲取用戶的早期反應，一般的會議室甚至一個相對空曠的小空間就足以開展這樣的調研。你只需要一張桌子，一把椅子，一個主持人和一個要測試的主題，然後有一個現場錄音或者你的同事現場記錄，以便於稍後和你的設計團隊一起分享調研測試的結論就足夠了。
做什麼?
一張簡單的草圖或低保真原型圖就足夠開展一次用戶研究。
在做這類測試的時候，你不需要通過向參與測試的用戶展示一個設計完全並且功能都實現了的產品來獲得他們對這個產品的反應。事實上，你只需要一張簡單的草圖或者紙面原型展現給用戶，而他們回饋給你的，往往是一些重要的，甚至超乎你預期的見解和回饋。紙面原型圖測試在以下場景中尤其有效：測試一個產品的新功能或者改變一個產品已有的功能，例如一個搜索框或者綁定身份資訊的操作流程的新增或改變，通過紙面原型圖測試可以發現新的改變是否讓這件事變得更好，還是更複雜更難實現。
如果你的公司有交互設計師，那麼恭喜你擁有了更加美觀和貼近真實模樣的demo可供測試使用。相信所有的交互設計師們都能快速的根據我們的設想製作出超級逼真的頁面原型圖，你需要做的就是下載到你的手機當中，然後直接拿給接受測試的用戶觀看就醒了，當然了，必要的講解是少不了的。
怎麼做?
我們把驗證當初的設計方案是否可行以及收集用戶回饋的過程稱為設計演練環節。這個環節一般情況下會使用上文提到的紙面原型;當然，如果能提供一個已經實現部分功能的原型demo，那將是極好的。
一個設計演練的環節需要讓參與測試的使用者還原他們日常的場景和使用該類產品的需求任務。主持人需要要求參與使用者用指定的行為去完成每一個任務，然後傾聽他們在使用過程中對每一步操作的可用性和易用性等方面的評論以及回饋。這裡所需要注意的技巧是，不要過度的引導這些參與測試的用戶。給他們一個整體的印象，讓他們瞭解這個產品是做什麼的，或者描述一下這個產品所適用的場景和想要達到的目標是什麼，然後讓他們自己按照自己曾經使用真實產品的經驗來操作。當然如果這裡有兩個或兩個以上的對比demo或者原型圖需要使用者分別體驗一下，並得出哪一個更好等類似結論時，你需要事先平衡不同使用者體驗demo的不同順序，以減少因為順序對測試結果造成的影響。
一旦你從參與測試的用戶那裡獲取了階段性的回饋和評論，接下去要做的事情就是分析這些回饋。你可能會發現一些“攪局者”，他們的回饋從根本上顛覆了你對你產品原先的期待;但更有可能的事情是，你將會從中整理出來一個優化改進列表。當然了，最重要的事情是，確保這份優化改進列表能及時分享給你的設計團隊，這樣大家可以及時回應並採取相應的措施去改進產品的設計。
為什麼要這樣做?
不論你信不信，用戶經常性的參與能成就一款好的產品。
在產品設計階段讓使用者介入進來能夠讓提前遇到設計上的路障或者一些你意想不到的發現，而這兩方面很有可能在同一時間展現在你的面前，這也讓你能夠靈活糾正之前設計過程中的誤區，最重要的是，成本很低廉。這是能夠保證產品能夠被使用者接納並準確而輕鬆使用的最有效的途徑。從長遠來看，無論多小的規模或者方法多簡易，調研人員嘗試去獲取用戶回饋的任何努力都將會節省設計團隊一大部分的時間，財力和未來可能發生尷尬甚至推倒重來的局面
留言列表
